<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="MSHTML 8.00.6001.19088">
</head>
<body>
<div dir="ltr" align="left"><font color="#0000ff" size="2" face="Arial"><span class="694335406-02092011">Hi,</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" size="2" face="Arial"><span class="694335406-02092011"></span></font> </div>
<div dir="ltr" align="left"><font color="#0000ff" size="2" face="Arial"><span class="694335406-02092011">I do not have QGIS 1.7 installed at the moment but I noticed from a video
<a href="http://188.64.1.61/QGis_WFS.swf">http://188.64.1.61/QGis_WFS.swf</a> 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.</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" size="2" face="Arial"><span class="694335406-02092011"></span></font> </div>
<div dir="ltr" align="left"><font color="#0000ff" size="2" face="Arial"><span class="694335406-02092011">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
<a href="http://188.64.1.61/Kosmo_WFS_2.swf">http://188.64.1.61/Kosmo_WFS_2.swf</a> and see attribute filter in action.</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" size="2" face="Arial"><span class="694335406-02092011"></span></font> </div>
<div dir="ltr" align="left"><font color="#0000ff" size="2" face="Arial"><span class="694335406-02092011">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.</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" size="2" face="Arial"><span class="694335406-02092011"></span></font> </div>
<div dir="ltr" align="left"><font color="#0000ff" size="2" face="Arial"><span class="694335406-02092011">-Jukka Rahkonen-</span></font></div>
<div dir="ltr" align="left"><span class="694335406-02092011"></span><font face="Tahoma"><font size="2"><span class="694335406-02092011"><font color="#0000ff" face="Arial"> </font></span></font></font></div>
<div dir="ltr" align="left"><font size="2" face="Tahoma">Andrea Peri<span class="694335406-02092011"><font color="#0000ff" face="Arial"> wrote:</font></span></font><br>
</div>
<blockquote style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
<div></div>
I know this settting was availbale surely in the arcims-esri.<br>
But I don't know the wfs part of arcims. I know the wms part.<br>
<br>
Arcims admit setting of scale of availability as server setting.<br>
So I suppose also the wfs system of esri-arcims can do it.<br>
<br>
I guess this is not a spec. dependent setting.<br>
However the real setting should be that the data are available only over a scale.<br>
<br>
>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:
<a href="http://188.64.1.61/Kosmo_WFS_3.swf" target="_blank">http://188.64.1.61/Kosmo_WFS_3.swf</a><br>
<font color="#888888"><br>
</font>thx, I test it.<br>
<br>
cheers,<br>
<br>
<div class="gmail_quote">2011/9/2 Rahkonen Jukka <span dir="ltr"><<a href="mailto:Jukka.Rahkonen@mmmtike.fi">Jukka.Rahkonen@mmmtike.fi</a>></span><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
Hi,<br>
<br>
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?<br>
<br>
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:
<a href="http://188.64.1.61/Kosmo_WFS_3.swf" target="_blank">http://188.64.1.61/Kosmo_WFS_3.swf</a><br>
<font color="#888888"><br>
-Jukka Rahkonen-<br>
</font>
<div>
<div></div>
<div class="h5"><br>
Andrea Peri wrote:<br>
<br>
<br>
> Hi,<br>
<br>
> I'm study-ing TinyOWS as server WFS,<br>
using qgis as wfs client.<br>
<br>
> I notice a procedural issue when the dataset is huge.<br>
<br>
> It need a very much time to startup on first visualization.<br>
The qgis plugin need to download all the dataset.<br>
The only solution to avoid this time lost, is activate the "limit-feature" option.<br>
But it is a strange solution.<br>
Infact the qgis WFS-plugin download the first feature untile the limit set, and after don't show any other dataset.<br>
If I try to zoon to a details if the detail is out of the first downloaded feature, simply qgis show nothing.<br>
Perhaps this is an issue of qgis plugin, but however I guess the "limit-feature" solution for huge dataset is not a<br>
solution in many use-case.<br>
<br>
> I guess a better approach should be a<br>
dimension approach.<br>
> Allowing the size in unit of length of the max dataset retrievable.<br>
<br>
> something like<br>
<br>
<limits unit-of-lenght="1000" /> (dont send when the portion asked is more than a square of 1000x1000 unit-of-lenght)<br>
<br>
<br>
<br>
> For example setting max retrievable size = 1000 meters,<br>
the wfs server should be send data only if the bbox asked has a size under<br>
1000meters x 1000meters<br>
<br>
> Without see how much features it could contains.<br>
<br>
> Of course this mean to set something like a scale-dependent limitation,<br>
but this in many use-case is more affordable then a limit-features .<br>
<br>
Regards,<br>
<br>
--<br>
-----------------<br>
Andrea Peri<br>
. . . . . . . . .<br>
qwerty אטלעש<br>
-----------------<br>
<br>
</div>
</div>
<div>
<div></div>
<div class="h5">_______________________________________________<br>
TinyOWS-users mailing list<br>
<a href="mailto:TinyOWS-users@lists.maptools.org">TinyOWS-users@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/tinyows-users" target="_blank">http://lists.maptools.org/mailman/listinfo/tinyows-users</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
-----------------<br>
Andrea Peri<br>
. . . . . . . . . <br>
qwerty אטלעש<br>
-----------------<br>
<br>
</blockquote>
</body>
</html>