GenericMappingTools / GenericMappingTools/gmt
-Jepsg where epsg is an UTM with negative longitudes fails in classic but only for .ps in modern.
- Dominant language
- C
- Stars
- 979
- Forks
- 414
- Avg merge
- 17h 26m
- Merged PRs (30d)
- 54
Description
The modern case first.
This fails. No PS error but figure is blank
```
gmt coast -R-81.8/-66.9/-1.0/15.0 -J32618 -Baf -BWSen -W0.5 -Da -ps lixo
```
but this, or any other format, works.
```
gmt coast -R-81.8/-66.9/-1.0/15.0 -J32618 -Baf -BWSen -W0.5 -Da -eps lixo
```
Now the classic mode case. Since here we only have output in .ps it always fails. But using the -J GMT syntax, works.
That is, this works. (epsg:32618 <==> JU18)
```
gmt pscoast -R-81.8/-66.9/-1.0/15.0 -JU18/14c -Baf -BWSen -W0.5 -Da -P > lixo.ps
```
Several debugging hours later I found why. The ``gmtproj_utm()`` function (called by ``gmt_geo_to_xy``) has
```
if (!GMT->current.proj.north_pole) (*y) += GMT_FALSE_NORTHING; /* For S hemisphere, add 10^7 m */
```
but the corresponding GDAL function that is used for the UTM transformation doesn't have that offset and thus the computed ps units are negative and points fall off cliff.
So, one of the problems is identified though I don't know a cure since the transformation for the epsg case takes place inside the GDAL lib.
The second problem is: HTF the modern mode is insensitive to problem one when not using the .ps format????
Contributor guide
Assessment
This issue has not been assessed yet.