Selon Jukka Rahkonen <jukka.rahko...@mmmtike.fi>: > Hi, > > If user wants to read a summary of a certain WFS feature type with a command > like > > ogrinfo -ro -so WFS:http://server.com/wfs ns:typeName > > GDAL seems to send then four separate commands: > > First: > SERVICE=WFS&REQUEST=GetCapabilities&ACCEPTVERSIONS=1.1.0,1.0.0 > Second: > SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&TYPENAME=[list of all > the > typenames in the whole service] > Third: > SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=ns:typeName&RESULTTYPE=hits > Fourth: > SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=ns:typeName > > Questions: > - Why to send DescribeFeatureType for all the feature types when user is only > interested in the named one "ns:typeName"?
This an optimization for the case where you want to read several layers. I've observed that the cost of a DescribeFeatureType request with N feature types is generally significantly cheaper than the cost of N request with one feature type. Of course, there are situations like the above where you don't win. But you cannot always win, right ? (and the WFS driver cannot know that ogrinfo will only request one layer) > - Is is necessary to send the fourth request and read the whole layer from > the > service? I guess it is because GDAL wants to see the real geometries so it > can > calculate correct extents for the layer but it can be quite a heavy load for > the > WFS server. Correct, this is necessary to get the extent. > > In fact the following line leads to an ultimate query "get everything that > exists in the WFS service" > > orginfo -al -so WFS:http://server.com/wfs > > This will make one by one full GetFeatures for all the feature types in the > whole service. My service has 55 feature types and many of them has more than > million features and ogrinfo will probably fail if my server won't fail > earlier > with sending a few gigabytes of GML. I consider it a little bit dangerous > that > users can send such requests accidentally. I think that at least users should > especially do something before GDAL would create the fourth request, the > plain > GetFeature. Not much can be done : there's no way to make interact the user with the driver and ogrinfo doesn't know which requests are expensive or not. Perhaps one could have a cheaper implementation of GetExtent() based on what is in the GetCapabilities response. But AFAIR, you only get the bounding box in latitude/longitude, even if the default SRS is something else. One could try to reproject the lat/long bounding box into the target SRS, but that might be inaccurate in some cases, not to say plainly wrong (consider UTM zone 60, polar projections, etc...). Even in the case where the SRS is EPSG:4326, I've avoided to use the advertized bounding box because of uncertainty about what the coordinate order should be, and how WFS servers have understood or misunderstood the spec (see ticket http://trac.osgeo.org/gdal/ticket/4041 for more details). In the meantime, you could just comment the line in ogrinfo that calls GetExtent(). > > -Jukka Rahkonen- > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
