Closed pcace closed 1 year ago
because it has both a point (referencesPoint from ax_flurstueck.objektkoordinaten) and a polygon (position)
@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
@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 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.
@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:
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).
@jef-n Fix proposal in https://github.com/OSGeo/gdal/pull/7532
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:
but the resulting geojson has features like this:
is this a bug from ogr2ogr or do i miss something?
any help would be awesome!!