[gdal-dev] Re: Are these WFS issues worth filing tickets?
jukka.rahkonen at mmmtike.fi
Thu Jan 12 04:57:37 EST 2012
Even Rouault <even.rouault <at> mines-paris.org> writes:
> > > I don't want to deny there is a problem when issuing ogrinfo, but I'm not
> > > sure that setting a default MAXFEATURES on client side is appropriate.
> > > The issue is more with GetExtent() and the fact that the reported extent
> > > in GetCapabilities is reported as WGS84 and not in the default SRS, or
> > > that the values are sometimes junk.
> > Sure they are often junk but doing getFeature is an expensive way for
> > getting the correct information. Ald also this result may be unreliable if
> > it is interpreted to describe the whole WFS feature type it getFeature
> > request hits the server side maxFeatures limit. In this case ogrinfo can
> > only report the extents of the first [maxFeatures] of the feature type.
> > How about having an option -TRUST_GETCAPABILITIES=TRUE and use it as
> > a default value? So number of feature could be examined with
> > resulttype=hits and extents could be taken as they are in the
> > getCapabilities. Or perhaps they could be reported as unknown if
> > reprojecting the lat/lon bounding box feels bad or is
> > inaccurate/impossible? Extents are not always so interesting.
> I also somehow imagined that. Perhaps you could file a ticket about that,
> can be eventually considered later.
I filed a ticket #4434 http://trac.osgeo.org/gdal/ticket/4434. It did not
get immediate acceptance for understandable reasons because ogrinfo is a
general tool which treats all the data sources in a similar way. However,
WFS is a web service and it has some differences to other data sources.
Network connection to databases has some similarities but then user
needs to have a username and password from the database administrator.
Therefore a feedback from doing silly things in a database tends to be
guaranteed, prompt and bitter. I do not know if db admins are alike
With an internat service the bandwidth has always some limits both on
the server and client sides. If user happens to use a mobile internet
connection it can be also rather expensive. With my operator the cost
seems to vary 2.40-10.24 euros per megabyte depending on the country.
For me "ogrinfo -so" means a standard tool for checking a layers
metadata. Let's see what this quick look with ogrinfo -so means with
one of my WFS feature type. The WFS server is running on a small Linux
virtual server with 10 Mb line up. Feature type has 462208 features
with lots of attribute data. I do have also bigger feature types than
Ogrinfo -so is sending 4 requests. Here are the requests, data received
and the time it took.
GetCapabilities 32896 bytes in 2 seconds
DescribeFeatureType 6745 bytes in 3 seconds
GetFeature&resultType=hits 843 bytes in 90 seconds
GetFeature 386446513 bytes in 590 seconds
The last request is needed for getting one piece of metadata, the exact
extents of the layer. The request transfers 386 megabytes of data for
ogrinfo and is will be discarded after the extents have been calculated.
With a fast network when the speed of the server side sets the limits
finalising the reques takes nine and a half minute. If I were stupid and
sent the request through mobile net while traveling in Europe it would
have cost me 926 euros. If I were in Vietnam I would see in the next
bill a price of 3952 euros.
Now the question is that isn't "ogrinfo -so" the standard way for checking
just the metadata of a layer with GDAL tools? Documentation says "Summary
Only: supress listing of features, show only the summary information
like projection, schema, feature count and extents". If answer is yes,
the next question is that is it reasonable that with a WFS driver this
command is reading the whole feature type from the service and all that
just for calculating the exact extents for the layer. One must remember
that the Lat/Lon extents have already been advertised within 2 seconds
in the response to the first GetCapabilities request. I would say that
the default should be not to read the features. In most cases I would
rather live without exact extents. If GetFeature is needed it should use
a MAXFEATURES parameter with some reasonable small value by default. The
summary metadata query should fire GetFeature without any feature count
limits only if user specifically selects that option.
If this is impossible to do with ogrinfo then perhaps there could be
another tool "wfsinfo"? Or more feature rich "owsinfo" for giving
optimised reports created in a reasonable way from various OGC web
services (WMS, WFS, WCS, WPS)?
More information about the gdal-dev