GenericMappingTools / GenericMappingTools/gmt

-Jepsg where epsg is an UTM with negative longitudes fails in classic but only for .ps in modern.

Open
#7,773 3 comments 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.