proposal for interactivity and feature look-up for efficiently rendered and functional GUIs


Hi there,

we've been developing a commercial application using GT2 - actually we're in the process of upgrading the app from GT1. We've got a long way with this new OGIS compliant version, which we're happy about, but have gotten to a point where we need some extra functionality. We'd like to develop this functionality, as a contribution to the GeoTools project, with the aim of enhancing GeoTools as well as for our own ends (and obviously we don't want to diverge from the project, or - worst-case - pursue an alternative). We are (and expect to continue to be) involved in a number of projects involving processing and visualisation of large geographical data sets. So here are the issues as we see them and what we'd like to do - I'm sure you've thought about much or perhaps even all of this before, so please let us know your thoughts. If you agree, we'd be very keen to make progress on
this development.

In the previous version of our app, which used GT1, we had the ability to highlight features with MouseOver (for purposes of user selection in setting up an optimisation process). We need to replicate this behaviour with GT2. Actually I've raised this before in one of our various correspondences - an issue was opened on JIRA at -
Also related is a request at -
The underlying issue, as we see it, is really one of interactivity,
coupled with dynamic rendering, which must be considered for performance reasons.

Such a capacity for interaction seems to be absent from the OGIS spec as it appears to be concerned primarly with representation of geography. However, in any real software application it becomes necessary to interact with the map (e.g., in this case, to select features). This requires that the visualisation is able to receive notification of changes from the user (by way of some kind of Event mechanism) and that the map respond appropriately. A parallel issue then arises of how to achieve this interaction for densely featured maps without impacting too heavily on performance (again this is a real-world software issue which OGIS does not seem to consider in any depth). Some kind of feature look-up mechanism would seem to be essential to ensure that only features in an area which is changed by user interaction are re-Styled and re-rendered - this may relate to -
Such a mechanism, combined with some kind of feature caching, is of course also a large part of what is required for fast panning and zooming operations.

Currently we have implemented a slightly crude selection mechanism which re-draws selected features in an extra, overlaid, "SelectionLayer" (with a "selected" Style). Features are selected in a table and their IDs added to a FeatureIDFilter in the SelectionLayer Style - hence our earlier request for removing/adding Fids to FidFilters: - This however, can be slow when re-rendering and in any case does not offer the MouseOver capablities our client requires.

We would like to add these capabilities - interactivity and feature look-up - to GeoTools. It would be nice to build these in at quite a low level, but given the restrictons of OpenGIS, we expect that much of it will have to be done in the renderer.

For user interaction we propose some kind of listener which listens for MouseEvents on Shapes on the map. This then throws FeatureChangedEvents as appropriate, and, together with a Shape2Feature map, the affected area can be redrawn to show the modified features. For efficiency this would best be realised using a feature look-up mechanism. For this we propose building a (fairly standard) R-Tree structure of features in each layer, adding one to each layer (or, if OpenGIS is not happy with that, we are thinking to use RenderedLayer).

All this would also pave the way for building a proper Viewer with efficent pan and zoom behaviour - this would at least be useful for GeoTools for demo purposes (currently it seems such a Viewer element is not yet present or complete in GT2).

Well, hope you find this positive and worth pursuing. We would really like to get started on this soon.

Hope to hear from you soon, and in any case, all the best for the season and good luck with GeoTools in 2004!


proshun sinha-ray
Julian Elliott
Vince Darley




April 10, 2015, 2:53 PM

CodeHaus Comment From: jmacgill - Time: Mon, 26 Jan 2004 23:26:01 -0600
This issue came during todays IRC session and a decision was made to dedicate most of next weeks IRC to issues related to interactive rendering.

You can find details about how to join in on an IRC session at:

<a href=""></a>

If you are interested in this issue and are unable to attend (either for technical or timing reasions) then please let us know so that we can arrange something else.

April 10, 2015, 2:53 PM

CodeHaus Comment From: aaime - Time: Wed, 4 Feb 2004 05:31:20 -0600
Sorry to wake up this late, but here are a few comments:

  • instead of using the r-tree I&#39;d suggest using a quadtree

&nbsp;&nbsp;to fastly get the geometries under the mouse. Rationale:

&nbsp;&nbsp;the quadtree and r-tree indexes are provided in the jts

&nbsp;&nbsp;as maps from envelopes to objects, so they are fairly

&nbsp;&nbsp;generic. R-tree is faster but is implemented as an STR-Tree

&nbsp;&nbsp;and needs to be rebuilt every time a single geometry changes,

&nbsp;&nbsp;which is what we need anyway when the base map style changes, but

&nbsp;&nbsp;may not be the best when in future we will provide layer editing

&nbsp;&nbsp;capabilities. The quatree implementation can be changed after

