[gdal-dev] Missing geometry type when using ogr2ogr to write FileGDB

Even Rouault even.rouault at mines-paris.org
Mon Apr 22 10:50:53 PDT 2013


Le lundi 22 avril 2013 16:02:56, Stefan Keller a écrit :
> Hi Jukka and Even
> 
> I also thought about this, i.e. to delay the determination of the geometry
> type check to the first occurrence, in case when the abstract gml:
> GeometryPropertyType has been announced in DescribeFeature.
> 
> I know that QGIS, ArcGIS Desktop and Gaia clients can read the WFS
> mentioned below. And I'm almost sure they don't read the whole data stream
> in order to determine that's a polygon type. It's only OGR in my test suite
> which can't cope with this an needs a manual configuration ("-nlt POLYGON")
> which is no option for me since it's inside an automated script.
> 
> On the other hand and from a higher level perspective something it's clear
> to me: The original feature set (here e.g. svo_zonen) is of type
> gml:Polygon. If the WFS doesn't expose and explain this as gml:Polygon to
> others, there's a problem with this server.

I think that the current behaviour of the OGR WFS driver is perfectly correct. 
A layer with a geometry of GeometryPropertyType could contain any type of 
geometry (even if in practice most servers will only throw the same geometry 
type for all features).
What could be done is to have a "-nlt guess" mode in ogr2ogr, that, in case 
the source layer has an unknown geometry type, would retrieve the first feature 
of the source layer to find the geometry type and create the target layer 
geometry type.

> 
> Yours, Stefan
> 
> 
> 2013/4/22 Jukka Rahkonen <jukka.rahkonen at mmmtike.fi>
> 
> > Even Rouault <even.rouault <at> mines-paris.org> writes:
> > > Yes, when examining the
> > 
> > "
> > http://maps.zh.ch/wfs/FnsNSWFS?TYPENAME=svo_zonen&SERVICE=WFS&VERSION=1.1
> > .0&REQUEST=DescribeFeatureType "
> > 
> > > you can see :
> > >           <element name="msGeometry" type="gml:GeometryPropertyType"
> > > 
> > > minOccurs="0" maxOccurs="1"/>
> > > 
> > > So the geometry type is undefined. OGR then reports a unknown geometry
> > 
> > type.
> > 
> > > There could be a mix of geometries in such a layer.
> > 
> > Just for information, it is not uncommon that WFS servers advertise a
> > general geometry type "gml:GeometryPropertyType" even the layer contains
> > only one geometry type and therefore WFS clients should be aware of this.
> > General geometry type comes more or less automatically when setting up a
> > WFS
> > service on top of Oracle because by default Oracle can hold any
> > geometries in the geometry column. It is possible to set a geometry type
> > constraint when creating a spatial index but it is not important for
> > Oracle and therefore the constraint is often missing. Even if it exists
> > it is a bit complicated to query. For example Geoserver knows how to do
> > this check but GDAL OCI driver does not. If someone gets interested in
> > improving the OCI driver, here is a basic part of the query.
> > 
> > select idxmeta.sdo_layer_gtype from all_sdo_index_info idxinfo,
> > all_sdo_index_metadata idxmeta
> > where idxinfo.index_name=idxmeta.sdo_index_name
> > and idxinfo.table_name='TABLE_NAME'
> > 
> > If WFS client cannot handle mixed geometry types on one layer then it
> > could perhaps take the first not empty geometry from the WFS response
> > and initiate
> > the layer to use that geometry type. To be on a safe side it might create
> > a multipolygon or multilinestring layer even if the first feature is
> > simple. Another geometry type appearing later in the data will lead to
> > an error but it cannot be avoided anyway if client cannot handle mixed
> > layers.
> > 
> > -Jukka Rahkonen-
> > 
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev


More information about the gdal-dev mailing list