Skip to end of metadata
Go to start of metadata

Requirements for GeoWidgets and their status

Work on this MapFramework is crucial for GeoWidgets. On this page I give an overview about what has to be done in which order to continue development on GeoWidgets.

Sub components of this RND project

Note that these sub components are not necessarily independent of each other.

Things to consider:
MapFramework API does not work without a Catalog API, which tells how to access the data and metadata from the map layer.
MapFramework API + Catalog API do not make sense if there is no renderer, that can use the MapFramework API. It might be possible to create a wrapper around LiteRenderer that converts the new MapFramework to the old one, (something similar is done in uDig) but I am not sure how much work this would be.
Rendering API requires knowledge about data access as well in order to read the data from the map layers

GeoWidgets components requirements

Following widgets or widget sets are in preparation or already under development, but not yet working:

Widgets

Require

Status of requirements

Map canvas

MapFramework
Catalog
Rendering

Prototype
Idea
Idea

Legend widgets

MapFramework
Catalog
(Rendering)

Prototype
Idea
(Idea)

SLD Styling widgets

org.geotools.styling
(Rendering?)

Finished
(Idea)

Most urgent problems to solve and things to do in this field

In the order of percieved importance. Any help is appreciated:

  1. Backport CatalogAPI and combine it AS IS with the new MapFramework, just to get things working at all.
  2. Complete MapFramework implementation
    Decide if to use the GeoAPI Envelope or still the JTS Envelope (and change later)
  3. Design and implement new Rendering Architecture with a clear distinction of tasks between Render target,
    viewport state, Map renderer (and later specific layer renderers)
    This is impossible without the experience especially from the uDig side.
  4. Improve CatalogAPI with respect to metadata handling and Filter

Comments welcome.

  • No labels