Hi Yves,<br><br>I've just committed this in r586 -- thanks for the patch. <br><br>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?<br><font color="#888888">
<br><br clear="all"> -Josh</font><br>
<br><br><div class="gmail_quote">On Mon, Mar 9, 2009 at 9:39 AM, Yves Moisan <span dir="ltr"><<a href="mailto:yves.moisan@boreal-is.com">yves.moisan@boreal-is.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> > Did you get any feedback on the patch? If not, can you resend it to<br>
> > the list (I don't see it in my archives)?<br>
<br>
</div>Hi Josh,<br>
<br>
Any chance to commit the patch soon or is there a problem with it ? I'd<br>
like to deploy FeatureServer on a server and I would like to not have to<br>
manually edit the postgis.py file.<br>
<br>
Also, one other thing I currently do is bypass the maxFeatures = 1000 by<br>
commenting out the else clause. I understand the need to throttle the<br>
number of features returned, but I find it misleading. Of course I can<br>
always ask for maxFeatures = my number of features so I won't have<br>
surprises, so I guess that's how to do things. But I find it awkward as<br>
the number of features in a given table will rise so I'd need to have<br>
the number of records before I set maxfeatures, so that means 2<br>
requests. How do you handle those types of use cases ?<br>
<br>
Cheers,<br>
<font color="#888888"><br>
Yves<br>
<br>
<br>
<br>
</font></blockquote></div><br>