Note that the same logic should be applied to the spatial features, if
these are handled (i.e. RETURN_PRIMITIVES=ON).
And for feature-feature links, i.e. RETURN_LINKAGES=ON
Thank you all for your explanations.
I'm sad that this is a mistake in the doc :-) because as you pointed out S57
spec
Thank you all for your explanations.
I'm sad that this is a mistake in the doc :-) because as you pointed out S57
spec has no GUID definition. With the combination of the LNAM + DSNM, it
allowed to have one that would be convenient in a PostGIS database that
contains many S-57 charts.
On my fo
DSNM is dataset name. I'ts defined in the DSID which only occurs in the
first field/subfield group in the dataset - not sure what the driver does
in respect of it. In terms of identifiers s-57 has "FOID"s, so each feature
has a unique id made up of a combination of the agency code and two
integers
On dimanche 3 mai 2020 09:54:22 CEST kusala nine wrote:
> DSNM is dataset name. I'ts defined in the DSID which only occurs in the
> first field/subfield group in the dataset - not sure what the driver does
> in respect of it.
Right. The driver doc was incorrect. I've just fixed it per
https://gith
Hi
I have not checked the GDAL implementation but DSNM is an unneccessary
addition to the S57 spec to generate a (potential unique) GUID.
S57 spec has no GUID definition, IDs needs only be to unique inside a
dataset/ENC cell.
DSNM belongs to the dataset-wide DSID fields, see 6.3.2 in
https:/
Hello,
After reading this documentation concerning the S-57 driver :
https://gdal.org/drivers/vector/s57.html
I thought the attribute DSNM ( Dataset name) should be defined on all features,
no ?
But on the source code, the method S57GenerateStandardAttributes
(s57featuredefns.cpp) always a