GeoTools

Make the j2d renderer data streaming aware

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Won't Fix
  • Affects Version/s: 2.1.M0
  • Fix Version/s: None
  • Component/s: unsupported
  • Labels:
    None

Description

The j2d renderer uses the RenderedLayerFactory to transform
FeatureCollections to RenderedLayer. This is a blocking process, no
rendering can be performed before this ends.

The idea is to create a new kind of RendereredLayer that does this transformation while rendering data the first time. This must be a composite since it will potentially be a composition of SLDRenderedGeometries and RenderedGridCoverages.

Issue Links

This issue depends upon:
GEOT-775 Port the geometric part of J2D-renderer to a "rendering-targeted" ISO 19107 implementation Major Closed
GEOT-18 Enable rendering while loading only the required part of geometries, like tiles in images Minor Closed
GEOT-416 Port the geometric part of J2D-renderer to a "rendering-targeted" ISO 19107 implementation Critical Closed
This issue is depended upon by:
GEOT-21 Active rendering for MapPane Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Martin Desruisseaux added a comment -
An other possible approach is to take advantage of iterators. The renderer alyways iterate through points using an iterator, a little bit like JTS 1.4 'CoordinateSequence' interface can be used to iterate through JTS's geometries. For each Feature, we could:

   - Extract the Feature's bounding box only (not the full data).
     The bounding box is needed in order to determine when the Feature
     become visible in the Renderer's clipping area.

   - Keep some pointer to a CoordinateSequence, in order to be
     able to read Feature's data when they will be first needed.

Instead of wrapping RenderedLayer, I suggest to perform the wrapping at a much lower level: straight into JTS's geometry. I think it would be simplier, provides more fine-grain control and be usefull for lite-renderer as well as j2d-renderer.

   - Creates a special implementation of JTS's geometry with a
     special CoordinateSequence iterator. This iterator is the
     place where Feature data will be fetch the first time they
     are required, using streaming capability.

   - Modify org.geotools.renderer.array.JTSArray in order to uses
     CoordinateSequence instead of CoordinatePoint[].

From this point, basic streaming will be available in j2d-renderer. Further work would be needed later in order to allow for example progressive update of the map at rendering time.
Show
Martin Desruisseaux added a comment - An other possible approach is to take advantage of iterators. The renderer alyways iterate through points using an iterator, a little bit like JTS 1.4 'CoordinateSequence' interface can be used to iterate through JTS's geometries. For each Feature, we could:    - Extract the Feature's bounding box only (not the full data).      The bounding box is needed in order to determine when the Feature      become visible in the Renderer's clipping area.    - Keep some pointer to a CoordinateSequence, in order to be      able to read Feature's data when they will be first needed. Instead of wrapping RenderedLayer, I suggest to perform the wrapping at a much lower level: straight into JTS's geometry. I think it would be simplier, provides more fine-grain control and be usefull for lite-renderer as well as j2d-renderer.    - Creates a special implementation of JTS's geometry with a      special CoordinateSequence iterator. This iterator is the      place where Feature data will be fetch the first time they      are required, using streaming capability.    - Modify org.geotools.renderer.array.JTSArray in order to uses      CoordinateSequence instead of CoordinatePoint[]. From this point, basic streaming will be available in j2d-renderer. Further work would be needed later in order to allow for example progressive update of the map at rendering time.
Hide
Permalink
Andrea Aime added a comment -
EXTERNAL MESSAGE:
SUBJECT: Re: [jira] Commented: (GEOT-52) Make the j2d renderer data streaming aware
On Sunday 16 November 2003 18:22, jira@codehaus.org wrote:
> An other possible approach is to take advantage of iterators. The renderer
> alyways iterate through points using an iterator, a little bit like JTS 1.4
> 'CoordinateSequence' interface can be used to iterate through JTS's
> geometries. For each Feature, we could:
>
> - Extract the Feature's bounding box only (not the full data).
> The bounding box is needed in order to determine when the Feature
> become visible in the Renderer's clipping area.
>
> - Keep some pointer to a CoordinateSequence, in order to be
> able to read Feature's data when they will be first needed.

