OSGeo / gdal

GDAL is an open source MIT licensed translator library for raster and vector geospatial data formats.
https://gdal.org
Other
4.87k stars 2.54k forks source link

ogr2ogr returns points instead of polygons when converting alkis to geojson #7529

Closed pcace closed 1 year ago

pcace commented 1 year ago

hi there, i am trying to convert a gml (alkis) file form here:

https://service.gdi-sh.de/SH_INSPIREDOWNLOAD_AI_CP_ALKIS?service=wfs?version=2.0.0&outputFormat=application%2Fgml%2Bxml%3B%20version%3D3.2&typeNames=cp%3ACadastralParcel&count=10000&bbox=505096.734896758%2C6024840.724533008%2C505896.734896758%2C6025640.724533008&service=WFS&request=GetFeature

to a geojson file.

the problem is that ogr2ogr seems to be not realizing that the geometry are polygons, and not points. so the resulting geojson has only points as geometry.

the way i try to convert it is so: ogr2ogr test.json XtraServerGetFeature.xml -skipfailures

the section in the alkis xml file looks like so:

    <wfs:member>
        <CadastralParcel gml:id="CadastralParcel_011632005003750001__">
            <gml:identifier codeSpace="http://inspire.ec.europa.eu/ids">
                https://registry.gdi-de.org/id/de.sh.inspire.cp.alkis/CadastralParcel_011632005003750001__</gml:identifier>
            <areaValue uom="m2">630.00</areaValue>
            <beginLifespanVersion>2020-09-15T07:17:33Z</beginLifespanVersion>
            <endLifespanVersion nilReason="other:unpopulated" xsi:nil="true" />
            <geometry>
                <gml:Polygon gml:id="o11001.id.120845510.position.Geom_0"
                    srsName="http://www.opengis.net/def/crs/epsg/0/25832" srsDimension="2">
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList>505830.220 6025039.852 505835.047 6025036.873 505843.687
                                6025068.234 505847.376 6025080.374 505851.368 6025092.652 505854.157
                                6025103.042 505853.702 6025103.185 505845.350 6025105.820 505838.975
                                6025107.833 505838.444 6025107.999 505837.323 6025108.353 505836.903
                                6025098.015 505836.342 6025084.285 505835.767 6025070.236 505835.385
                                6025064.493 505835.716 6025063.852 505836.007 6025042.960 505834.928
                                6025042.520 505830.220 6025039.852</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:Polygon>
            </geometry>
            <inspireId>
                <base:Identifier>
                    <base:localId>CadastralParcel_011632005003750001__</base:localId>
                    <base:namespace>https://registry.gdi-de.org/id/de.sh.inspire.cp.alkis</base:namespace>
                </base:Identifier>
            </inspireId>
            <label>375/1</label>
            <nationalCadastralReference>011632005003750001__</nationalCadastralReference>
            <referencePoint>
                <gml:Point gml:id="o11001.id.120845510.ST_PointOnSurface__T_.position__.Geom_0"
                    srsName="http://www.opengis.net/def/crs/epsg/0/25832" srsDimension="2">
                    <gml:pos>505840.905 6025075.305</gml:pos>
                </gml:Point>
            </referencePoint>
            <validTo nilReason="other:unpopulated" xsi:nil="true" />
            <zoning
                xlink:href="https://registry.gdi-de.org/id/de.sh.inspire.cp.alkis/CadastralZoning_011632005" />
        </CadastralParcel>
    </wfs:member>

but the resulting geojson has features like this:

{ "type": "Feature", "properties": 
{ "gml_id": "CadastralParcel_011632005003750001__", "identifier": "https://registry.gdi-de.org/id/de.sh.inspire.cp.alkis/CadastralParcel_011632005003750001__", "areaValue": 630.0, "beginLifespanVersion": "2020-09-15T07:17:33Z", "endLifespanVersion": "", "localId": "CadastralParcel_011632005003750001__", "namespace": "https://registry.gdi-de.org/id/de.sh.inspire.cp.alkis", "label": "375/1", "nationalCadastralReference": "011632005003750001__", "validTo": "", "zoning": "" }, 
"geometry": { "type": "Point", "coordinates": [ 505840.90500000002794, 6025075.304999999701977 ] } }

is this a bug from ogr2ogr or do i miss something?

any help would be awesome!!

jef-n commented 1 year ago

because it has both a point (referencesPoint from ax_flurstueck.objektkoordinaten) and a polygon (position)

rouault commented 1 year ago

@jef-n I see the NAS driver triggers here because "aaa-suite" is found in Inspire .xsd URLs. Is it appropriate here ? When the default GML driver is used instead, the expected behaviour happens because of "In case of multiple geometry occurrences, if a geometry is in a element, this will be the one selected. This will make default behavior consistent with Inspire objects." mentionned in https://gdal.org/drivers/vector/gml.html#geometry-reading

@pcace You might get the behaviour you want by deleting the XtraServerGetFeature.gfs file produced by GDAL, and adding --config OGR_SKIP NAS to your GDAL command line invokations (or setting OGR_SKIP=NAS as environment variable)

jef-n commented 1 year ago

@jef-n I see the NAS driver triggers here because "aaa-suite" is found in Inspire .xsd URLs. Is it appropriate here ? When the default GML driver is used instead, the expected behaviour happens because of "In case of multiple geometry occurrences, if a geometry is in a element, this will be the one selected. This will make default behavior consistent with Inspire objects." mentionned in https://gdal.org/drivers/vector/gml.html#geometry-reading

No, the data is not NAS, but unfortunately there is no reliable way to easily detect whether data is NAS. Maybe we should make NAS_GFS_TEMPLATE mandatory and only evaluate NAS_INDICATOR if it is set. IMHO it doesn't make much sense to work with NAS data w/o the schema.

rouault commented 1 year ago

@jef-n Would it make sense to ship https://github.com/norBIT/alkisimport/blob/master/alkis-schema.gfs in GDAL data/ directory and use it by default (the file hasn't been modified since 2020 so it looks to be relatively stable) ? And require the filename to be prefixed with NAS:, like for the GMLAS driver vs the GML driver.

Actually that could be a mix of your proposal and mine:

jef-n commented 1 year ago

Actually that could be a mix of your proposal and mine:

* if NAS_GFS_TEMPLATE is set, then use NAS_INDICATOR to evaluate if the file is NAS
* if the filename is prefixed with "NAS:", open it unconditionally (NAS_INDICATOR ignored), and if NAS_GFS_TEMPLATE is not set, then use alkis-schema.gfs shipped with GDAL data?

There are going to be two versions of the schema soon (6.0.1 and 7.1.2; 7.x has been around for quite some time, although it is still not used) and both will probably be used for some time - I was planning to ship either one with the corresponding version of alkisimport along with a corresponding database schema for postgis. Those could obviously also be moved to gdal data instead - but there's not going to be a sane default that works for every federal state (although they will probably all eventually use 7.1.2 - or maybe above).

rouault commented 1 year ago

@jef-n Fix proposal in https://github.com/OSGeo/gdal/pull/7532