Welcome

Welcome to the GeoSpatial Networked Database. This is a networked database used to store a range of geospatial data, particularly vehicle tracks.

Requirements

Here's a High Level set of requirements, but I've also invested some thought into Analysis Use Cases and some more tentative requirements, plus an overview of the Underlying Problem. From reading legacy documents I've been able to identify some Analysis Requirements.

As my understanding of the available technologies matures, informed by standing on the shoulders of the giants I've talked to in the last few days, I've started to over-step my abilities and consider Candidate Technologies (including thoughts on GWT activities and places and GWT MVP Structure ). ETL forms one of the candidate technologies, thoughts on which are recorded in ETL Findings.

Strategies

The wide range of schemas would seem to suggest switching to a schema-less environment. Once we get to a Big Data environment this brings maintainability concerns. A workaround has been identified. It may be possible to constrain the wild-beast by imposing order on information going in and out of it. These design thoughts are recorded in Hierarchical Schemas

Candidate technologies

Should we go down the document-oriented datastore route, it appears that the embryonic OrientDb may prove very useful - particularly given its support for inherited schemas plus Sql-like interactions. But first we need to consider its technical applicability, the results from which are presented in test results

Since this will be a very web-centric system, and GeoJSON is the geospatial version of JSON. Read more GeoJSON Thoughts, plus some thoughts on the Document metadata, and the Schema Validation Strategy.

I've also put some thought into web Use Cases, plus a UI Mockup. We need a certain degree of Web-UI to test the developing backend. This is recorded in the Debug UI. The OpenLayers application will form a central part of the Web UI for the application, and the Debug UI

There remains the possibility of a PostGIS RDBMS solution. A design for such a solution is considered at PostGIS design

First design of GND gwt application is placed in the GND Gwt app design. Thoughts on the file-format to be used by the app are recorded in GND File Format

After a period of research, I've managed to come up with a Version Control Strategy

I've also put some thought into ElasticSearch_trials.

We've also successfully put a web-app (GWT in this case) into CouchDb to give it write access Installing a CouchApp

Design Documents

Here is a collection of the formal documents recording our (current) implementation.

• Design for Gwt app as used for web-interface
• Alternative Design Based on GWT-Platform Framework as used for web-interface
• GND_File_Format as used within the CouchDb
• High Level Backend Architecture
• The Version Control Strategy used for individual documents the database, plus the dataset provenance across a series of master/child documents.
• Significant View and Show functions in the CouchDb store
• Ian's thoughts on where GWT Code Splitting could be applied
• Here is a SmartGWT design from Barış
• To aid getting started with the app, you may say: Show me some data
• Here's the current working version, hosted within CouchDb