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...
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
