Selon Ari Jolma <ari.jo...@gmail.com>: > Even, > > Another strange thing with GDAL WFS driver. Earlier it did not try to > access the HEAD of a XXX.resolved.gml and now it does: > > Here's an excerpt from my server logs. These calls are created by GDAL, > the first is a good GetFeature call, which gets 215633 bytes of GML and > the next is bogus. I can see this made up in ogrgmldatasource.cpp but do > not understand why. In February this did not happen and GDAL parsed the > GML the WFS provided fine (it actually created by GDAL too). > > 213.157.86.72 - ajolma [21/May/2013:00:02:56 +0300] "GET > /OILRISK-protected/wfs.pl?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=OILRISK.vtest.geom > HTTP/1.1" 200 215633 > 213.157.86.72 - ajolma [21/May/2013:00:02:58 +0300] "HEAD > /OILRISK-protected/wfs.pl?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=OILRISK.vtest.resolved.gml > HTTP/1.1" 200 - > > Do you have an idea what's going on here?
Ari, I don't remind a recent change that might have affected this (but my memory can be fragile), but reviewing the GML driver code, the fact that .resolved.gml is probed means that the GML driver doesn't recognize the first bytes of the GetFeature response to be a GML WFS document. Could you paste them ? My hypothesis would be that the FeatureCollection root element is in a XML namespace different from none, gml or wfs. Does the probing of .resolved.gml, apart from slowing down the process, prevent the driver to parse the GetFeature document ? I think it should not, but there might be subtle issues since it will probably not use the schema obtained with DescribeFeatureType to return the GML layer. Even _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
