[TinyOWS-users] An enhancement for TinyOWS

Andrea Peri 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
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.64.1.61/Kosmo_WFS_3.swf

thx, I test it.

cheers,

2011/9/2 Rahkonen Jukka <Jukka.Rahkonen at mmmtike.fi>

> Hi,
>
> 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.64.1.61/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"
> 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
> 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 .
>
> Regards,
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------
>
> _______________________________________________
> TinyOWS-users mailing list
> TinyOWS-users at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tinyows-users
>



-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/tinyows-users/attachments/20110902/1533e543/attachment.htm 


More information about the TinyOWS-users mailing list