All,
Because of a very dense dataset I would like to restrict the spatial size of a WFS query.
Let say I only want to allow a request with a 2 degree bbox or smaller and ignore larger requests.
So allow:
http://…TypeName=cities&Request=GetFeature&Service=WFS&BBOX=-110.0,52.0,-108.0,54.0
but ignore:
http://…TypeName=cities&Request=GetFeature&Service=WFS&BBOX=-126.0,36.0,-108.0,54.0
Is there a way to configuration this type of functionality?
-Jay
Hi Jay,
Its possible to attach a "definition filter" to a feature type. Which basically means use this filter for any request, no matter what. So it sounds like that might be what you need.
Unfortunately it is not something that is settable from the user interface. But if you find teh info.xml fiel for your feature type (<data_directory>/featureTypes/cities/info.xml). And add something like:
<definitionQuery>
<Filter>
<BBOX>
<PropertyName>the_geom</PropertyName>
<gml:Box>
<gml:coordinates>-110.0,52.0 -108.0,54.0</gml:coordinates>
</gml:Box>
</BBOX>
</Filter>
</definitionQuery>
Try that out, let us know if it works for you.
-Justin
Jay Parsons wrote:
All,
Because of a very dense dataset I would like to restrict the spatial size of a WFS query.
Let say I only want to allow a request with a 2 degree bbox or smaller and ignore larger requests.So allow:
http://…TypeName=cities&Request=GetFeature&Service=WFS&BBOX=-110.0,52.0,-108.0,54.0but ignore:
http://…TypeName=cities&Request=GetFeature&Service=WFS&BBOX=-126.0,36.0,-108.0,54.0Is there a way to configuration this type of functionality?
-Jay
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users!DSPAM:4007,47f3950130251961014482!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Jay Parsons ha scritto:
All,
Because of a very dense dataset I would like to restrict the spatial size of a WFS query.
Let say I only want to allow a request with a 2 degree bbox or smaller and ignore larger requests.So allow:
http://…TypeName=cities&Request=GetFeature&Service=WFS&BBOX=-110.0,52.0,-108.0,54.0but ignore:
http://…TypeName=cities&Request=GetFeature&Service=WFS&BBOX=-126.0,36.0,-108.0,54.0Is there a way to configuration this type of functionality?
Jay, while we don't have this kind of functionality from the geographic
bbox point of view, we have something similar on the feature count: you can set the maximum number of features that will be returned by a GetFeature request.
There is a global setting in config/server that will provide a general
cap, and a per feature type setting that you can use to provide a stricter limit on the single feature type (stricter, but not larger).
Hope this helps
Cheers
Andrea
Andrea Aime wrote:
Jay Parsons ha scritto:
> Because of a very dense dataset I would like to restrict
the spatial size of a WFS query.
>
> Is there a way to configuration this type of functionality?Jay, while we don't have this kind of functionality from the
geographic bbox point of view, we have something similar on
the feature count: you can set the maximum number of features
that will be returned by a GetFeature request.
There is a global setting in config/server that will provide
a general cap, and a per feature type setting that you can
use to provide a stricter limit on the single feature type
(stricter, but not larger).Hope this helps
I fear this is not very good alternative if you look the situation from
the user's point of view. If the query was spatially restricted then
the user would get all the data he ordered, even the batch size is
limited. In the latter case, if the feature count exceeds actually all
the data that user gets may have no meaning because user can't know how
much data is missing. Even worse, WFS gives no way, as I know, to make a
new query to get additional data like "get 100000 more features
beginning from feature number 100001). I feel that the value of feature
count restriction in WFS is mainly in protecting the service.
I am using WFS having feature count limit in real life and I have
learned that after succeeded WFS request I must check every time what
was the feature count I received. If it was the same as the limit I
know that I did not get all the data and I must start from the beginning
with smaller request. Frustrating sometimes.
-Jukka Rahkonen-
Rahkonen Jukka ha scritto:
Andrea Aime wrote:
...
I fear this is not very good alternative if you look the situation from
the user's point of view. If the query was spatially restricted then
the user would get all the data he ordered, even the batch size is
limited.
It seems no different to me. You ask for a larger area, the server
returns only features covering a smaller one because of the limit.
In the latter case, if the feature count exceeds actually all
the data that user gets may have no meaning because user can't know how
much data is missing. Even worse, WFS gives no way, as I know, to make a
new query to get additional data like "get 100000 more features
beginning from feature number 100001).
Yeah, why the WFS working group at OGC did not thing about paged access
is something that suprised me as well.
I feel that the value of feature
count restriction in WFS is mainly in protecting the service.
I am using WFS having feature count limit in real life and I have
learned that after succeeded WFS request I must check every time what
was the feature count I received. If it was the same as the limit I
know that I did not get all the data and I must start from the beginning
with smaller request. Frustrating sometimes.
If we used a rule such as "no more than 2x2 deegrees" and you asked for 4x4, how would you know the server returned less features than requested?
An exception would be needed.
Cheers
Andrea
Andrea Aime wrote:
Rahkonen Jukka ha scritto:
>
> I fear this is not very good alternative if you look the situation
> from the user's point of view. If the query was spatially
restricted
> then the user would get all the data he ordered, even the
batch size
> is limited.It seems no different to me. You ask for a larger area, the
server returns only features covering a smaller one because
of the limit.
As a user I would like to see server refusing the whole request in such
case. I have seen a well working example, the OpenStreetMap server has
just lat/lon area limits and if the area is too wide it returns nothing
but an error message. Then you can restrict the area and have another
try. If bigger data set is needed it is possible by sliding the request
window. Unique ids in data give a possibility for client software to
take care of duplicates. That part should work with WFS as well if fids
are taken from database back end.
If we used a rule such as "no more than 2x2 deegrees" and
you asked for 4x4, how would you know the server returned
less features than requested?
An exception would be needed.
That's what I mean.
-Jukka Rahkonen-
Rahkonen Jukka ha scritto:
Andrea Aime wrote:
Rahkonen Jukka ha scritto:
I fear this is not very good alternative if you look the situation from the user's point of view. If the query was spatially
restricted
then the user would get all the data he ordered, even the
batch size
is limited.
It seems no different to me. You ask for a larger area, the server returns only features covering a smaller one because of the limit.
As a user I would like to see server refusing the whole request in such
case. I have seen a well working example, the OpenStreetMap server has
just lat/lon area limits and if the area is too wide it returns nothing
but an error message. Then you can restrict the area and have another
try. If bigger data set is needed it is possible by sliding the request
window. Unique ids in data give a possibility for client software to
take care of duplicates. That part should work with WFS as well if fids
are taken from database back end.If we used a rule such as "no more than 2x2 deegrees" and you asked for 4x4, how would you know the server returned less features than requested?
An exception would be needed.That's what I mean.
You can file jira issues requesting both of the behaviours,
thought I guess neither will be developed up until we have someone
coding or sponsoring them.
Cheers
Andrea
Rahkonen Jukka wrote:
As a user I would like to see server refusing the whole request in such
case. I have seen a well working example, the OpenStreetMap server has
just lat/lon area limits and if the area is too wide it returns nothing
but an error message. Then you can restrict the area and have another
try. If bigger data set is needed it is possible by sliding the request
window. Unique ids in data give a possibility for client software to
take care of duplicates. That part should work with WFS as well if fids
are taken from database back end.If we used a rule such as "no more than 2x2 deegrees" and
you asked for 4x4, how would you know the server returned
less features than requested?
An exception would be needed.That's what I mean.
-Jukka Rahkonen-
We have the exact same requirement for limiting WFS requests. We coded in a
check in the Geoserver 1.5. code base and the caller gets a "Bounding Box
Too Large" Exception. Its all custom code.
I have since added more custom code to directly take a Virtual Earth Quadkey
for WMS, which then I can limit very easily by ZoomLevel since that is just
the length of the Quadkey. (Yes I know you can limit the Scale in an SLD but
we accept Dynamic SLD's so I can't guarantee the scale is properly set)
So I guess I am bringing this up because we are finishing up our analysis of
1.6.X and we will be porting soon. We will be happy to share our approach
and take some direction and donate the code to the project if/when that
happens, if the project is interested. I am not sure exactly what
constitutes and extension versus breaking the WMS / WFS spec.
--
View this message in context: http://www.nabble.com/Restrict-bbox-size-of-wfs-request--tp16451775p16471353.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
bvader ha scritto:
Rahkonen Jukka wrote:
As a user I would like to see server refusing the whole request in such
case. I have seen a well working example, the OpenStreetMap server has
just lat/lon area limits and if the area is too wide it returns nothing
but an error message. Then you can restrict the area and have another
try. If bigger data set is needed it is possible by sliding the request
window. Unique ids in data give a possibility for client software to
take care of duplicates. That part should work with WFS as well if fids
are taken from database back end.If we used a rule such as "no more than 2x2 deegrees" and you asked for 4x4, how would you know the server returned less features than requested?
An exception would be needed.That's what I mean.
-Jukka Rahkonen-
We have the exact same requirement for limiting WFS requests. We coded in a
check in the Geoserver 1.5. code base and the caller gets a "Bounding Box
Too Large" Exception. Its all custom code.I have since added more custom code to directly take a Virtual Earth Quadkey
for WMS, which then I can limit very easily by ZoomLevel since that is just
the length of the Quadkey. (Yes I know you can limit the Scale in an SLD but
we accept Dynamic SLD's so I can't guarantee the scale is properly set)So I guess I am bringing this up because we are finishing up our analysis of
1.6.X and we will be porting soon. We will be happy to share our approach
and take some direction and donate the code to the project if/when that
happens, if the project is interested. I am not sure exactly what
constitutes and extension versus breaking the WMS / WFS spec.
I've asked on the wfs-dev mailing list and got this responses:
* throwing an exception when the request should return more than
maxFeatures features is considered a violation of the spec (even
if you're hitting the limit because of a server default maxFeatures
limit)
* the next wfs specification will have a place in the answer where to
declare the number of features satisfy the query and how many have
actually been returned (satisfying both max feature and area limiting
requests)
The frustrating part of all of this is that the spec has not been pushed
out anywhere afaik, so there is no way to implement it either. And of
course most of us have to work on wfs 1.0 since that's the widespread
understood spec.
A way to handle this would be to provide the behaviour you're
looking for as an option, so that by default we're compliant, but we
still allow administrators that do need this custom behaviour
to have it by sacrificing standard compliance.
Cheers
Andrea