[TinyOWS-users] An enhancement for TinyOWS
aperi2007 at gmail.com
Fri Sep 2 00:14:08 EST 2011
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
>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://126.96.36.199/Kosmo_WFS_3.swf
thx, I test it.
2011/9/2 Rahkonen Jukka <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://188.8.131.52/Kosmo_WFS_3.swf
> -Jukka Rahkonen-
> Andrea Peri wrote:
> > Hi,
> > 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"
> 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
> dimension approach.
> > 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 .
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> TinyOWS-users mailing list
> TinyOWS-users at lists.maptools.org
. . . . . . . . .
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TinyOWS-users