[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?


>> 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


> 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

> 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



Maciej Sieczka

More information about the grass-dev mailing list