[gdal-dev] S-57 Driver WRONG Geometry
bogdan.grama at soft-union.ro
Mon May 31 02:25:43 EDT 2010
I could not agree more. But, if u parse the sample ENC, you will see
that for the ROADWY layer:
---->NAME_RCNM = (10:130,130,130,130,130,130,130,130,130,130)
---->NAME_RCID = (10:114,103,89,97,99,112,111,108,110,124)
---->ORNT = (10:1,1,1,1,1,1,1,1,1,1)
---->USAG = (10:255,255,255,255,255,255,255,255,255,255)
---->MASK = (10:2,2,2,2,2,2,2,2,2,2)
So, no masking :). Now the Question is this: How Sevencs succeeds
showing the correct representation, where all others fail?
On 5/30/2010 6:00 AM, ogr user wrote:
> Correct me if I am wrong (I might be) but my reading of S-57 standard
> (section 4.7 and thereabouts) is such that it does not provide for
> multi-line geometries. Instead, it is suggested that if certain edges of
> a line have to be "invisible" they should be masked by using appropriate
> attribute. I have to admit that I haven't seen that used in major data
> sets (NOAA, UK, various european) either. In any case - while it is
> certainly possible to store multiple "not really connected" edges for a
> given feature, this does not seem to be something that S-57 standard
> permits or provides for.
> By the same token, standard is being quite specific about not permitting
> multiple polygons in the single area feature (though they do provide for
> "holes" in a given polygon).
> FWIW I would consider an S-57 ENC using such line structure to be not
> well formed. Just my 5 cents.
> Frank Warmerdam wrote:
>> Bogdan Grama wrote:
>>> Dear Frank
>>> Please find in the archive (http://www.wgs.ro/gdal/0_w.zip):
>>> -the ENC
>>> -GDAL Interpretation
>>> -correct Interpretation
>>> The assembled geometry is not according with specifications. Each
>>> referenced edge starts and ends with a ConnectedNode. Not all the
>>> Connected nodes are present in the feature geometry dump.
>>> This is not all. If the file is rendered with Sevencs
>>> (http://www.sevencs.com/service-products/download) and few others
>>> viewers the rendering is correct.
>>> For GDAL, ESRI FME, Caris the geometry is not correct.
>> I have determined this is the same as the previously reported:
>> for which I neglected to apply the patch. I have revised the patch
>> and applied it in trunk and 1.7 branch.
>> Best regards,
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
More information about the gdal-dev