[GRASS-dev] Re: v.in.gshhs - bogus horizontal lines
Maciej Sieczka
msieczka at sieczka.org
Wed Mar 18 16:26:47 EDT 2009
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
More information about the grass-dev
mailing list