search

OSGeo / gdal

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

GML - geometry type and SRS are not detected #6392

Closed pathmapper closed 2 years ago

pathmapper commented 2 years ago

Expected behavior and actual behavior.

For test_ausgleichsflaeche.zip the geometry type and SRS are not detected but all features are having a polygon geometry with srsName="EPSG:25833".

Steps to reproduce the problem.

ogrinfo test_ausgleichsflaeche.gml

1: BP_AusgleichsFlaeche (Unknown (any), Unknown (any))

ogrinfo test_ausgleichsflaeche.gml BP_AusgleichsFlaeche

Layer name: BP_AusgleichsFlaeche
Geometry (symbolPosition): Unknown (any)
Geometry (position): Unknown (any)
Feature Count: 4
Extent (position): (378666.730000, 5714695.641000) - (410604.084000, 5721458.711000)
SRS WKT (symbolPosition):
(unknown)
SRS WKT (position):
(unknown)
Geometry Column 1 = symbolPosition
Geometry Column 2 = position

Operating system

Ubuntu 22.04.1 LTS

GDAL version and provenance

GDAL 3.6.0dev-e10d39568c6ab37077f4b6bc2ee3fb93e1e4d41e, released 2022/06/28 (docker osgeo/gdal:ubuntu-full-latest)

pathmapper commented 2 years ago

Original datasource:

WFS: http://xplanung.lkee.de/xplansyn-wfs/services/xplansynwfs FeatureType: xplan:BP_AusgleichsFlaeche

jratike80 commented 2 years ago

For me on Windows with binaries from gisinternals.com

gdalinfo --version GDAL 3.6.0dev, released 2022/99/99

ogrinfo test_ausgleichsflaeche.gml
ERROR 1: Failed to connect to xplanung.lkee.de port 80 after 21166 ms: Timed out
INFO: Open of `test_ausgleichsflaeche.gml'
      using driver `GML' successful.
1: BP_AusgleichsFlaeche (Polygon)

ogrinfo test_ausgleichsflaeche.gml BP_AusgleichsFlaeche
INFO: Open of `test_ausgleichsflaeche.gml'
      using driver `GML' successful.

Layer name: BP_AusgleichsFlaeche
Geometry: Polygon
Feature Count: 4
Extent: (378666.730000, 5714695.641000) - (410604.084000, 5721458.711000)
Layer SRS WKT:
PROJCRS["ETRS89 / UTM zone 33N",
...
pathmapper commented 2 years ago

@jratike80 that looks good :)

Just built a current docker image locally

sudo docker run --rm -v /home:/home osgeo/gdal:alpine-small-latest ogrinfo --version

GDAL 3.6.0dev-e011e1525a5d05c89bb136eac742a75f677449bf, released 2022/09/19

but the issue remains:

sudo docker run --rm -v /home:/home osgeo/gdal:alpine-small-latest ogrinfo $PWD/test_ausgleichsflaeche.gml

INFO: Open of `/home/user/Documents/elbe/test_ausgleichsflaeche.gml'
      using driver `GML' successful.
1: BP_AusgleichsFlaeche (Unknown (any), Unknown (any))
sudo docker run --rm -v /home:/home osgeo/gdal:alpine-small-latest ogrinfo $PWD/test_ausgleichsflaeche.gml BP_AusgleichsFlaeche

INFO: Open of `/home/user/Documents/elbe/test_ausgleichsflaeche.gml'
      using driver `GML' successful.

Layer name: BP_AusgleichsFlaeche
Geometry (symbolPosition): Unknown (any)
Geometry (position): Unknown (any)
Feature Count: 4
Extent (position): (378666.730000, 5714695.641000) - (410604.084000, 5721458.711000)
SRS WKT (symbolPosition):
(unknown)
SRS WKT (position):
(unknown)
Geometry Column 1 = symbolPosition
Geometry Column 2 = position
jratike80 commented 2 years ago

Right , I had a problem with bypassing our proxy. I fixes that and now GDAL is able to go further with resolving the XML the schema by following the DescribeFeatureType the link of the GML data. I cannot say for sure what happens and if GDAL works as supposed or not but maybe these findings can help you.

For some reason GDAL cannot resolve the XML schema correctly. A workaround with the GML driver is not to analyze the schema but let the driver to read the GML file and build the schema based on the information that the data contains: ogrinfo test_ausgleichsflaeche.gml BP_AusgleichsFlaeche -oo DOWNLOAD_SCHEMA=NO

Notice that ogrinfo now does not list the other geometry "symbolPosition" because it does not appear in the GML data even it is defined in the schema.

Generally speaking the data in the service are complex features. With this request you can see the whole schema: http://xplanung.lkee.de/xplansyn-wfs/services/xplansynwfs?SERVICE=WFS&VERSION=2.0.0&REQUEST=DescribeFeatureType&OUTPUTFORMAT=application%2Fgml%2Bxml%3B+version%3D3.2&TYPENAME=xplan:BP_AusgleichsFlaeche&NAMESPACES=xmlns(xplan,http%3A%2F%2Fwww.deegree.org%2Fxplanung%2F1%2F0))

GML driver is not actually right for complex features ("application schema") even the driver tries to resolve the schema and convert data into simple feature data that GIS programs understand and often does that rather well. The right driver for complex GML would be the GMLAS driver, but unfortunately it cannot resolve this certain XML schema completely. With this command you can see what GDAL tries and what happens ogrinfo gmlas:test_ausgleichsflaeche.gml -oo HANDLE_MULTIPLE_IMPORTS=YES --debug on

The problem is related to this: http://www.opengis.net/gml/3.2:_Feature' not found. I am not good enough with XML schemas and I cannot say if the schema is defined in a wrong way on the server (seems to be a deegree server) side or if the GMLAS driver cannot resolve the schema even if it is valid. Deegree servers are usually good with XML application schemas but application schemas are complicated.

The concrete issue is that the XML schema has loads of lines like this: <element name="FP_VorbehalteFlaeche" substitutionGroup="gml:_Feature"> and GDAL cannot resolve them.

I wonder why this command do not find the srsName even I expected that it would ogrinfo test_ausgleichsflaeche.gml BP_AusgleichsFlaeche -oo FORCE_SRS_DETECTION=YES

jratike80 commented 2 years ago

By https://etutorials.org/Mobile+devices/mobile+location+services/Appendix+B.+Geography+Markup+Language/4+Encoding+GML/ the gml:_Feature is OK

Type names are in mixed case with a leading capital; the names of geometric properties and attributes are in mixed case with a leading lower case character. The names of abstract elements are in mixed case with a leading underscore (e.g. _Feature) to highlight their abstract character.

If you want you can try to find out if gml:_Feature should be found from here <import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>

It may also be that your acute problem with missing SRS and geometry type is caused by some other reason but application schemas are complicated.

rouault commented 2 years ago

Fix queued in https://github.com/OSGeo/gdal/pull/6397. This requires also to specify the FORCE_SRS_DETECTION=YES open option. When a .xsd is found and understood, the GML driver does not do by default an initial scan of the file content to determine the CRS when establishing the schema. The user has to explicitly asks for it.