Is the missing piece of the puzzle that selection and classification in SLD is reusing filters, but have different semantics? I can feed back to the SLD revision group (which is being proposed to be re-formed) that this is an implementation problem, and maybe get the next version fixed.
In the meantime, I'd recommend Andrea's suggestion - whether its an extension or a parsed comment - or even something horrible like putting a keyword on the layer classifiedBy=attributename, if its a workaround a deficiency in the spec semantics anything goes. Putting it in the keywords or another config parameter makes it a config issue, and the SLD's can be fully interoperable. Rob On Thu, Oct 8, 2009 at 5:17 PM, Andrea Aime <aa...@opengeo.org> wrote: > Jody Garnett ha scritto: >> Hi Andrea: >> >> I was waiting to see if you were going to talk about this on the >> geotools list; I assume a Hint can be passed to the OracleDatastore to >> control the SQL encoder? > > Humm... no? The renderer is doing the job of building in the extra > filters into the query. Building them just to pass down a hint that > only the geometry part should be used is backwards. > > Read again my mail: the parameter that control how many filters the > renderer will add to the original query is already there, I'm > just proposing to expose it to the admins. > > Adding a hint would be more code in the renderer, more code into > the JDBC datastores and the same amount of code to expose it to > the user. The code in the JDBC datastore would be more complex > too, as one would have to be able and split any kind of filter, > whilst the renderer knows that the filter being built is: > layer definition filter + bbox + extra stuff from the SLD > and skipping the last part is just easy. > > Cheers > Andrea > >>> The database is configured with an index on the classification field, >>> and GeoServer was issuing a query like: >>> >>> geom in bbox and (mtfcc = 'class1' or mtfcc = 'class2' or ...) >> >> I also wondered (since applying this idea is kind of different on a >> case by case basis) if a per FeatureTypeStyle vedor specific parameter >> would be appropriate. >> >> Jody > > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
