Why Develop FMaps.

There are many Geographical Information Systems (GIS) and Remote Sensing Applications (RS) out there. Few of them are “Free Software” as specified by the GNU foundation. Some of these applications are well know and in wide use. These applications can be found on www.freegis.org or on www.remotesensing.org. To name a few there is GMT, GRASS and OSSIM. OSSIM started at the same time as of this project. All these applications have their merits however they are missing a few points that I feel particular important.

The following 3 principles mustn't be compromised in this project to bring a new vision into GIS and RS.

A Centralised Database System.

In the world of GIS there are many files that represent the same real world features, sometime they get duplicated:

“In my experience, shapefiles seem to breed like rabbits in the directory tree, especially between different computers if shared network directories are not used properly ;-). A uni environment can be a good example of this, where many users may not have a GIS/computing background or have inadequate training due to various reasons (such as not enough staff to do any training, students fall asleep or didn't bother to turn up to the lecture as they will NEVER USE that knowledge and are only enrolled in the subject because it is a core component for their course ... ;-), and/or there is a high turnover of users (research students, postdocs and contract staff members) whom are mainly concerned with producing their thesis, paper, pretty coloured maps etc rather than a consistent dataset.” (John Reid)

The important feature is to avoid that users duplicate files, this could be solved by a centralised file system, but generally applications have difficulties to handle multi-users modifying the same file. Special data files must be developed. In the past speed of access to the data required simple file design, but now with computer power we can store data into a database and a real one like a client-server SQL database.

There are several database systems available. The criteria:

  1. The database must be “Free Software”,

  2. The database must be multi-user with password access,

  3. The database must support transaction as several tables can be involved in a modification

  4. The database must support binary and/or custom data type

The database in my mind that follows the best this model is PostgreSQL. Other database may fit the bill but PostgreSQL seems the most advanced project. Version 7.1 should have no more tuple size limitation, and the following versions will have replication in place allowing the have a distributed centralised geographical database.

“It probably makes sense to look at this initially as a two (or more) stage process. This way hopefully we can get a database store using PostgreSQL up and running fairly quickly. I suspect 3D types and topology might take a bit longer ....

As far as choice of database goes, PostgreSQL seems to be the best choice for the moment. However it would be good to keep in mind that eventually (once they become available!) any SQL3 compliant database could be used.” (john Reid)

A Metadata Catalogue.

“Other projects (such as Grass and OSSIM) have already poured significant (major understatement) development effort into the area of open source GIS. Any duplication of effort to me seems fairly pointless, and I think effort would be better redirected addressing any concerns within the scope of those projects. However, one area that currently seems to be lacking development is the provision of database support. GrassSQL provides limited support for attribute storage, however AFAIK there is no current support for storage of Metadata and vector/raster data within a RDMS or even better, ORDMS.” (John Reid)

Storing geographical object is nice, but it does not expose how the geographical object was acquired. It is a common mistake to compare geographical objects that have nothing in common. A electric network could have been digitised at 1/10,000 and overlay on a road network digitised at 1/50,000. Some will wonder why the electric network is so off the road... It is therefore important to store information about the data set: Metadata.

There are several standards put in place: ANZLIC, FGDC, ISO. The ISO Metadata is still a draft but contains the possibility of having 2 level of conformance. A simple Level and more Exhaustive Level with possibility to move from Level 1 to Level 2 easily. FMaps will follow Level 1 in a first step.

The Metadata should be used as a catalogue allowing the user to query and retrieve the features needed.

Automatic generation of Metadata by applications

Provision should be made so that Metadata can be generated by the application when creating new datasets (e.g. String the algorithm used, along with the values of any parameters passed).

The world is 3D (or 4D).

We live in a 3D world: a world with 3 dimensions. You may add the 4th dimension: time. Why most of the GIS are simple 2D? They are based on the concept of maps. I think this is wrong, many fields require 3D analysis: geology, marine, meteorology, space exploration,..

Existing GIS datasets are largely 2D in nature. Consequently support is required for import of 2D, 3D and 4D objects. Thought should also be given to the provision of a “n-dimensional datatype” (this may have uses in physics). Further, where information is missing in existing datasets, the application should have the ability to generate this information from other datasets (such as a DEM for elevation or the metadata for temporal information). Type inheritance should be used to provide this feature within the database access methods.

The geographical object must all be 3D, no 2D involved at all. This requires also to have a good datum conversion engine with a good projection system. Support should be provided for all common projections and datums. In addition, there should be the ability to define additional spatial reference systems, such as local planar coordinate systems and local datums (e.g depths down drill-holes).

Desirable Characteristics for Object-Relational DBMS

These are taken from “Object-Relational DBMSs: Tracking the Next Great Wave” (Michael Stonebraker and Paul Brown)

Base Type Extension.

CharacteristicImportance for FMapsImplemented in PostreSQL
Dynamic linking of user-defined functionsCriticalYes?
Client or server activation of user-defined functionsCriticalYes
Secure user-defined functionsYes?
Callback in user-defined functions??
User-defined access methodsCriticalYes
Arbitrary-length data typesYesYes

Complex Objects

CharacteristicImportance for FMapsImplemented in PostreSQL
Type constructorsCritical 
User-defined functionsCritical 
Arbitrary length data typesYesYes
SQL supportYesNot yet

Inheritance

CharacteristicImportance for FMapsImplemented in PostreSQL
Data and function inheritanceYes? 
Overloading  
Inheritance of types, not tables  
Multiple inheritance Yes (needs work)?

Rule System

CharacteristicImportance for FMapsImplemented in PostreSQL
Events and actions are retrieves as well as updates  
Integration of rules with inheritance and type extension  
Rich execution semantics for rules  
No infinite loopsObvious!