[gdal-dev] S-57 Driver WRONG Geometry

[Bogdan Grama]

Dear Mike,

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?


Bogdan GRAMA


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.
> --Mike
>
> 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.
>>>
>>>       
>> Folks,
>>
>> I have determined this is the same as the previously reported:
>>
>>   http://trac.osgeo.org/gdal/ticket/2147
>>
>> 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
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>