On Sun, Mar 4, 2012 at 5:28 AM, Andrea Aime <[email protected]> wrote: > On Sun, Mar 4, 2012 at 1:04 AM, Gabriel Roldan <[email protected]> wrote: >> FWIW, imho it should be possible to declare this and other service metadata >> on a per-FeatureType basis. >> I'm not sure, but it seems that the implementations that drive the spec work >> a lot different than GeoServer, like in if they work against a single >> "backend" hence having a fixed set of capabilities for all types. >> Hence, in order not to sound like unneeded critic, I wonder what should I do
edit: "...what should _we_ do..." >> as a community to help drive future versions of the spec. > > I always thought one of the reasons for WFS to exist was actually to hide > the fact the different feature types might be coming from different sources, > and make everything look uniform. Nobody is saying the opposite. I may be missing something, but how do you distinguish an editable feature type from a read only one off the capabilities document? Anyways, we're taking the thread too off topic I guess. Cheers, Gabriel > > At the same time I agree the above vision has a quite the cost, in various > ways: > - bringing up less capable data sources to have the same features as the > most capable ones is costly > - working against some emulated, non native, feature (e.g., sorting > over large data set) > has a runtime cost. > > Thinking about the runtime costs, there are issue that extend beyond the > data source differences, given a single feature type some fields are indexed, > some are not, it's not the first time I hear people asking for ways to > limit acceptable > WFS filters so that they include at least one condition on a indexed field to > avoid killing the database on a long and hard sequential scan. > The same could be applied to styles posted along with a GetMap request (SLD > 1.0 > WMS extensions, &sld, &sld_body and so on) > Something similar could be said about WFS-T, maybe you have some editable > fields, and some others that are compute on the fly and are thus non editable. > > Of course being able to specify all of the above on a per type basis would > make > clients harder to build. > > 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 339 8844549 > > 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 > > ------------------------------------------------------- -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
