[gdal-dev] ogr WFS GML parse error with WFS 1.1.0

Wed Feb 27 11:11:38 PST 2013

Le mercredi 27 février 2013 18:39:23, Jeremy Palmer a écrit :
> No problem at all.
> 
> I'm sure it has something do with the new streaming option in GDAL/OGR
> 1.10. If I run the query with the OGR_WFS_USE_STREAMING config set to NO
> it works:
> 
> ogrinfo --config OGR_WFS_USE_STREAMING NO -dialect sqlite -sql "select id,
> shape from \"v:x1571\" WHERE id = 3241251"
> WFS:'http://wfs.data.linz.govt.nz/84f646e35be34843abd9cee6085b50d6/v/x1571
> /wfs'

This server has a strange behaviour. I've attempted several downloads of 
"http://wfs.data.linz.govt.nz/84f646e35be34843abd9cee6085b50d6/v/x1571/wfs?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=v:x1571&FILTER=%3CFilter%20xmlns%3D%22http:
%2F%2Fwww.opengis.net%2Fogc%22%20xmlns:v%3D%22http:
%2F%2Fdata.linz.govt.nz%2Fns%2Fv%22%20xmlns:gml%3D%22http:
%2F%2Fwww.opengis.net%2Fgml%22%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Eid%3C%2FPropertyName%3E%3CLiteral%3E3241251%3C%2FLiteral%3E%3C%2FPropertyIsEqualTo%3E%3C%2FFilter%3E" 
with just wget

The interesting thing is that there are not identical. One thing that changes 
is the timestamp of course (and if that was the only thing, that would be OK), 
but not only. See :


$ diff -u dump2_reformat.gml dump4_reformat.gml

--- dump2_reformat.gml	2013-02-27 19:42:32.574353029 +0100
+++ dump4_reformat.gml	2013-02-27 20:01:56.164665700 +0100
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<wfs:FeatureCollection xmlns:v="http://data.linz.govt.nz/ns/v" 
xmlns:ogc="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xlink="http://www.w3.org/1999/xlink" 
xmlns:ows="http://www.opengis.net/ows" xmlns:wfs="http://www.opengis.net/wfs" 
numberOfFeatures="1" timeStamp="2013-02-27T18:38:34.794Z" 
xsi:schemaLocation="http://www.opengis.net/wfs 
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd http://data.linz.govt.nz/ns/v 
http://wfs.data.linz.govt.nz/84f646e35be34843abd9cee6085b50d6/v/x1571/wfs?service=WFS&version=1.1.0&request=DescribeFeatureType&typeName=v%3Ax1571">
+<wfs:FeatureCollection xmlns:ogc="http://www.opengis.net/ogc" 
xmlns:g="http://data.linz.govt.nz/ns/g" xmlns:wfs="http://www.opengis.net/wfs" 
xmlns:v="http://data.linz.govt.nz/ns/v" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:r="http://data.linz.govt.nz/ns/r" xmlns:ows="http://www.opengis.net/ows" 
xmlns:gml="http://www.opengis.net/gml" 
xmlns:xlink="http://www.w3.org/1999/xlink" numberOfFeatures="1" 
timeStamp="2013-02-27T18:59:47.339Z" 
xsi:schemaLocation="http://www.opengis.net/wfs 
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd http://data.linz.govt.nz/ns/v 
http://wfs.data.linz.govt.nz/84f646e35be34843abd9cee6085b50d6/v/x1571/wfs?service=WFS&version=1.1.0&request=DescribeFeatureType&typeName=v%3Ax1571">
   <gml:featureMembers>
     <v:x1571 gml:id="x1571.3241251">
       <v:id>3241251</v:id>
@@ -10,8 +10,8 @@
       <v:land_district>Southland</v:land_district>
       <v:calc_area>10104190696</v:calc_area>
       <v:shape>
-        <gml:MultiPolygon srsDimension="2" srsName="urn:x-
ogc:def:crs:EPSG:4167">
-          <gml:polygonMember>
+        <gml:MultiSurface srsDimension="2" srsName="urn:x-
ogc:def:crs:EPSG:4167">
+          <gml:surfaceMember>
             <gml:Polygon srsDimension="2">
               <gml:exterior>
                 <gml:LinearRing srsDimension="2">
@@ -184,8 +184,8 @@
                 </gml:LinearRing>
               </gml:interior>
             </gml:Polygon>
-          </gml:polygonMember>
-        </gml:MultiPolygon>
+          </gml:surfaceMember>
+        </gml:MultiSurface>
       </v:shape>
     </v:x1571>
   </gml:featureMembers>

As you can see in one download it uses gml:MultiPolygon and in a next one 
gml:MultiSurface !

There's a mechanism in /vsicurl_streaming/ that caches the first megabyte of 
each URL. If in one download it get the opening tag of gml:MultiPolygon and in 
a following one the closing tat of gml:MultiParse, this certainly explains the 
XML parsing error...

The only solution is then to have a less aggressive caching that will discard 
any segment of cached data when the corresponding download is stopped, so not 
to cause chaos if it is restarted later with different content. There's of 
course a risk it will have some impact on performance when OGR drivers will 
open successively the file, but that might be the only reliable option.

> 
> Cheers,
> Jeremy
> 
> > Sorry, I have no idea about that. I am not a developer but just a
> > somewhat experienced user and if something works it is legal enough for
> > me. I have a feeling that this GML is OK because it looks pretty much
> > similar to what Geoserver WFS is sending out, because GDAL can read it
> > OK if first saved on disk and because Kosmo GIS can also read data from
> > v:x1571 feature type.
> 
> This message contains information, which is confidential and may be subject
> to legal privilege. If you are not the intended recipient, you must not
> peruse, use, disseminate, distribute or copy this message. If you have
> received this message in error, please notify us immediately (Phone 0800
> 665 463 or info at linz.govt.nz) and destroy the original message. LINZ
> accepts no responsibility for changes to this email, or for any
> attachments, after its transmission from LINZ. Thank You.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
