Opened 12 years ago

Last modified 4 years ago

#378 new defect

g.region: weird w if input e=w

Reported by: msieczka Owned by: grass-dev@…
Priority: normal Milestone: 6.4.6
Component: Projections/Datums Version: svn-develbranch6
Keywords: g.region Cc:
CPU: All Platform: All


In a latlon location specifing e=w gives a weird w border. E.g.:

$ g.region e=180 w=180 n=90 s=-90 -g


Change History (6)

comment:1 Changed 12 years ago by neteler

540 - 180 = 360

That's the global wrap-around magic, AFAIK not blocked to allow for the Mars coordinate system which is from 0..360 deg. Or an epsilon issue?


comment:2 Changed 12 years ago by hamish

It is ambiguous, do you want 0 columns or 360? What is the goal?

g.region -p says: e 180E w 180E

anyway I think that it handles the ambiguous input as best as can be expected, I don't see the problem here. Possibly throw an error message out complaining that it has to guess what you meant, but as there cannot be 0 columns, the only valid choice is the 360 case. A bug would be if the global wrap around magic fails with e>360.


comment:3 in reply to:  2 Changed 12 years ago by msieczka

Replying to hamish:

It is ambiguous, do you want 0 columns or 360? What is the goal?

In a projected or xy CRS e=w or n=s in g.region makes it print an error:

ERROR: Invalid region: East must be larger than West

and quit not touching the region setting. In a geodetic CRS however no such such error crops out, while it should IMO.

comment:4 Changed 11 years ago by martinl

Keywords: g.region added
Priority: majornormal

Any reason to leave the ticket open?

comment:5 Changed 7 years ago by hamish

Component: DefaultProjections/Datums

comment:6 Changed 4 years ago by neteler

Note: See TracTickets for help on using tickets.