How do you generate the style for the feature if you don't inspect the attributes
too?

> Instead of wrapping RenderedLayer, I suggest to perform the wrapping at a
> much lower level: straight into JTS's geometry. I think it would be
> simplier, provides more fine-grain control and be usefull for lite-renderer
> as well as j2d-renderer.
>
> - Creates a special implementation of JTS's geometry with a
> special CoordinateSequence iterator. This iterator is the
> place where Feature data will be fetch the first time they
> are required, using streaming capability.

? The geometry is a part of the Feature, not the other way round. Having
a reference to a CoordinateSequence iterator provide no means to get
the Feature attributes necessary to instantiate a style. Do I miss something?

> - Modify org.geotools.renderer.array.JTSArray in order to uses
> CoordinateSequence instead of CoordinatePoint[].
>

Agreed, but only to save memory (see the ml and irc meetings when we
discussed how to save memory by using specialized coordinate sequences).

To recap: FeatureReader (the streaming architecture iterator) is a forward
only iterator, and the features that we got from it are fully loaded and parsed
from the original on-disk format. Getting only the bbox doesn't help, it will
require to read the whole data set just to get the attributes when the feature
needs to be shown.

We also need some kind of caching, since changing styles will require again
attribute access, which means reloading data anyway, unless data is cached
somewhere in memory. If people feel style changing is slow now due to
renderered layer rebuilding from on memory feature collections, what would they
say if we have to rebuild everything while reloading data from the disk/network?
Show
Andrea Aime added a comment - EXTERNAL MESSAGE: SUBJECT: Re: [jira] Commented: (GEOT-52) Make the j2d renderer data streaming aware On Sunday 16 November 2003 18:22, jira@codehaus.org wrote: > An other possible approach is to take advantage of iterators. The renderer > alyways iterate through points using an iterator, a little bit like JTS 1.4 > 'CoordinateSequence' interface can be used to iterate through JTS's > geometries. For each Feature, we could: > > - Extract the Feature's bounding box only (not the full data). > The bounding box is needed in order to determine when the Feature > become visible in the Renderer's clipping area. > > - Keep some pointer to a CoordinateSequence, in order to be > able to read Feature's data when they will be first needed. How do you generate the style for the feature if you don't inspect the attributes too? > Instead of wrapping RenderedLayer, I suggest to perform the wrapping at a > much lower level: straight into JTS's geometry. I think it would be > simplier, provides more fine-grain control and be usefull for lite-renderer > as well as j2d-renderer. > > - Creates a special implementation of JTS's geometry with a > special CoordinateSequence iterator. This iterator is the > place where Feature data will be fetch the first time they > are required, using streaming capability. ? The geometry is a part of the Feature, not the other way round. Having a reference to a CoordinateSequence iterator provide no means to get the Feature attributes necessary to instantiate a style. Do I miss something? > - Modify org.geotools.renderer.array.JTSArray in order to uses > CoordinateSequence instead of CoordinatePoint[]. > Agreed, but only to save memory (see the ml and irc meetings when we discussed how to save memory by using specialized coordinate sequences). To recap: FeatureReader (the streaming architecture iterator) is a forward only iterator, and the features that we got from it are fully loaded and parsed from the original on-disk format. Getting only the bbox doesn't help, it will require to read the whole data set just to get the attributes when the feature needs to be shown. We also need some kind of caching, since changing styles will require again attribute access, which means reloading data anyway, unless data is cached somewhere in memory. If people feel style changing is slow now due to renderered layer rebuilding from on memory feature collections, what would they say if we have to rebuild everything while reloading data from the disk/network?
Hide
Permalink
Andrea Aime added a comment -
Mass closing all go-1 related issues as the module does not exist anymore
Show
Andrea Aime added a comment - Mass closing all go-1 related issues as the module does not exist anymore

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.