&nbsp;&nbsp;being built.

  • mapping directly the geometry to the feature means keeping in

&nbsp;&nbsp;memory every feature (geometry + attributes) which is something

&nbsp;&nbsp;that we may not be allowed to do when managing big data sets.

&nbsp;&nbsp;A solution that would be fast for both small data sets and big

&nbsp;&nbsp;ones would be to keep only the feature id:

&nbsp;&nbsp;- if the data set is small, it can be kept in memory as a feature

&nbsp;&nbsp;&nbsp;&nbsp;collection, and mapping from id to feature should be fast (we

&nbsp;&nbsp;&nbsp;&nbsp;could create a feature collection implementation based on

&nbsp;&nbsp;&nbsp;&nbsp;a HashMap instead of using a HashSet).

&nbsp;&nbsp;- if the data collection is so big that we cannot keep it into

&nbsp;&nbsp;&nbsp;&nbsp;memory, query the disk/network storage using a FidFilter and

&nbsp;&nbsp;&nbsp;&nbsp;hope that the data source itself has some feature caching


&nbsp;&nbsp;Since feature collection can be wrapped to look as feature sources,

&nbsp;&nbsp;the query mechanism would work for both in memory and disk data

&nbsp;&nbsp;sources without changes in the shape -&gt; feature mapping code.

  • when thinking about ways to improve interactive rendering, please

&nbsp;&nbsp;consider that j2d renderer could be in future used for

&nbsp;&nbsp;headless server side apps (geoserver)...

&nbsp;&nbsp;so don&#39;t pretend to be in a swing environment.

&nbsp;&nbsp;This is just a praise, if that slows you down, forget

&nbsp;&nbsp;about it, we&#39;ll refactor the code to work server side later.

  • The featureModifier could be along the lines:

&nbsp;&nbsp;StyledGeometry getModifiedGeometry(StyledGeometry original)

&nbsp;&nbsp;this would allow to change both the style and the geometry.

&nbsp;&nbsp;Scaling can be achieved by wrapping the original geometry

&nbsp;&nbsp;along with an affine transform (see the TransformedShape class)

I still haven&#39;t looked at the source code, sorry.

April 10, 2015, 2:53 PM

CodeHaus Comment From: jelliott - Time: Fri, 6 Feb 2004 09:04:20 -0600
Thanks for your detailed comments on the highlighting stuff. In answer to your specific points:

1. The quadtree sounds sensible - from what you say, are you thinking that we should use the jts implementation?

2. You&#39;re absolutely right about mapping to features directly being a bad idea. Your idea of storing the feature id sounds very sensible. What is the contract that feature id should obey - is it supposed to be unique within a feature collection (in which case might we also need a reference to the feature collection) or across multiple feature collections.

3. I understand what you&#39;re saying about the rendered layer and client server applications. In fact, we may be about to implement an application relying on a client-server architecture with a large database of features. What do you think the future direction will be as regards this issue?

4. We thought about doing it that way ourselves (passing back a StyledGeometry object), it may be better perhaps. The idea of including an additional transformation seems nice.

April 10, 2015, 2:53 PM

CodeHaus Comment From: aaime - Time: Fri, 6 Feb 2004 09:35:21 -0600

  • yes, I&#39;d like to use the JTS quadtree implementation, no need to re-invent the wheel IMHO.

  • ID uniqueness... uhm, I&#39;m not sure. You should ask to the devel list, data store people will have an answer.

  • as far as managing big datasets are concerned, I think the following things are necessary or at least desiderable:

&nbsp;&nbsp;* implement tiling in the renderer so that not everything is loaded

&nbsp;&nbsp;&nbsp;&nbsp;in memory at the same time (specifically, when the area of interest

&nbsp;&nbsp;&nbsp;&nbsp;is smaller than the full data set)

&nbsp;&nbsp;* implement some kind of local on-disk cache, maybe based on picle,

&nbsp;&nbsp;&nbsp;&nbsp;to reduce the need to access the network

&nbsp;&nbsp;* implement active rendering aka threaded rendering, where the

&nbsp;&nbsp;&nbsp;&nbsp;rendering process is not blocking, but is progressive (with heavy

&nbsp;&nbsp;&nbsp;&nbsp;usage of VolatileImages to get good performance

Julian, can you post also the modified MapViewer with highlighting on?

Even better, subscribe to the devel list and attach the needed files

to the mail, so that everybody can see, test, comment and maybe include in cvs.

April 10, 2015, 2:53 PM

CodeHaus Comment From: aaime - Time: Sun, 28 Mar 2010 05:03:06 -0500
Mass closing all go-1 related issues as the module does not exist anymore








Affects versions