[gdal-dev] WFS driver, ogrinfo and GetFeature

Even Rouault even.rouault at mines-paris.org
Mon Dec 19 08:55:49 EST 2011


Selon Jukka Rahkonen <jukka.rahkonen at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>




More information about the gdal-dev mailing list