[Featureserver] Query

[Josh Livni]

Hi Yves,

I've just committed this in r586 -- thanks for the patch.

The reason for the 1000 max is because some tables have so many rows it
would be a big hit if you asked for everything accidentally, and as you
noted, you can always override with a maxfeatures param.  If  you always
want all the features, why not just do &maxfeatures=100000000000 in each
request, and then you never have to worry about it again?


 -Josh


On Mon, Mar 9, 2009 at 9:39 AM, Yves Moisan <yves.moisan at boreal-is.com>wrote:

>
> > > Did you get any feedback on the patch?  If not, can you resend it to
> > > the list (I don't see it in my archives)?
>
> Hi Josh,
>
> Any chance to commit the patch soon or is there a problem with it ? I'd
> like to deploy FeatureServer on a server and I would like to not have to
> manually edit the postgis.py file.
>
> Also, one other thing I currently do is bypass the maxFeatures = 1000 by
> commenting out the else clause.  I understand the need to throttle the
> number of features returned, but I find it misleading.  Of course I can
> always ask for maxFeatures = my number of features so I won't have
> surprises, so I guess that's how to do things.  But I find it awkward as
> the number of features in a given table will rise so I'd need to have
> the number of records before I set maxfeatures, so that means 2
> requests.  How do you handle those types of use cases ?
>
> Cheers,
>
> Yves
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/featureserver/attachments/20090309/ef24f2c1/attachment.html