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