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