Markus Metz pisze:
Maciej Sieczka wrote:
I personally like the way QGIS or MapServer handles it - they just
don't care and don't try to treat lat-long data as connected at
the datum border.
So they stop displaying maps beyond -180 or 180? West of Alaska is
nothing?
Yes.
This has the major plus that in those applications there is no
problem with manual browsing/editing world-wide lat-long data. One
can pan and zoom just like in any other coordinate system and the
display coordinate extent is not restricted.
I thought this is true for GRASS. Generally, if you zoom/pan beyond
the extend of the feature (raster or vector), nothing is displayed.
This should not happen in latlon,
Why not?
features must be wrapped around
Why?
so that you can pan beyond -180 or 180 and everything that is
supposed to be there is displayed, as in GRASS.
What about other world-wide CRSs, like those based on sinusoidal,
Goodge, Mercator projections - does GRASS wraps world edges for them as
well?
Spatial data viewers/editors can not treat latlon like any other
(like a proper) projection.
GRASS automatic wrapparound is a feature that brings more troubles
than benefits to developers and users IMHO.
There are two distinct issues, once the wrap around and once the
restriction to -180 - 180 (causing wrap around of parts of a geometry
feature only). They are connected but not identical. The horizontal
lines are caused by the -180 - 180 restriction, not the wrap around.
BTW, the restriction does not cause problems with rasters, in GRASS
I can create a raster with West = 170 and East = -170, i.e. West >
East, this is displayed properly as one block. It becomes difficult
with vector features, because many operations would need to handle
latlon different from proper projections, i.e. in this case wrap
around, make sure lon differences are not > 180, run select by bbox
twice etc. Currently the vector libs treat latlon pretty much like a
proper projection, IMHO not a perfect solution. I'm not going to
change current GRASS behaviour for vector handling in latlon on my
own, this needs to be discussed by some more people before such
drastic changes (from a user perspective) are introduced because it
is about the general policy on how to cope with latlon.
Is there anything that could be done for v.in.gshs in GRASS 6.5 so that
it's output (when the input is a full GSHHS extent) would be free of the
horizontal longitudal extent-wide artifacts in case of:
1. editing in v.digit
2. exporting with v.out.ogr (that's another issue I haven't mentioned yet)
3. displaying and editing in QGIS
?
Maciek
--
Maciej Sieczka
http://www.sieczka.org
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
