GeoTools : GUI Architecture

This page is for a general discussion of a new GUI architecture.
(Under construction, feel free to add random thoughts)


It should be remembered that GeoTools2 exists to allow the creation of applications. It is not intended to actually be one. Because of this, any 'architecture' should not place too many restrictions on how a developer might want to use it. A developer should be able to embed the GUI components we create inside almost any platform structure.

The main issue to be considered is - how to interact with a renderer? i.e. how to navigate, how to style, how to query and how to edit a map shown in a display.


The overall architecture should (probably) be platform neutral so as to allow SWT and Swing implementations
It needs to be easy to extend with new tools / variants of tools
It needs an event / notification system to automatically update the renderer should any of the following change:

  • data
  • filters
  • styling
  • selection / highlighting

It should allow for coordination between multiple views.

It should follow the MVC pattern - the entire state (visible extent, styling, selections...) should be external to any viewer component

It should support undo/redo as soon as possible (implies command/action pattern of some form)

Where possible selections / actions should be expressed using Filters - i.e. a select tool that drags out a box should actually generate an intersects or contains filter rather than working out the selected features for itself.


The convention when thinking about MVC is that there is one model for the view. However, I think we need to think about having multiple models...

e.g. The style, area of interest, data and current selections should be separate models

Use Cases

Other architectures

There are many other projects out there that face the same issues. The following links point to design documents and javadocs for other projects' GUI designs from which we might beg/borrow/adapt solutions.


To Matthias: the header of the page states clearly that here we are speaking about how to
design a map pane component that allows map viewing, zooming, panning, selection, editing
and so in with a general framework that allows library users to add their own way to interact
with the map. Using Netbeans as a base for building a complete GIS application if out of scope.
You may want to have a look at mapkenzie tought.
And yes, dialogs to manage and build coordinate systems would be appreciated if general
enough I guess (smile)

Anyway, I did not remove your contribution, just moved it to this comments so it is visible
but does not gets in the way of the main page topic.


Netbeans Platform, Netbeans-like GUI or?
by Matthias Basler,

I currently develop a GIS application (not yet published) that utilizes GeoTools. Currently it uses only the cts-coordtrans module, since I am not very far gone yet. My program uses a Netbeans-like UI with a tree view that shows the hierarchical structure of the project, a properties window that allow to edit an object's properties (e.g. the coordinate system of an object) and a desktop area that is thought to hold the maps, tables and other windows.
My program contains some GUI elements, that I could imagine to share with this GUI, e.g. a dialog for selecting geographical coordinate reference systems or building them from their components.

Although I have developed my own GUI architecture, which is much simpler (in both positive and negative sense) than Netbeans Platform, I would think that for a more general project like GeoTools it would be the ideal way to utilize the Netbeans Platform which provides a flexible and comfortable GUI framework. GeoTools would not need to care about the GUI architecture, but could concentrate more on the actual GIS aspects - at least I hope so. (wink)

Posted by aaime at Apr 16, 2004 14:12

I moved this comment from the Operations API page (bit more on topic here)

Posted by Anonymous at Apr 30, 2004 10:09

The MapContext needs methods like getWidth() and
getHeight(). So you can set and get the ScreenBounds();
This has the advantage for the Renderer. You don't need
work with AffineTransform for a small application.

I wish me like this:
DefaultMapLayer dml=new DefaultMapLayer(fs,style);
DefaultMapContext context= new DefaultMapContext();

Renderer lr = new LiteRenderer(context);

And the creating of a DefaultMapLayer is for me difficult.
An Contructor like new DefaultMapLayer(fs) is still sufficient.
You can still use a DefaultStyle for the Layer.
If you want to change the Style you can make it thereafter.

Posted by rschulz at May 01, 2004 02:57

HI, It could be very nice if the HUI could be implemented in Eclipse SWT or better in GEF. regards

Posted by at Oct 23, 2004 04:53