[gdal-dev] Issues with WFS driver

[Even Rouault]

Le samedi 25 mai 2013 11:04:42, Ari Jolma a écrit :
> On 05/25/2013 11:44 AM, Even Rouault wrote:
> > Hi Ari,
> > 
> >> Another thing related to streaming mode.
> > 
> > I fail to see how below is related to streaming mode... This is a generic
> > behaviour of the GML driver
> 
> Because it appears when GDAL uses the DescribeFeatureType request's
> output as a gfs...(?) maybe, I think :)

If the GML driver detects that the file passed to it is a WFS GetFeature 
document and that it is opened through /vsicurl_streaming/ , yes it cannot 
access the schema other by using the DescribeFeatureType document indicated in 
the schemaLocation property of the top XML element. So if the 
DescribeFeatureType document indicates a geometry name inconsistant with the 
one of the GML, this can likely cause issue.

> 
> >> I was wondering why the geometries the WFS were not being parsed by the
> >> client. It turns out that GDAL uses the tag "geometryProperty" by
> >> default (ogrgmllayer.cpp:601). The WFS I have uses the field name from
> >> PostGIS when replying to the DescribeFeatureType request. So I need to
> >> add a hack to the server to always use the "geometryProperty" tag.
> >> 
> >> This seems to be a small deficiency in GDAL; that it doesn't have the
> >> concept of a field name for geometries. This may limit the usability of
> >> GDAL as a component of a WFS.
> > 
> > The issue is that, as far as I've understood, you use a schema not
> > generated by the GML driver with GML output generated by the GML driver.
> 
> Could the driver do it? Ok, I see InsertHeader method in
> OGRGMLDataSource class, which would perhaps be the one to do it, but it
> is probably not open in the bindings. Which is why I used Perl tools to
> query PostGIS and reply to DescribeFeatureType request.

If you output to a regular file, the GML driver will generate a .xsd file with 
the schema alongside the GML file. If you output to /vsistdout/ directly, then 
of course it is not possible to generate the .xsd file.
If you don't want to write on the filesystem, an alternative would be to output 
to /vsimem/ so that you can read both files afterwards.
Another way if you want to use the .xsd generated by the GML driver and keep 
the advantage of using streaming to vsistdout, would be to:
1) Output to /vsimem/ , create the layer definition, but write 0 feature. You 
just fetch the .xsd that can be used for DescribeFeatureType
2) Output to /vsistdout/ with all the needed features.

> 
> > OGR layers have a concept of GetGeometryColumn(), in read mode. The GML
> > driver is able to read a GML whose geometry name is not
> > "geometryProperty". What could be done is to add a layer creation option
> > to specify a geometry name instead of the default "geometryProperty".
> > Would you be interested in that ?
> 
> I think the right thing to do would be to open the schema methods to the
> bindings. But then it would be first needed in the OGR C API. But is the
> schema method a generic thing for a DataSource and thus something for
> the API? Hm.

Seems a bit too specific to make it available at the OGR C API level. The trick 
I mentionned above should be a workaround.

But as I'm not in front of your computer, I'm not really sure to have 
understood your whole setup...

> 
> Ari
> 
> >> Ari
> >> 
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html