g.region: weird w if input e=w

[msieczka]

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

n=90
s=-90
w=180
e=540
nsres=0.00083333
ewres=0.00083333
rows=216000
cols=432000
cells=93312000000

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

Markus

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

Hamish

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

[martinl]

Any reason to leave the ticket open?