Green is the original line, red is the computed buffer polygon. Test script is at the end of this post. Maybe I’m making some large mistakes but I observed the following problems:
General:
The scaling of the units seems to be way off. I wanted a 10 nautical mile (NM) buffer around the line but this led to a polygon way outside the plot area. had to use 0.05 NM to get the present result.
Different scaling in N-S and E-W directions. The buffer seems smaller in E-W direction compared to the buffer in N-S direction. Maybe a bug where it wasn’t taken into account that 1’ latitude isn’t 1 NM except on the equator? This Lambert conic conformal projection should make the buffer almost identical in both directions.
Test 1 (upper left) did almost what I expected, however there are two stray lines pointing to the west?
Test 2 (middle) as expected except for the points written under General.
Test 3 (lower right) has similar problems as Test 1 (stray lines) and additionally the buffer simply bridges the gap and doesn’t follow the green line on the inside. I expected something like Test 2 but with the bends.
As said, I’m not sure if I did everything the proper way. Your ideas and help is greatly appreciated. Am I making some major mistakes somewhere?
Yes, it’s a Mirone plot but the projection if it has a name I don’t know it. It’s a linear one that has a 1:1 scale at middle latitude. But that is not the real point. If you have read the mails I linked you saw that the main problem is that GEOS lib (the guy who computes the buffers) works only for Cartesians and the mail discuss strategies when using lon,lat data (basically the advice is to project to an equal-area, compute the buffer and project back to geogs. But this is not implemented in gmtspatial.
In Mirone I programmed another algorithm, (based on the Matlab one) where each vertex is the source of a geographical circle (radius = buffer width) and the buffer is the union of all circles and rectangles connecting not touching circles. This is not completely right as I should interpolate the straight lines with a 2*buff_width such that vertex insured circles touch each other. But for my usage at the time, that was good enough.
Yes I read the mailing list thread. Thank you for the link. I’m not sure if the equal area work-around is good enough for higher latitudes. I hoped with this experiment to find another approach for my problems from this thread or at least to get a nice outline for visualisation purposes.
On the contrary, this one is purely geographic (spherical or ellipsoidal [default]) and believing in this Esri site not even ArcGIS has one (theirs is only for points or multi-points), whilst QGis uses the goto-equal-area-n-return and R does it only with (visible) rectangles.
In this fig the red line represents the Matlab solution. I’m still not clear why they differ so much on the polar region. I interpolate the line segments along great circles, Matlab rotates the segments to put them on the equator and then computes the buffer along small circles of latitude = to buffer width so I would say that they also interpolate the line segment along great circles but it looks more as if the interpolation is done along rumb lines.
When trying to recreate it I only get error messages. I installed julia via github and have now version 1.7.0-DEV.1268 (2021-06-07). For troubleshooting I went back to copy & pasting examples from the GMT.jl docs but no luck either:
Hmmm, that’s worse. It means that your proj4 library is old or for some reason it misses the pj_get_spheroid_defn function.
At some point in the development I saw that error too (don’t remember anymore where)
It works in the 3 Linux’s that I have access.
I tried to update my julia installation via git pull followed by make clean && make as recommended in the docs but now the make process fails:
[…]
CC src/llvm-demote-float16.o
LINK usr/lib/libjulia-internal.so.1.7
/usr/bin/ld: ./codegen.o: in function `__gnu_cxx::new_allocator<llvm::Type*>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o: in function `__gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o: in function `__gnu_cxx::new_allocator<unsigned int>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o: in function `__gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: /usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o:/usr/include/c++/11.1.0/ext/new_allocator.h:110: more undefined references to `std::__throw_bad_array_new_length()' follow
collect2: Fehler: ld gab 1 als Ende-Status zurück
make[1]: *** [Makefile:300: /home/kristof/Dokumente/github/julia/usr/lib/libjulia-internal.so.1.7] Fehler 1
make: *** [Makefile:76: julia-src-release] Fehler 2
