Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3


  • (warning) Update internals of GTRenderer implementations to take advantage of new classes
  • (warning) Update gt-swing code to take advantage of new classes

Documentation Changes

  • Target for sphinx documentation

History and Motivation

The MapContext (and MapLayer) classes are the last on Jody Garnett's top-to-bottom QA run for GeoTools 3.0. I am not quite sure of the history and motivation behind these classes; I suspect they were created by James in his early work on the SLD specification, or perhaps Martin in his working a "Lite" Java renderer. Oh wait it says Cameron Shorter (gasp!)


Over time they have been hooked up to more and different kinds of data with some truly amazing twists and turns in order to:

  • Render a FeatureCollection: This is obviously the start (ie what MapLayer) is responsible for rendering. These days it is always wrapped up in a DataUtilities.collection( featureCollection ) call so that a FeatureSource is available.
  • Render a FeatureSource: This is what we want to work with today; the FeatureSource api allows the renderer to perform queries against the data; and better yet look at the capabilities of the feature source in order to perform these efficiently; decimate the geometry and other assort tricks
  • Render a Grid Coverage: formally GridCoverages extend Feature; so you should just be able to render one correct? Well for GeoTools you package up the GridCoverage in a Feature with a magic FeatureType which it knows to un wrap it out of the Feature and then draw it as a GridCoverage.
  • Render a Grid Coverage: You thought that was fun? Well after looking at the fun low memory use provided by FeatureSource GeoTools 2.3 had a go at making use of a GridCoverageReader. Just pop a read into your feature and proceed like normal (can that be considered normal?)
  • Web Map Server Layer: a couple of attempts have been tried; the current one ends up as a GridCoveargeReader as above and is working quite well
  • Collection: a collection can also be used to render "Plain old Java Objects"; all that is needed expression based access provided by a PropertyAccessor implementation - currently supports use of Java Beans


  • My original idea was to follow the progress of the "Open Web Service" Context specification; it is formally defining different layers.
  • The OSGeo Foundation standards list is coming up with OWS Context conventions for more then just OGC services (WMS-C, Google Maps etc...)


So the proposal is pretty straight forward; a one two punch.


Code Block
public interface MapLayer(){
  Layer toLayer();


  • We are deliberately using an abstract super class rather then an interface for Layer because life is short and we don't want to break people over time.
  • In general each layer should have data + style at the end of the day
  • These are all concrete layers represented as specific combinations of data+style
  • New code examples will use the concrete classes directly; however DefaultMapLayer constructors will still function

Planning for DirectLayer

  1. We can now introduce the concept of "DirectLayer" that is a layer that is responsible for its own paint method
    • This can be used for WMS
    • Map decorations such as scalebars or grids
  2. Other concrete Layers
    • TileSet layers (provided by WMS-C or WMTS etc...)


Andrea had a number of ideas, but I could not keep track of them all:

  • (tick) remove Collection<Object> as it is a pain to support and not used
  • map context taking a referenced envelope is a pain for users (as it is hard to make referenced envelope of the correct aspect ratio)
    • the idea of "location+scale" - andrea did not like this because scale is hard to define. The idea of using "zoom" (ie ratio of pixel to map unit) may however be okay
    • mbedward would like to see this viewport model stuff seperate from the map context
  • there is a handover between streaming renderer and grid coverage renderer, perhaps this could be better represented as a DirectLayer
  • Imagine we need a bit of a review of how a MapLayer is connected with some code that is capable of rendering it. We may be able to handle this by producing a List<DirectLayer> where some of the entries are a specific renderer "Wrapped around" the original Layer
  • Taking these kind of steps should allow the rendering system to be better able to be multithreaded
  • Some of the methods are specific to the visual JMapPane such as isSelected; once again this could be handled as a wrapper specific to the application in question

Discussion of listeners:

  • Implementation uses CopyOnWriteArray for threadsafty; and is agressive about setting up listeners only if client code starts listening
  • Looked into using WeakReferences to hold listeners ... but it would clean up the kind of listeners we want to keep (say a listener that writes log information; or sends email) but not clean up the kind of listeners we want to throw away (listeners on user interface / featureSource etc...)
  • Explored use of List<Reference<XXXListener>> so that list could contain Reference and WeakReference on a case by case basis - added complexity not worth it

Use of dispose()

  • We all don't like the use of dispose()
  • We need dispose to clean up the listeners (see above)
  • It should remove references to featureSource, grid coverage reader etc .. but not close them
  • will use finalize to scream out a warning should dispose() not be called