Hello everyone,
This is a request for comments and corrections.
The following document will be posted to the user mailing list as an
answer to the common question "what's going on with the GUI"? It
represents, my less than perfect understanding of the current (Oct.2005)
state of affairs. Please send me your comments and corrections to me
directly. I will revise this and either submit a second draft or post it
to the user list.
Thanks,
Adrian
***********************************************************************
** DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT **
***********************************************************************
Drawing Maps on the Screen with Geotools
========================================
Most developers using the Geotools library want to figure out how to
display a map on the screen. This is such a strong desire that several
different developers have come up with several different ways to do
things. Worse, all of the different ways of doing things currently
depend on parts of the Geotools library which are being discarded. Even
worse, developers are waiting for a few outside efforts to reach
maturity before they will upgrade these display components. By the 2.1
release of Geotools in 2005, these different ways had become exceedingly
confusing.
This document will try to clear up the confusion and explain where
things are going for the near future.
The short version:
=================
Geotools how now (Oct. 2005, release 2.2M0) decided to standardize on
the GTRenderer interface and the StreamingRenderer implementation of
that interface.
There are currently no GUI components which use that interface. However,
the GUI components using the older deprecated interfaces still work.
Work on porting the older GUI components to the new interface is
currently waiting on the GeoObjects project which aims to define a
standard way that these GUI components should behave.
Intro: Geotools is *not* an application:
=======================================
One of the issues involved in the display of maps on the screen is that
Geotools considers itself a code library *not* an application. Since
displaying maps lies at the core of what applications do, it is assumed
that the application will end up being responsible for most of the work
displaying maps. Since different applications have different
requirements, map display will be handled differently by each of these.
For example, web sites which use Geotools to show maps will probably
work through a java applet and therefore will not be able to access
swing elements.
Geotools has been reluctant to take on, as part of its mission, the
display of maps before displaying maps could be treated as a
standardized tool. Since the GeoObject project aims to define the
standard way to treat these components, Geotools is waiting for the
GeoObject project to mature at which point Geotools will actively
maintain implementations of these widgets.
Background: How geographic data gets displayed:
==============================================
In order to explain what is going on, we all need to share some
terminology on how Geotools actually draws a map.
In order to get Geotools to draw a map, Geotools needs (1) data, (2) a
description of how different data elements should be drawn, (3) a
component capable of output (i.e. drawing), and (4) a set of components
to deal with the window system and the user's input.
(1) Data + (2) Style + (3) Renderer + (4) GUI
Let's cover this in slightly more detail:
1. Data: To draw a map we need stuff to put in the map
First, Geotools needs some data to work with. This means the
developers need to create a bunch of features to display which
can be done by hand (tedious) or using a source of data such as
files. The way this is done is explained in other documents.
Most ways of making a map require that features be collected
into separate layers. The idea is that each layer will group
similar features that a user would want to display together and
display using a similar
2. Style: Create descriptions of the appearance of different features
Somehow a decision has to be made about what appearance the
various pieces should have. For example, geographic points can
be displayed as single black pixels, as circular blobs, as
shapes such as a cross, or in many different ways. Similarly
Geographic Lines can be shown as single pixel black line
segments or as wide anti-aliased blue line segments. Simple,
easy to use components decide what to do on their own. More
sophisticated map display components let users decide what
styles should be used for what elements. In a full blown
software system, these decisions can be linked to other
attributes of the data elements, for example displaying a group
of point features by placing a circle centered on the
coordinates of the points but making the size of the circles
depend on one attribute and the colour of the circles depend on
another attribute.
Several of the display systems are split with one version making
all the decisions about style and the second making all the
3. Renderer: Create a component capable of drawing pixels on screen
Some component must know how to change the pixels in an image
based on the content of the data since, at the end, an image is
what is actually displayed. In Geotools, this element is called
the renderer and is the core of the display system. There are
lots of issues involved in this step and potentially lots of
tradeoffs in speed, detail, flexibility, and complexity. This is
one of the reasons that different approaches have been tried in
Geotools.
However, this component is sophisticated several efforts have
been created to provide developers with GUI components which
operate at a higher level, the GUI components.
4. GUI: Create windows and handle keyboard and mouse events
This component will group together all the previous elements,
display the elements on the screen, and perhaps interact with
the user.
In summary, we need:
Data (i.e. Features)
|==> Define some Styles
|==> Create a Renderer
|==> Create a GUI to display the pieces
The various pieces:
==================
This section explains what pieces currently exist. Please skip it and
focus on the next section. It is here to explain the layout of the code.
Old Renderers:
-------------
Several renderers have existed in Geotools which are now no longer used.
The older renderers include:
liteRenderer
liteRenderer2
j2dRenderer
please don't use these unless you have to.
Going forward, only the following should be used:
GTRender --- the interface
StreamingRendere --- the standard implementation
Old GUI Elements:
----------------
All of the GUI elements are in the 'migrate' module since they all
currently rely on the older renderers. These elements all belong in the
'org.geotools.gui' package.
There have been three significant in the Geotools code base to develop a
GUI element that could be used easily by users to display their data. As
of the begining of October, 2005 these all use swing.
1) Cameron Shorter's MapPaneImpl
Cameron Shorter created what appears to be the most sophisticated gui
element. This effort includes:
* /module/migrate/src/org/geotools/gui/widget/MapPane --- the
interface
* /module/migrate/src/org/geotools/gui/swing/MapPaneImpl --- an
implementation
* /module/migrate/src/org/geotools/gui/tools/* --- various
alternative states for user interaction.
* /module/migrate/src/org/geotools/gui/swing/event/*
<todo>
The idea of this approach is:
...and point to any existing tutorial.
</todo>
2) Martin Desruisseaux' MapPane
Martin Desruisseaux' work unfortunately uses the same name. This is
because he was attempting to write a replacement for the earlier effort.
This code includes:
* /module/migrate/src/org/geotools/gui/swing/MapPane.java --- an
implementation.
* /module/migrate/src/org/geotools/gui/swing/StyledMapPane.java
--- another implementation which gives users more power to
create and modify styles.
<todo>
The idea of this approach is:
...and point to any existing tutorial.
</todo>
3) Jessie Eichar's work
Jessie Eichar's work includes:
/module/migrate/src/org/geotools/gui/swing/LiteRendererStyleMapPane.java
/module/migrate/src/org/geotools/gui/swing/StyledLiteRenderer.java
This may have been only a proof of concept for the 'liteRenderer'.
Certainly this effort looks like the least polished.
Ongoing work:
============
The current renderer interface are
* GTRenderer --- the interface
* StreamingRenderer --- an implementation which is currently the
Geotools default
The only GUI components are the ones using the older renderers.
Future work:
===========
Several plans are apparently brewing and it is not entirely clear which
will come to fruition first.
Porting the uDig GUI component:
------------------------------
uDig, since it displays maps, obviously has a GUI component for that
purpose. Apparently there may be some work to port that code to the
current renderer interface.
Creating a GeoObject map display widget:
---------------------------------------
The GeoObject project, a derivative of the GeoAPI project, is trying to
create a standard approach to the higher level geospatial GUI
components. Apparently they are working on a widget which would display
maps. A stated intent of several Geotools developers is that, once this
work is complete, one of the existing implementations will be updated to
act as a GeoObject map display widget.
***********************************************************************
** DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT **
***********************************************************************
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
