I published this article on 27 November 2007, under another blog (which has suffered link rot) so I'm republishing here for archiving.
Federated Geo-synchronization
Standards and tools for reliable data synchronization in Spatial Data Infrastructure and field based data collection.
Overview
This article describes the issues and technical solutions associated with Federated Geo-synchronization.
Lisasoft aims to contribute to these solutions as part of the OGC’s Open Web Services Testbed 5.2.
To strengthen and refine our requirements, we are looking for Agencies which would benefit from solutions identified here. Please leave a comment, or contact me if you are interested.
Technical Problem Statement
As spatial databases become distributed and collaboratively maintained, traditional database transaction models ineffectively handle modern scenarios.
Figure 1 Synchronising databases in a Spatial Data Infrastructure
Users require current data from remote agencies. Data may be stored on a slow or unreliable server or behind an unreliable internet connection.
Updates may come from remote field workers, trusted external organizations, or general internet users. Identities must be confirmed, updates validated and applied, or rolled back to a previous version.
Technical Design
Figure 2 Caching WFS-T in field, local and remote networks
This project will:
Make a Spatial Data Infrastructure (SDI) fast and robust by caching remote WFSs locally.
Provide WFS Synchronization to allow real time data updates between agencies.
Ensure interoperability between agencies and applications by proposing required extensions to Open Standards.
Ensure wide adoption by providing all components free as Open Source Software.
Provide desktop and mobile, field based data collection tools.
Version WFS-T
A Transactional Web Feature Service (WFS-T) provides an OGC standards compliant web interface for downloading and updating vector features over the internet. To date the WFS-T standard doesn’t address version history.
Versioned WFS-T enables users to roll back to previous versions, track update history, check differences between updates. A versioned WFS is required to support a cached WFS.
Version WFS-T Development
Geoserver developers have developed a Versioned WFS-T by extending the WFS-T specification to include standard version attributes. As at May 2007, the Geotools version code is complete, but still in alpha state. It requires configuration web pages to ease operator use, packaging into a release and real world testing.
The extensions to the WFS-T specification need to go through the OGC standards process.
Security
Security involves: authentication (to verify who a user is) and authorization (to specify what a user can view or update).
Security Development
Geoserver has prototype authorization and authentication code. Access is provided to the level of WFS. Granular access to a layer or a specific feature is not supported. The code still requires refinement, a user interface and integration with the baseline.
Clients like Udig, Mapbuilder and OpenLayers require security logic. Some of this will be addressed during the Canadian Geographic Data Infrastructure Interoperability Pilot, due to complete October 2007.
Cached WFS-T
A Cached WFS mirrors a remote WFS locally. A Cached WFS-T also caches WFS-T updates when disconnected from the remote WFS.
A Cached WFS-T is used when:
Cached WFS-T depends upon the Version WFS-T protocol.
Cached WFS-T Development
An alpha version of Cached WFS (read only) is implemented by Geoserver. A friendly user interface is required to bring this to COTS quality.
Minimal development is required to implement Cached WFS-T (with writes) which has a basic conflict management interface.
Business rules for managing updates and conflicts from disconnected clients will be addressed in a second development phase.
Desktop Mapper
Figure 3 JGrass desktop mapping application
Desktop Mapping offers powerful data manipulation and analysis. There are a number of clients available both proprietary and open source with varying levels of functionality and standards compliance.
Desktop Mapper Development
A prime candidate for an Open Source Desktop Mapper is UDig and JGrass which are combining forces to provide:
User friendly mapping interface.
Extensive map analysis tools from Grass.
Access to numerous mapping format and data sources from Geotools.
Extensible architecture from Eclipse
Development is required to include:
More work is required to add:
Mobile Mapper
Field operators need to create or update geographic data while in the field.
A typical use case involves:
Download geographic data while in the office
Disconnect from the network
Modify, create and delete features and datasets. Interface with a GPS to collect feature information.
Synchronize changes with local or remote data-stores via Standards compliant WFS-T protocol.
Mobile Mapper - Tablet Development
Figure 4 Ultra Mobile PC with slide down keyboard
A Tablet or Ruggedized PC provides the same operating environment as a desktop PC. So the Desktop Mapper will port directly to the Tablet.
Integration with a GPS is the only extra development required for the Mobile Tablet.
Mobile Mapper - PDA Development
Figure 5 Mapping on a PDA
PDAs are often used for field work because they are cheaper and smaller than laptops. Along with smaller size they are also less powerful and have less storage capacity.
Cut down versions of Windows (Windows CE) and Java (J2ME) run on most PDAs.
Investigation is required to determine effort required to port the Desktop Mapper to the PDA and whether alternative development would be more effective.
Browser Editor
Figure 6 Mapbuilder, a browser map editor/viewer
Browser editors efficiently enable data collection from the public or remote workers.
Browser clients can also publish public map data.
Browser Editor Development
Openlayers and Mapbuilder are working together to produce Open Source, Open Standards Browser Based mapping client. WFS-T editing is supported but needs to include business logic associated with user authentication and access rights.
Open Standards
Multiple agencies tend to run multiple technical solutions. This is fine so long as they interoperate through Open Standards.
The Versioned WFS-T protocol will be presented to the OGC to be formalized as an Open Standard.
Open Source
Free tools reduce entry costs to a Spatial Data Infrastructure which will maximize participation.
Open Source software already provides the majority of the functionality required by this project which means tools can be built for minimal cost.
Deliverables
Essential Deliverables
Essential Deliverables are required to meet immediate customer needs. These phases are low risk as the functionality already exists in tested or prototype code.
Phase 1: Mirror remote WFS locally
Phase 2: Update remote WFS-T from remote or disconnected client
Phase 3: Security - Role based editing and views
Optional Deliverables
Optional Deliverables are nice to have and involve further development with associated risk.
Phase 4: Universal Client for easy install
Phase 5: Universal Client on PDA
Schedule
| OWS 5.1 |
|
| RFQ (5.1) Issued | May 11, 2007 |
| OWS 5.2 |
|
| Revised RFQ issued | July 9, 2007 |
| Questions Due & Bidders’ Conference | July 16, 2007 (TBR) |
| Clarifications Posted | July 23, 2007 (TBR) |
| RFQ Responses Due | August 3, 2007 |
| Kickoff Meeting | week of September 10, 2007 |
| Interim Milestone | week of November 12, 2007 |
| Demonstration Milestone | week of January 7, 2008 |
| Final Delivery | February 18 – February 22, 2008 |
| Commercialize product, provide support, consulting and customized solutions. | March 2008 – 2009. |
Delegates who voted for the FOSS4G 2009 presentations ranked the OSGeo comparison projects very highly, which is something I suggest hopeful FOSS4G 2010 presenters take note of, because competition for speaking slots will be fierce.
