Closed joa-quim closed 2 years ago
Why is 315 considered a latitude? See the error message. Any rogue -: going on?
Yes, that's why I tried -45, thinking it was a error in the message string, and got two points. But note that the latitude f the point is correct.
Get the same shit if using Lambert Azimuthal (-JA0/0/14c)
Seems related to binary input (that is where the message comes from) which makes sense since your input data comes in as a binary data set. It is in gmtio_bin_colselect so not projection dependent. Pinging @meghanrjones since she is familiar with that part of the code.
That message also appears in _gmtlib_process_binaryinput.
BTW, we have never annotated those projections for -Rg.
This came out on the Julia forum where (a geologist, likely) wanted to plot on a stereonet and for that, annotations may be quite handy. Even if for confirming the plot correctness. That's why I added the coastlines.
And we do annotate longitudes if the center is at the pole.
Yes, but this is -R0/360/0/90, etc. I know what you mean. Will try to have a look at the binary stuff later but family visitors makes it unpredictable and Meghan is at AGU.
I haven't been able to reproduce the issue using gmt or PyGMT. @joa-quim what resource do you use to pass the data to GMT?
I dont understand why this case mixes lon/lat in the binary input. Presumable most Julia plots still work when you pass then data directly? It ought to affect everything unless there is a hidden -i setting somewhere for the above case.
It's not a -: switch. Tested hat already, if I manually swap input then we get two points.
julia> plot([-45,30], marker=:circ, mc=:green, ms=0.2, region=:global, proj=(name=:LambertAzimuthal, center=(0,0)), frame=(annot=:auto, grid=:auto), show=true, coast=true, Vd=1)
["psxy -Rd -JA0/0/14c -Bpag -BWSen -Sc0.2 -Ggreen -P -K > C:\\TEMP\\GMTjl_tmp.ps", "pscoast -R -J -A200/0/2 -W0.5 -Da -K -O >> C:\\TEMP\\GMTjl_tmp.ps"]
Meghan, GMT.jl passes data in/out using GMT data types (filling/reading them). A GMT_DATASET in this case
I'm sure gmtmex
will show the same thing.
And indeed. If I save input data in a text file then the plot is correct.
And we do annotate longitudes if the center is at the pole.
@PaulWessel : I think I mentioned this problem when creating the polar sea-ice animation. I think I ended up overlaying manually psbasemap.
@PaulWessel, I don't think I can help without setting up mixed debugging with GMT.jl because the problem does not exist for any of the input types we use in PyGMT.
Is this a cross-platform issue or Windows specific?
Will try to find out.
@joa-quim, it may be simpler (well quicker) for you to debug and see what you learn when you enter one of those two functions I listed in gmt_io.c that have that message.
I did a quick try and found that the problem is what I said before. Something with debugging from Julia screwed so much that it's now extremely painful to debug because it takes > 20 secs to step one line.
the problem does not exist for any of the input types we use in PyGMT.
OK, my turn. What are those types (other than passing a file name)? A Matrix?
This is a good check. PyGMT uses matrices and vectors but no GMT structs like DATASET.
I can't understand what's inside that M.data structure nor how it got there but it ain't right (and here I am again debugging the part I want stay away more, the IO)
Ghrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
My bad
plot([315, 30], ...)
is a vector and interpreted to mean [1 315; 2 30] (like in Matlab when we don't specify the *xx** coords). When I do it the correct way, plot([315 30], ...)
(a matrix. Julia distinguish between the two), then it works fine. Fragile, I agree but don't know how to catch this mistakes without compromising the generality.
Sorry for the false alarm.
And the result is wrong in longitude. If I use -45 instead of 315 then no error message but it pots two green circles. Note also then no latitude annotations are plotted, though they we requested.