[GRASS-dev] latlon support

[Markus Metz]

Glynn Clements wrote:
> Markus Metz wrote:
>
>   
>> I think my questioning started because the region settings including map 
>> extends are restricted to the 180 degree lon and 90 degree lat limits 
>> whereas vector operations can exceed these limits causing problems later 
>> on. To make grass handling of latlon coordinates consistent all around, 
>> either the limits on region settings must be relaxed (taking care of all 
>> the associated risks) or latlon vector coords must be forced into the 
>> latlon limits by some lower-level handling.
>>     
>
> Alas, it isn't just the coordinates, but the topology. E.g. for
> Antartica, you have to add south, east and west edges to get a closed
> region in Euclidean space.
>   
I think the poles and the datum border are two different problems, 
correct me if I'm wrong.
Using the GSHHS shorelines, topology seems to be ok for Eurasiafrica 
when I create a proper area with centroid. At least building topology 
does not report errors and the display is ok. Not so for Antarctica, 
both topology and display are wrong. For Antarctica a different 
projection is needed.
A rather crude description of what we see when we use latlon is a plane 
created by putting an axis through the poles and then folding the globe 
open along the datum border. Therefore I guess it is less of a problem 
to traverse the datum border because the axis has been set first, then 
the folding-up longitude. Maybe the location of the axis is crucial and 
determines the degrees of freedom for moving around in this 
pseudo-projection (only the latter one of two determinants allows 
changing, the one set last, longitude).
>   
>> The currently allowed mix is confusing.
>>     
>
> Indeed.
>   

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