[gdal-dev] Re: Are these WFS issues worth filing tickets?

[Jukka Rahkonen]

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, 
so it 
> 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 
everythere, though.

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 
this one.

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)?

Regards,

-Jukka Rahkonen-