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

[Maciej Sieczka]

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 possible
>  to 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 possible
>  to 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gshhs.png
Type: image/png
Size: 8150 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20090322/1dbc5a29/gshhs-0001.png