Jesse Eichar ha scritto: ... > (b) and (c) are about generalizing data while reading it. > The hints we're discussing in the separate generalization > thread could be used to support this. I'm however > a little skeptical about this point. > (b) simply means doing inside the datastore the job of the > Decimator class (skip points that are too close to each > other to show up as distinct entities on the screen). > The datastore still has to read all the coordinates, > and perform the generalization in memory, so I'm > dubious doing this inside the reader can be any faster > than doing it in the Decimator. Jesse, what do you think? > > > For shapefile it might be slightly faster in the case where the renderer > requests features in projection X but the native projection is Y in this > case decimation in the renderer results in many more transformations > which are potentially expensive.
Mumble... why more transformations? The Decimator class does both, generalization and transformation, in this order: first generalize, only after transform. Where are the extra transformations? > For other datastores like postgis (if postgis adds a generalization > function) the performance in the datastore and not the renderer can be huge Indeed, that's why we're discussing this in a separate thread on this ml (and in http://jira.codehaus.org/browse/GEOT-2421) > d) is about skipping the bbox filter evaluation in memory, > and in particular, skipping the bbox full intersection behaviour > mandated by the OGC (an bbox in OGC terms is just a shorthand > syntax for instersect, but for rendering a bbox vs bbox comparison > is more than enough). > Since we're accessing the spatial index, we can skip the > bbox completely. IndexedDataStore is not doing that, and > it's performing those expensive intersections for all > features whose bbox is not fully contained in the rendering area. > This can be skinned in a number of ways: > - have streaming renderer build a subclass of bbox that > only does the loose evaluation when used in memory > - have a gt2 wide bbox subclass that does the same, allowing > everyone to recognize it. Downside, how do we build it > given the FilterFactory is defined at the GeoApi level? > - pass down a query hint that all bboxes should be evaluated > in a loose way. Nice, too bad it might interfere with > some bbox in the SLD itself that people wanted to be > evaluated the hard way (think dynamic SLD used to show > selection in WMS) > > > That is a hard one. Considering having a gt wide bbox subclass so that > the DS can recognize it. I want to analyze the benefits of that > option. From where I stand there is a clear, huge benefit: getting rid of shapefile renderer without giving up its the extra performance. I've already spend many, many days since GeoServer adopted it fixing issues that were only in one of the two renderers :-) I'm ok spending more days, but trying to get rid of the extra maintenance instead of working more on the two renderers, twice each time. > Is the majority of the performance bottleneck with Postgis and > WFS, etc.. the network streaming? Or is the reduced cost of processing > in the database/other service worth the cost of introducing a new system > wide class to be recognized by all. It does not have to be recognized by all, just by all concerned with rendering performance. To get started I would only need shapefile datastore to recognize it. > I honestly dont know. I can see perhaps if the Postgis and Geoserver > are on the same server it could make a significant difference and that > is a usecase that occurs at least occasionally. > > Same argument can be made for the hint. At the moment the JDBC datastores are configured with the magic "loose bbox" flag that makes them assume every bbox is a loose one. It's the thing that makes WMS on top of PostGIS fast enough (there is a big price to pay to turn that off) but it also makes WFS non compliant, as BBOX filters are evaluated in a loose manner (not that many people complain about it thought). I'm also starting to see people use dynamic SLD to have the renderer highlight areas that a user selected. If the selection is "by window" using a loose bbox approach we'd end up highliting featuers that are outside of the window, but whose bbox crosses it, making for an odd result. So: - a hint that all bboxes are considered loose would make the WFS case work in a compliant way (keeping WMS happy) - a class that marks a specific bbox as loose would make the "dynamic SLD with Rule with a bbox filter" happy as well. The first approach is less costly, and people can work around the loose bbox issue by specifying manually an equivalent intersect filter in their dynamic sld that highlights the "window selection" > (e) is kind of a very hard core, very effective in its > specific use case, but map degrading optimization. > Basically the renderer keeps ... > I guess this optimization has merit anyways when getting > a quick overview is more important than getting an > accurate result, but being a trade off, it should > be optional. > > > Agreed. But it is really nice when loading a GB shapefile :) Yep. That's why I'm suggesting to have this ported to streaming, but be optional. > (f) imho does not give any speedup, once you're loaded > the coordinates into a double[] where you do the > transformation (inside the reader, or inside the > renderer) should not make a difference. > > > I think I agree :P > > > Plan > ------------------------------------------------------- > Well, the idea is to come up with a number of patches > that move the optimizations into the > StreamingRenderer/ShapefileDataStore couple, and allow > other datastores to benefit from them as well. > I can do that on a branch, or I can do it on trunk. > What do people prefer? My preference would be to > create a stream of incremental patches to be applied > on trunk, where I can get early feedback from uDig and > GeoTools on whether these are breaking any expected > behaviour. > > > > I am ok with a stream of clean patches. I think there is potential for > more upfront testing that way. Nice Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
