Ivo Brodien ha scritto: > >>> I mean, all the filtering and calculations could be done in my SVG >>> Renderer in Geoserver but I think it would be much faster within the >>> database. >> Agreed... but getting GeoServer to serve that out will be tricky... > > I am afraid you are right. I saw that Andrea is one of the geotools > postig classes devoloper. Maybe he has an idea? > > am I right that until > > > Query bboxQuery = new DefaultQuery(schema.getTypeName(), bboxFilter); > Query definitionQuery = layer.getQuery(); > DefaultQuery finalQuery = new > DefaultQuery(DataUtilities.mixQueries(definitionQuery, bboxQuery, > "svgEncoder")); > finalQuery.setHints(definitionQuery.getHints()); > finalQuery.setSortBy(definitionQuery.getSortBy()); > finalQuery.setStartIndex(definitionQuery.getStartIndex()); > > featureReader = fSource.getFeatures(finalQuery).features(); > > until the last line is executed in my SVGRenderer or in any other > Renderer the database is not queried?
Yes, you're indeed right, the data access code works in pull mode, the database is accessed only the last moment, it's the features() call that actually triggers the query on the db. > Wouldn't it be useful (i am asking in general) if a PostGIS would > somehow also promote functions that have a geometry column, just like > having a geometry_column table you would have a geometry_funcion table > which also includes the desired paramters...if any? Just an idea from a > total newbie to all this... The crux of the problem is passing parameters down to SQL, function or not. And that is not trivial, as we don't have any place to put those parameters in the standard Query API, to start with. We should probably create a subclass of Query, ParametricQuery, that has the ability to pass down params. And then also have a way to state a FeatureType is parametric, in that querying it can require specify parameters (or allows specify params, and uses default values when not). And finally have a way to configure the params for such a feature type on creation, which could be done with a table like the one you suggest, or in a ton other ways... So I guess it's doable, but it require a non trivial amount of changes in core classes. Something that we can think about for jdbc-ng... Ivo, maybe you can prototype out a solution for your specific use case (which as I understand works on top of the old jdbc classes, and it cannot be elsewhere, since there is no jdbc-ng version of the postgis datastore) and then we can work into merging the solutions or the ideas that come out of it into the new jdbc classes, so that everybody can get, in due time, benefits from this work? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
