[GRASS-dev] Re: v.in.gshhs - bogus horizontal lines
markus.metz.giswork at googlemail.com
Sun Mar 22 16:06:40 EDT 2009
Maciej Sieczka wrote:
> It's not that every application is different, but that GRASS is
> different than all the rest in this regard - it seems. Again, I'm not
> saying GRASS or you are wrong, but could there be an optional switch to
> constrain GSHHS geometry exactly to -180 - 180 in v.in.gshhs to improve
> GRASS interoperability regarding this? Or is that just too much work or
> not interesting to you?
Well, the previous version restricted all coordinates to -180, 180, and
GRASS displayed it all right, so I thought that's all right.
>> FWIW, I have submitted changes to make the digitizer work, no more
>> horizontal lines there, tested with grass-6.5.
> Thanks for looking into this. I tried it and no more horizontal
> artifacts indeed, but with this modification the data imported with
> v.in.gshhs and exported with v.out.ogr now extend over -180 - 180
> slightly. Please see the attached screendump - violet is a
> -180,180,-90,90 box, green is "crude" GSHHS. Same happens in OpenJump,
> uDig, gvSIG 1.1.2, MapServer.
Yes, that was my workaround to avoid horizontal lines, now the map
extends are -179, 190, roughly. You can check with v.info. BTW, that's
why I don't understand why the screenshot extends beyond -180, it should
extend only beyond 180, i.e. on the right side only.
I looked at other worldwide vector data like world boundaries and found
that a common solution is to e.g. have two polygons instead of one for
Eurasiafrica as in the GSHHS dataset. Eurasiafrica would stop at 180E
with a straight vertical line, and the missing bit would start as a
separate polygon with a straight vertical line at 180W, then going East.
That would be the fool proof solution to avoid horizontal lines. But
then you have vertical lines... Of course everything is technically
possible, and I can modify v.in.gshhs so that it produces straight
vertical lines instead of straight horizontal lines. I'm not really
convinced, however, but don't mind if someone else wants to change this
in v.in.gshhs. As long as the -r flag keeps its current behaviour and
on-the-fly reprojection still works.
More information about the grass-dev