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" <[email protected] <mailto:[email protected]>> 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 <[email protected]
    <mailto:[email protected]>>:

        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 <[email protected]
        <mailto:[email protected]>>
        *À :* [email protected] <mailto:[email protected]>
        *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
        [email protected] <mailto:[email protected]>
        http://lists.osgeo.org/mailman/listinfo/gdal-dev
        <http://lists.osgeo.org/mailman/listinfo/gdal-dev>




    _______________________________________________
    gdal-dev mailing list
    [email protected] <mailto:[email protected]>
    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
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to