Hi, I noticed a performance issue with serving WFS 1.1.0 GetFeature requests with GeoJSON output format.
1. GetFeature.run() calculates the total number of features that the query matches (for paging purposes) 2. GeoJSONGetFeatureResponse.getFeatureCountFromWFS11Request() counts the number of total features again (to include the number in the GeoJSON reponse) There are (at least) two issues with this: first of all it makes little sense to count the features twice. This is especially problematic with complex data sources (for example cascaded WFS stores, JDBC stores serving data especially from non-trivial objects). The second issue is that this implementation requires duplicating query / filter logic in the response class, which is the wrong place architecture wise. For WFS 2.0.0, the total number of matching features is retrieved in the response writer via FeatureCollectionResponse.getTotalNumberOfFeatures(). This feels like a much better pattern. For WFS 1.1.0, this getter could be a lazy method which fires the actual query to the data store only once per query. What do you think? Would this be the right approach to fix this, or is there a deeper reason why this getFeatureCountFromWFS11Request() hack is required? Sampo -- Sampo Savolainen R&D Director, Spatineo Oy sampo.savolai...@spatineo.com +358-407555649 Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland www.spatineo.com, twitter.com/#!/spatineo www.linkedin.com/company/spatineo-inc This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate, or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so.
------------------------------------------------------------------------------
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel