[GRASS-dev] Re: v.in.gshhs - bogus horizontal lines
Markus Metz
markus.metz.giswork at googlemail.com
Wed Mar 18 04:26:19 EDT 2009
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? If Asia is displayed west of Alaska and Alaska is displayed
east of Asia, the spatial data viewer used (QGIS or MapServer) does wrap
around.
>
> 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, features must be wrapped around so that you
can pan beyond -180 or 180 and everything that is supposed to be there
is displayed, as in GRASS. 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.
Markus M
More information about the grass-dev
mailing list