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.
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:
The database must be “Free Software”,
The database must be multi-user with password access,
The database must support transaction as several tables can be involved in a modification
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)
“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.
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).
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).
These are taken from “Object-Relational DBMSs: Tracking the Next Great Wave” (Michael Stonebraker and Paul Brown)
|Characteristic||Importance for FMaps||Implemented in PostreSQL|
|Dynamic linking of user-defined functions||Critical||Yes?|
|Client or server activation of user-defined functions||Critical||Yes|
|Secure user-defined functions||Yes||?|
|Callback in user-defined functions||?||?|
|User-defined access methods||Critical||Yes|
|Arbitrary-length data types||Yes||Yes|