GenericMappingTools / gmt

The Generic Mapping Tools
https://www.generic-mapping-tools.org
Other
861 stars 359 forks source link

Error in Stereographic (-JS) plotting #6125

Closed joa-quim closed 2 years ago

joa-quim commented 2 years ago
julia> plot([315,30], marker=:circ, mc=:green, ms=0.2, region=:global, proj=(name=:Stereographic, center=(0,0)), frame=(annot=:auto, grid=:auto), show=true, coast=true, Vd=1)
        ["psxy  -Rd -JS0/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"]
psxy [WARNING]: Latitude (315) at line # 1 exceeds -|+ 90! - set to NaN

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. GMTjl_tmp-fs8

PaulWessel commented 2 years ago

Why is 315 considered a latitude? See the error message. Any rogue -: going on?

joa-quim commented 2 years ago

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.

joa-quim commented 2 years ago

Get the same shit if using Lambert Azimuthal (-JA0/0/14c)

PaulWessel commented 2 years ago

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.

PaulWessel commented 2 years ago

That message also appears in _gmtlib_process_binaryinput.

PaulWessel commented 2 years ago

BTW, we have never annotated those projections for -Rg.

joa-quim commented 2 years ago

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. GMTjl_tmp-fs8

PaulWessel commented 2 years ago

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.

maxrjones commented 2 years ago

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?

PaulWessel commented 2 years ago

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.

joa-quim commented 2 years ago

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. GMTjl_tmp-fs8

joa-quim commented 2 years ago

And indeed. If I save input data in a text file then the plot is correct.

gd-a commented 2 years ago

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.

maxrjones commented 2 years ago

@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?

PaulWessel commented 2 years ago

Will try to find out.

PaulWessel commented 2 years ago

@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.

joa-quim commented 2 years ago

I did a quick try and found that image 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.

joa-quim commented 2 years ago

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?

PaulWessel commented 2 years ago

This is a good check. PyGMT uses matrices and vectors but no GMT structs like DATASET.

joa-quim commented 2 years ago

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)

image

joa-quim commented 2 years ago

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.