[GRASS-dev] latlon support

[Markus Metz]

Glynn Clements wrote:
> Markus Metz wrote:
>
>   
>> How about reversing the current policy? Restrict both raster and vector 
>> maps to the 180 degree lon and 90 degree lat limit, that avoids 
>> duplicate features within a map. Allow the region to be set anywhere 
>> between -360 and 360 lon but restrict the width of the computational 
>> region to 360 degrees lon to avoid duplicates.
>>     
>
> That is problematic for computations which use a window (e.g. 
> r.neighbors, r.proj, r.mfilter etc) on a whole-earth map. For that,
> you need 360 degrees plus the width of the window.
>   
Do you really mean "360 degrees plus the width of the window"? That 
would be max 720 degrees? The status quo is to restrict the width of the 
current window to 360 degrees, maximum possible extends are 180W to 
180E. So you say the current status quo is problematic? This limit 
applies to the computational region, a module is free to override that 
for internal calculations, but as soon as a module calls 
G_put_raster_row(), the current computational region is respected, right?
>   
>> Wrap map contents to the 
>> current computational region if any map contents exist that fall into 
>> the computational region. This would allow traversing the datum border 
>> without gaps or breaks, e.g. for raster resampling. The display is not 
>> affected, apart from "zoom to the current computational region".
>>
>> I'm afraid you have thought of that possibility before and found flaws 
>> in it. Apart from rewriting a lot of code...
>>     
>
> AFAICT, the most important case to solve is when the region is set to
> the Bering strait, and a vector map has Alaska at ~180W and Sibera at
> ~180E. Some of the data will need a 360-degree shift to obtain the
> correct relative position.
>
>   
That is apparently done not only for display but also for vector operations.

Anyway, I just realized (embarrassing that I did so only now) that I can 
set the window to East = 170W and West = 170E which gives me a window 
width of 20 degrees going over the datum border. There is no error that 
East must be east of West, this is a valid window setting. A vector is 
properly displayed. I can convert that vector to a raster, that raster 
is also properly displayed. The raster map extends are East = 170W and 
West = 170E, seamlessly going over the datum border, great!
East = 190E and West = 170E is not a valid window setting though, 
g.region exits with an error.
So with the current latlon handling of GRASS everything is just fine as 
long as the map coordinates are within limits. My only complaint would 
now be that somewhere deep down it should be enforced for vectors to 
stick to these limits. Further on, if there are any modules that require 
East to be east of West they do so wrongly for latlon, this is correctly 
handled by g.region.

Replying to Hamish:

Markus Metz wrote:

 > > Restrict both raster and vector maps to the 180 degree lon

 > note that the planetary science people prefer to keep lon as 0-360,
 > not -180 thru 180. (search ML archives for "Mars")

The status quo is that both raster and vector maps must stick to the 180 
degree lon limit, this is required by GRASS, it seems. At least 
everything I tried works fine when keeping vector lon values to the 180 
limit.

 > Also, AFAIR, for vector maps d.what.vect report correct land areas for
 > lat/lon polygons. So the vector lib isn't completely lat/lon braindead.

Yes, but playing around here with world shorelines gives me the 
impression that vector operations work better when the coords stick to 
the limits. The libraries really do the wrapping very well!

There is however a problem with the new vdigit, lines and borders are 
not displayed properly when the window is set to East = 170W and West = 
170E. The old tcltk v.digit displays lines and borders properly.