Markus Metz pisze:
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.
We seem to be using same terms for different things. By "restricted",
"constrained", "limited" to -180 - 180 I mean no feature extends over
-180 or 180 longitude vertical line. I.e that e.g. Alaska is split into
2 pieces.
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's exactly what I meant from the beginning :). Till now I've been
achieving this using a combination of GRASS vector modules, awk and
manual editing, but that's pretty tedious and error prone.
That would be the fool proof solution to avoid horizontal lines. But
then you have vertical lines...
If you decide it's worth your time to provide that *as an option* in
v.in.gshhs it'd be cool.
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.
Maciek
--
Maciej Sieczka
http://www.sieczka.org
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
