On 4/13/11 8:35 AM, Justin Deoliveira wrote: > Hi Andrea, thanks for the feedback, comments inline. > > On Wed, Apr 13, 2011 at 12:54 AM, Andrea Aime > <[email protected] <mailto:[email protected]>> wrote: > > On Wed, Apr 13, 2011 at 3:55 AM, Justin Deoliveira > <[email protected] <mailto:[email protected]>> wrote: > > Hi all, > > As most know the next version of the wfs spec (2.0) brings paging > into the > > mix which just boils down to the parameters startIndex and count on a > > GetFeature request. While it looks quite promising that wfs 2.0 will > > becoming to geoserver in the next few weeks / months, we have a > client > > currently that requires paging functionality via WFS. So I have > put together > > a patch that implements paging for all wfs versions. > > http://jira.codehaus.org/browse/GEOS-4485 > > Feedback welcome. > > Hi Justin, > I did not review deeply, just had a quick walk over the patch > sources, but it > looks pretty much like what I was expecting (one tricky part that we > might > want to double check, maybe with some more tests, it's the wfs 1.0 > feature > counting). > > Sure thing... can you be more specific about what cases to test? Most of > the test cases there are wfs 1.0 with a mix of startIndex and > maxFeatures. I tried to catch most of the boundary cases but probably > missed some. > > > So I'm wondering about count/maxFeatures. Are they basically going to be > aliases with the same meaning? > So that one can do > ...&startIndex=10&maxFeatures=5&... > or > ...&startIndex=10&count=5&... > and the result will be the same? > > > That is the general idea yeah. The patch as written should do that for > the GET case. For the POST case count is not yet handled... i was going > to put that off until wfs 2.0 starts. > > > I'm also wondering about paging stability. > The current setup will return incoherent results if someone deletes > or updates a feature while we page. Not complaining, doing a full dump > of the results just for the sake of paging in a stable way would be > a massive > overhead, just wondering if the problem had been considered. > > Yeah I did consider this after reading the spec because technically this > is a requirement of spec on the server. But seems quite unrealistic to > me since as you say we would have to maintain some sort of cache or > something on the server. It would make the WFS GetFeature a stateful > operation... so I imagine we would need so start creating sessions to > track the request or something. All in all I think just having this be a > "limitation" of the implementation is probably going to suffice in 99% > of cases.
WFS 2.0 describes both paging with and without transactional consistency. It's not a requirement to be consistent there even (PagingIsTransactionSafe can be true or false), right? > Also it seems that WMS GetMap already supports paging... and this is > more or less following suite what it is doing. > > > Also curious about sorting... I remember something like sorting by > default > on the feature id while paging, but my memories of it are foggy, we > discussed > this with Gabriel a loong time ago (when the paging machinery was > added to > GeoTools). > > > As I understand things how they are implemented now using startIndex > requires the underlying datastore to be able to do sorting. And when the > client does not specify an explicit attribute to sort on this means > doing a natural sort (feature id). If you look at > ContentFeatureSource.getReader(Query) you will see a check there. > > Which more or less means that paging can only be used with jdbc > datastores. Which personally I think is fine since they are the only > ones that can really do it efficiently. Thoughts on that? Would it be possible (later) to do sorting for all stores? I understand it would be inefficient, but it's a bigger drawback (in my opinion) to have a feature be store specific. As the client has no way to know about these distinctions. > > Cheers > Andrea > > -- > ------------------------------------------------------- > Ing. Andrea Aime > GeoSolutions S.A.S. > Tech lead > > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584 962313 > fax: +39 0584 962313 > mob: +39 333 8128928 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.youtube.com/user/GeoSolutionsIT > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ------------------------------------------------------- > > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > > > ------------------------------------------------------------------------------ > Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. > Forrester found the best-in-class provider in terms of services and vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > > > > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
