[TinyOWS-users] An enhancement for TinyOWS
Jukka.Rahkonen at mmmtike.fi
Fri Sep 2 02:27:07 EST 2011
I do not have QGIS 1.7 installed at the moment but I noticed from a video http://22.214.171.124/QGis_WFS.swf that is does already have a check box in the lower left corner. If you zoom in to your area of interest fists and then get features from WFS with this box checked it will take the BBOX from the map window.
I would say that setting the scale limit for WFS would be useful sometimes but only if there is a well defined use case and if application developer and server administrator are working together. WFS standard does not contain anything like scale_hint on the WMS side. Implementing the scale limit would also mean in practise that a WFS client should send the request always with a BBOX filter and that is against the standard because BBOX and other filters are optional. In practise forcing the use of a small BBOX always would make the service much worse for the user. Imagine a user willing to use an attribute filter for selecting certain kind of features from the whole country. The result set may be minimal in size but a compulsory smal BBOX would make it impossible to do this reasonable request. Try http://126.96.36.199/Kosmo_WFS_2.swf and see attribute filter in action.
I believe that users can live with WFS if the client is able to use at least BBOX filter. It would be nice aid for the user if the client would also check if the result set contains exactly as many features as the maxFeatures limit that is set either from the server side or in the request. That would suggest that probably some of the features are missing and user should do a new request with smaller BBOX or some other limiting filter.
Andrea Peri wrote:
I know this settting was availbale surely in the arcims-esri.
But I don't know the wfs part of arcims. I know the wms part.
Arcims admit setting of scale of availability as server setting.
So I suppose also the wfs system of esri-arcims can do it.
I guess this is not a spec. dependent setting.
However the real setting should be that the data are available only over a scale.
>But QGis should really be more clever and not just send plain GetFeatures. Version 1.8.0 has filter option but it is not very user friendly. Look what you can do >with Kosmo GIS: http://188.8.131.52/Kosmo_WFS_3.swf
thx, I test it.
2011/9/2 Rahkonen Jukka <Jukka.Rahkonen at mmmtike.fi<mailto:Jukka.Rahkonen at mmmtike.fi>>
That is not supported by WFS standard but I don know some services using such a tailored throttle. It could perhaps be a useful configuration option in TinyOWS but it would not suit very well for a public WFS because all the users should be aware of such a limit. And what the server would send without any BBOX in the request?
But QGis should really be more clever and not just send plain GetFeatures. Version 1.8.0 has filter option but it is not very user friendly. Look what you can do with Kosmo GIS: http://184.108.40.206/Kosmo_WFS_3.swf
Andrea Peri wrote:
> I'm study-ing TinyOWS as server WFS,
using qgis as wfs client.
> I notice a procedural issue when the dataset is huge.
> It need a very much time to startup on first visualization.
The qgis plugin need to download all the dataset.
The only solution to avoid this time lost, is activate the "limit-feature" option.
But it is a strange solution.
Infact the qgis WFS-plugin download the first feature untile the limit set, and after don't show any other dataset.
If I try to zoon to a details if the detail is out of the first downloaded feature, simply qgis show nothing.
Perhaps this is an issue of qgis plugin, but however I guess the "limit-feature" solution for huge dataset is not a
solution in many use-case.
> I guess a better approach should be a
> Allowing the size in unit of length of the max dataset retrievable.
> something like
<limits unit-of-lenght="1000" /> (dont send when the portion asked is more than a square of 1000x1000 unit-of-lenght)
> For example setting max retrievable size = 1000 meters,
the wfs server should be send data only if the bbox asked has a size under
1000meters x 1000meters
> Without see how much features it could contains.
> Of course this mean to set something like a scale-dependent limitation,
but this in many use-case is more affordable then a limit-features .
. . . . . . . . .
TinyOWS-users mailing list
TinyOWS-users at lists.maptools.org<mailto:TinyOWS-users at lists.maptools.org>
. . . . . . . . .
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TinyOWS-users