[gdal-dev] OGR - S57 - geometry extraction issue

[Even Rouault]

On samedi 4 mars 2017 16:12:03 CET David FERDOILLE wrote:
> Hi,
> 
> I'm sorry, I didn't have any time to work on integrating s57 data to
> geoserver through ogr during several months but I got time to work on it
> last month.
> 
> The main issue : objects may be composed of multiple primitives
> (isolated node or edge) with geometric attributes like posacc or quapos
> but ogr makes a aggregation of geometries and ignore those geometric
> attributes.
> 
> We succeed to manage this issue by this process :
> 1) extract all classes to shapefile with all relations between objects
> and primitives
> 
> ogr2ogr
> -oo "RETURN_PRIMITIVES=ON"
> -oo "RETURN_LINKAGES=ON"
> -oo "LNAM_REFS=ON"
> -nlt "MULTILINESTRING"
> -where "OGR_GEOMETRY='LINESTRING' or  OGR_GEOMETRY='MULTILINESTRING'"
> -fieldTypeToString IntegerList
> cell-class-line.shp
> cell.000
> class
> 
> 
> 2) extract all primitives to shapefile with a s57-reader modification
> which return posacc and quapos values
> 
> ogr2ogr
> -oo "RETURN_PRIMITIVES=ON"
> -oo "RETURN_LINKAGES=ON"
> -oo "LNAM_REFS=ON"
> -nlt "MULTIPOINT"
> -skipfailures
> cell-isolatednode-point.shp
> cell.000
> IsolatedNode
> 
> To get posacc and quapos attributes, the S57Reader::ReadVector function
> was modified, can I propose the modification to the community on github ?

Yes, please do so.

> 
> 
> 3) integrate all shapefiles in a PostgreSQL/PostGIS database and work on
> it to construct all objects-subgeometries with 'name_rcnm' and
> 'name_rcid' to obtain a database compatible with geoserver.
> 
> 
> During my tests, I found some differences between s57attributes.csv,
> s57objectclasses.csv and the s57 reference (on www.s-57.com
> <http://www.s-57.com> for example), I will propose the update on github.

Thanks. Note that in trunk I've a few weeks ago merged the _aml and _iw files into the main 
one.

> 
> 
> Moreover, I was confronted with the TEMP_BUFFER_SIZE of ogrfeature when
> converting IntegerList to String because some objects have many
> subgeometries and the result is truncated (finishing by '...)') and not
> exploitable. The limit is 80 characters, I tried to increase to 254 (max
> string length in shp) but it's not enough in some cases : for now, I
> just log the complete Integerlist in stderr and I handle all errors... I
> tried the splitlistfield option but it's not very easy to exploit...

There will be no perfect solution if you output to shapefiles. Did you try to SQLite or 
Spatialite ? IntegerList are properly supported there.

> 
> 
> Regards
> 
> 
> David
> 
> Le 07/12/2016 à 22:00, Mike a écrit :
> > David, did you ever figure this one out? I've run into the same
> > situation, where I need the spatial attributes.
> > 
> > -Mike
> > 
> > On Aug 12, 2016 1:32 AM, "David Ferdoille" <david.ferdoille at gmail.com
> > 
> > <mailto:david.ferdoille at gmail.com>> wrote:
> >     Hello,
> >     
> >     
> >     Thanks for the responses,
> >     
> >     After a long afternoon of tests :
> >     
> >     I try to access a WRECKS object, compose by an only point, with a
> >     QUAPOS specific value of 5, and an POSACC of 500.0 (find it using
> >     CARIS Easy View)
> >     
> >     1-
> >     
> >     In ogrinfo -oo "RETURN_PRIMITIVES=ON" -oo "RETURN_LINKAGES=ON" -oo
> >     "LNAM_REFS=ON" file.000 WRECKS, I found the object, but no QUAPOS
> >     or POSACC (logical because the 2 attributes are not directly
> >     linked to the object, but to the geometry).
> >     
> >     2-
> >     
> >     In ogrinfo -oo "RETURN_PRIMITIVES=ON" -oo "RETURN_LINKAGES=ON" -oo
> >     "LNAM_REFS=ON" file.000 IsolatedNode, I found the node
> >     representing the object but also no QUAPOS or POSACC.
> >     
> >     3-
> >     
> >     In ogrinfo -oo "RETURN_PRIMITIVES=ON" -oo "RETURN_LINKAGES=ON" -oo
> >     "LNAM_REFS=ON" file.000 M_QUAL, I found an only object, spatially
> >     containing my wreck object, but POSACC is null.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170304/06d8bf58/attachment-0001.html>