[gdal-dev] S-57 Driver WRONG Geometry

[ogr user]

Sevencs succeed in many other aspects where others fail.

For example, they will actually parse and show older Netherlands chart
data (I still have a few cells from a year ago), which encoded polygon
edges using multiple SG2D fields, rather than a single SG2D field with
multiple values. Not only that, but even once I modified s57 reader to
support that, those polygons could not be reassembled using the "vertex
proximity" approach as used by GDAL. Yet Sevencs could read those files
and show them reasonably well. Still have no idea how they did that - I
could not come up with a reasonable method, and I tried a few.

You can do a lot by building specific heuristics into a product that
adjust the way it handles data based on certain guesses. Whether that is
a good practice I don't know - I certainly don't think so. Ultimately,
it appears that Netherlands decided to reencode their data - and the
current data set is properly readable by GDAL.

That may be a moot point if you have a user that absolutely *must use
that chart* no matter how badly encoded it is, so Sevencs have a good
practical approach there, I guess. But generating data as closely
following the standard as possible is better, if you ask me.

--Mike

Bogdan Grama wrote:
> 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?
>
>
>