On 05/21/2013 10:57 AM, Even Rouault wrote:
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 ?
<?xml version="1.0" encoding="utf-8" ?>
<ogr:FeatureCollection
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://ogr.maptools.org/ .xsd"
xmlns:ogr="http://ogr.maptools.org/";
xmlns:gml="http://www.opengis.net/gml";>
<gml:featureMember>
<ogr:vtest_geom_ fid="vtest_geom_.0">
<ogr:geometryProperty><gml:Point
srsName="EPSG:3067"><gml:coordinates>185607.11328746471554,6718884.468898030929267</gml:coordinates></gml:Point></ogr:geometryProperty>
<ogr:id>6483</ogr:id>
</ogr:vtest_geom_>
</gml:featureMember>
...
My
hypothesis would be that the FeatureCollection root element is in a XML
namespace different from none, gml or wfs.
It seems to be in ogr (it's made by GDAL). I'll try changing that.
Does the probing of .resolved.gml, apart from slowing down the process, prevent
the driver to parse the GetFeature document ?
yes, the resolved.gml is not older than the GetFeature doc, thus it is
used and found to be empty. I commented that out but it still can't
parse the features.
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.
It is using the schema it got from DescribeFeature.
About the OpenSSL problem. I can probably bypass it by using only Curl
(there are Perl bindings to Curl)
Ari
Even
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
