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

David FERDOILLE david.ferdoille at gmail.com
Sat Mar 4 07:12:03 PST 2017


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 ?


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.


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...


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.
>
>     4-
>
>     In ogrinfo -oo "RETURN_PRIMITIVES=ON" -oo "RETURN_LINKAGES=ON" -oo
>     "LNAM_REFS=ON" file.000 M_QUAL, I found 20 objects, but QUAPOS is
>     null for all of them.
>
>     5-
>
>     No M_ACCY table is present in my dataset.
>
>     According to me, the good way to get these attributes, is the
>     second one (2-), but even if I try a lot of things, I didn’t
>     manage to :
>
>     -Trying all the S57 option with –oo
>
>     -Trying to change the CSV types and attributes catalog used by GDAL
>
>     -Etc…
>
>     Does someone know if it is possible to get these attribute through
>     GDAL/OGR ?
>
>     If not, is there another way to get this attributes (python GDAL
>     scripts ? another command line software ?)
>
>     Thanks again for your help !
>
>
>     Regards
>
>
>     David
>
>
>     2016-07-29 11:31 GMT+02:00 teddy guerin <teddyguerin at yahoo.fr
>     <mailto:teddyguerin at yahoo.fr>>:
>
>         Hi,
>         Up for my previous answer.
>         I was wrong for lines and area values POSACC, QUAPOS are on
>         edges and not on "real object".
>
>         Regards
>         Ted
>
>
>         ------------------------------------------------------------------------
>         *De :* David Ferdoille <david.ferdoille at gmail.com
>         <mailto:david.ferdoille at gmail.com>>
>         *À :* gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>         *Envoyé le :* Mercredi 27 juillet 2016 15h12
>         *Objet :* [gdal-dev] OGR - S57 - geometry extraction issue
>
>         Hello all,
>
>         We are trying to render S57 files as ENC through Geoserver.
>
>         We convert S57 to shapefiles thanks to ogr2ogr : 1 shapefile
>         for 1 class (ex : COALNE) and 1 geometry type (LINE) :
>         ogrinfo -oo "RETURN_PRIMITIVES=ON" -oo "RETURN_LINKAGES=ON"
>         -oo "LNAM_REFS=ON" CELLLL.000 COALNE
>         ogr2ogr -skipfailures  -where "OGR_GEOMETRY='POINT' or
>         OGR_GEOMETRY='MULTIPOINT'" SOUNDG_points.shp CELLLL.000 SOUNDG
>
>         We use gdal-2.1.0 with the S57_CSV environnement variable
>         (S57_CSV=/usr/local/share/gdal/ with s57*.csv files).
>
>
>         We noticed that objects (of COALNE class for example) have
>         multiple geometries and each sub-geometry have attributes like
>         POSACC and QUAPOS which are important for S52 representation.
>         We've succeeded to extract primitives (Edge, isolated points,
>         connected points, ...), but it looks very complex to operate.
>
>
>         We have some problems to extract geometries from s57 objects :
>         - we noticed that, for an object, all sub-geometries are
>         aggregated to one geometry
>         - we didn't succeed to extract geometry attributes like POSACC
>         and QUAPOS
>
>
>         1) Is there a way to not aggregate sub-geometries of an object
>         and get this list of sub-geometries ?
>         2) Is there a way to extract geometry attributes like POSACC
>         and QUAPOS ?
>         3) If not, are these features planned ?
>
>
>         Thanks for your help !
>
>
>         David
>
>         _______________________________________________
>         gdal-dev mailing list
>         gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>         http://lists.osgeo.org/mailman/listinfo/gdal-dev
>         <http://lists.osgeo.org/mailman/listinfo/gdal-dev>
>
>
>
>
>     _______________________________________________
>     gdal-dev mailing list
>     gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/gdal-dev
>     <http://lists.osgeo.org/mailman/listinfo/gdal-dev>
>



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170304/e394f687/attachment-0001.html>


More information about the gdal-dev mailing list