I want to be clear: KILL SHAPEFILERENDERER!!
The rest of the conversation is just discussion and I trust that you will do
a good job so dont let the discussion slow down work.
On Mon, Apr 6, 2009 at 9:51 AM, Andrea Aime <[email protected]> wrote:
> 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?
I was under the impression that LiteRenderer often asks for features in
projection X and requires that the Datastore offer transformed geometries.
This makes sense to do in the datastore when you consider postgis and other
server side Datastores. The AffineTransform to screen is not necessary to
have in the DataStore. So it is that Native CRS to Map CRS that 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.
>
Like I said I was just wondering how to implement this not a question of
whether we should kill ShapefileRenderer
>
>
> 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.
>
Jesse
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
