Skip to end of metadata
Go to start of metadata

A picture emerges - Visual progress

This page shall contain an update of where we are and where the journey might be going.

Map framework API

UML diagram

The UML diagram below shows with what we have come up so far. A prototype of the depicted model is in testing, but this does at all not mean that this structure is final. Please note that for the sake of clarity only the most important or some representative methods and functions are shown. Editing methods (setXXX(...)) and default implementations are mostly omitted.

UML for proposed map framwork.
Click it to see it in full size.

Update: In my current concept the abstract _GeoResource class and surrounding classes (GeoResourceInfo, Resolve, _Service, ServiceInfo and possibly more) will more or less have the same functionality and syntax as in uDig. However this will be decided later. See Jody's page on backporting the Catalog API: http://docs.codehaus.org/display/GEOTOOLS/CatalogAPI
One question there is where to draw the borderline between the general concept that this map framework is part of and the uDig-specific needs and concepts for the Catalog API.

Another question not yet addressed is the way of metadata handling in maps and map layers (... and which metadata is needed in order to satisfy all stakeholders).

For opinions and solutions, please tell the list or comment this document.

Use cases and examples

Following code snippet stems from the good old "Spearfish demo" and was edited to show the map creation methods of the new map framework API. Also it shows that there is already a JFace-based TreeViewer in preparation that uses a MapCollection (later also a MapContext) directly as model and allows to edit this model and respond to model changes.

Until now there isn't any "visibility" logic implemented that would react on setting, lets say, the "Line objects" group to invisible. (What to do: Grey all children in the widget?, Set all children to invisible?)

  • No labels