Markus Metz pisze:
Maciej Sieczka wrote:Markus Metz pisze:
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?
Because it does not happen in GRASS:-) and because latlon is not a true projection and because IMHO this is a nice feature and because other GRASS developers have thought long about how to handle latlon in lib/gis and I see no reason to question the current solution.
Yet this nice feature makes it problematic to use v.in.gshhs output outside GRASS, no matter if "GRASS approach" is better or not. I have checked in OpenJump 1.2F, uDig 1.1.1, QGIS SVN trunk, gvSIG 1.1.2, UMN MapServer 5.2.0. All these apps render the full-extent GSHHS data imported with v.in.gshhs and exported with v.out.ogr with those horizontal artifacts. In order to have the best of the two worlds could v.in.gshhs provide a switch that would force the imported data to be contained exactly within -180 - 180 longitudal extent? I.e. trim the borders exactly at -180 and 180?
What about other world-wide CRSs, like those based on sinusoidal, Goodge, Mercator projections - does GRASS wraps world edges for them as well?
No idea, you can check.
I'll try when I find time.
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
Yes for 1, can't say for 2, No for 3. AFAICT, v.out.ogr itself does not produce these horizontal lines, they are produced by the application rendering the vector. Different applications have different, often incompatible policies, therefore it is not possibleto accommodate every application. Either the GRASS display is 100%ok or digitizing is 100% ok, both is not possible with the full dataset. Actually, the mere display is always ok, but zooming to the selected map may or may not work. It does not work when the longitude map extends are > 360, but then the digitizer works... QGIS insists on straight lines also without wrap around in v.in.gshhs. It seems that QGIS wraps coordinates beyond -180 and 180 around into the -180, 180 range, then may draw these horizontal lines, and restricts the display area to -180, 180. I want v.in.gshhs to produce output that is compatible with GRASS, and there I stop because it is not possibleto accommodate every application (see also r.out.gdal discussion).
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?
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. Maciek -- Maciej Sieczka http://www.sieczka.org
<<inline: gshhs.png>>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
