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 [email protected]) 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
