The Modules

PostgreSQL GeoObj data type.

The first issue is to develop a geographical data type.

“Stage 1: OGIS Compliant datastore

This would basically cover the OSVecDB proposal. Implement a 2D or 2.5D OGIS compliant datastore. For compatibility purposes I think we need to provide this anyway (eventually by providing persistent views into the Stage 2 datastore), and a lot of the work has already been done. Eventually this could form a "lite" version for those systems that do not require the capabilities/system overhead of Stage2.

Stage 2: Extend OGIS Schema (or replace it entirely)

Both Franck and I have concerns about the OGIS schema (apart from the (un)readability of the specs). This stage would address these concerns, providing full 3D type as well (and preferably temporal types/support?), possibly (preferably?) based on the upcoming ISO standards.

Possible Further Developments:

Provide data processing support within the database? AFAIK, processes running in the address space of the database will not incur the overheads of applications accessing the datastore, so to me it would make sense to build as much "intelligence" or data processing capability into the backend database system as possible.” (John Reid)

I think in my mind the OGIS does not fit principles 2 and 3 of FMaps. However the wording of operators and objects could be followed. It is also important to create data types that can be easily displayed.

I would prefer use a data type that contains also information on its representation. There are here 2 philosophies. Each object has its representation (MapInfo style) or the table has only one representation (ArcView Style). I would rather go for the first representation.

The type should contain for fast access:

1. object type

2. bounding box

3. bounding box volume

4. length or perimeter

5. area or surface

6. volume

7. representation [1]

8. vertices (variable length)

The geoobj will not follow the OGIS specification but will be a multipurpose 3D database storage object for OpenGL/Mesa Applications.

gtkfmaps Widget.

This widget is supposed to be totally independent of the FMaps application and could be used in other software to display the data stored in the database. For the moment I don't know how to make it a bonobo component but time will come...

The gtkfmaps widget is a sub class of the gtkglarea widget, therefore all the representation of the data is done using the OpenGL/Mesa structure. The widget should call a generalised library for converting coordinates. The library should be closed from GeoTrans than from PROJ4. Geotrans is a true 3D projection/datum library. PRO4 is getting slowly the capabilities.

The Main Application.

The main application should only present a catalogue system with query interface. The main application should load plug-ins that would perform specialised tasks. At the moment there is no plug-in capabilities, but developers should develop import/export capabilities as independent modules. Later one processing modules would be added.

The Metadata Window.

The Browser Window.