[GRASS-dev] Re: v.in.gshhs - bogus horizontal lines

[Markus Metz]

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.

Markus M