GeoGit

Basics

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please add your feedback in the comments section.

Parent Project: 
Background: 

GeoGit explores the use of distributed management of spatial data. The project draws inspiration from the design of Git, but adapts its core concepts to handle versioning of vector geospatial data.

GeoGit started as a research and development project in October 2010 at Boundless, while developing an implementation [1] [2] of the OGC Geosynchronization Services 1.0 specification, under the OWS-8 Test Bed initiative, where it served as the back-end versioning engine the service implementation relied upon to provide inter-service synchronization of geospatial datasets.

This initial implementation proved itself useful to replace the 2006 Versioned-PostGIS DataStore (backend) and WFS-V (frontend) prototypes by a much more capabble and simpler to use versioning system. Then LISASoft joined the project and contributed to enhance the GeoTools DataStore implementation, provided an alternative serialization format, and prototyped some important operations like  push and pull to/from remote repositories, and branch merging.

After incubating as part of a Boundless (formerly OpenGeo) maintained GeoServer plugin, GeoGit debuted as a standalone open source project (on github and google groups) in September 2011.

LMN Solutions has been helping since then to delineate the project's goals and became a major contributor to the project.

GeoGit is under active development, backed by an experienced team, build infrastructure and has reached the stage of issuing alpha releases to the public.

Scope: 

GeoGit provides a distirbuted version control system for the efficient handling of spatial data.

  • manage spatial data in repositories
  • import raw spatial data from common formats such as shapefiles, PostGIS, MS SQL Server, and SpatialLite
  • import raw OpenStreetMap data and full history, apply mappings to raw OSM data to create specific datastets, and push edits made in geogit to OSM 
  • track changes to spatial data in a repository with support for history, branching, merging and rollback
  • support peer-to-peer distributed version control via pusing changes between repositories

GeoGit is available as both a command line application, and as a Java library. Also, a Quantim GIS plugin is planned and under initial development by Boundless.

Description: 

GeoGit is a Distributed Version Control System (DVCS) specially designed to handle geospatial data efficiently. It takes inspiration from the source code versioning system Git, but has an approach suited to the spatial data it manages. GeoGit efficiently handles very large binary data, divided up into features with the opportunity to optimise spatial operations using a spatial index. This is in contrast to Git which handles large text data, divided up into lines.

Users are able to import raw geospatial data (currently from Shapefiles, PostGIS, MS SQLServer, or SpatiaLite) in to a repository where every change to the data is tracked. These changes can be viewed in a history, reverted to older versions, branched in to sandboxed areas, merged back in, and pushed to remote repositories.

GeoGit is available as a command line tool with the following commands:

  • add             Add features to the staging area
  • apply           Apply a patch to the current working tree
  • branch          List, create, or delete branches
  • cat             Provide content of an element in the repository
  • checkout        Checkout a branch or paths to the working tree
  • cherry-pick     Apply the changes introduced by existing commits
  • clean           Deletes untracked features from working tree
  • clone           Clone a repository into a new directory
  • commit          Record staged changes to the repository
  • config          Get and set repository or global options
  • conflicts       Shows existing conflicts
  • diff            Show changes between commits, commit and working tree, etc

GeoGit is also provided as a Java Library for direct use.

 

Why Here?: 

GeoGit is set to achieve its intial scope, and we are seeing a huge pent up demand for a product in this space. LocationTech offers a vendor nuetral platform, helping ensure GeoGit's functionality is embeded and ubiquitous in the next generation of spatial software. The GeoGit participants are experienced with LocationTech and respects the business-friendly approach and governance procedures provided by the Eclipse Foundation.

The timing is appropriate, with GeoGit rapidly approaching its initial 1.0 release, the project will benefit from the visibility afforded a LocationTech project.

Initial Contribution: 

Initial contribution, available on gihub, is provided by OpenPlans under a BSD license. Full list of contributors can be seen on GitHub.

Project Scheduling: 

The following activities will need to be coordianted for the initial 1.0 release:

  • Tag and submit the initial source code as soon as the project is approved in order promptly start the parallel IP process.
  • Migrate codebase to LocationTech GitHub
  • Coordiante review of dependencies, including submission of GeoTools Version used
  • Tag and review the 1.0 release codebase prior to release
Future Work: 

Future work will be guided by GeoGit collaborators. Priorities include:

  • Efficient Spatial Index use
  • Use GeoTools DataStore FeatureId / ResourceId to allowing high-level query of history
  • Documentation and Integration Guidance for projects embedding GeoGit functionality
 
People

Comments

rstocker's picture
rstocker says

I would recommend changing the name from "GeoGit" to something else. Reasons:

  1. From just reading the name, I would expect that it was related to Git (e.g. an extension or tool working with Git repositories). But the only relation seems to be that it draws inspiration from how Git (or a DVCS in general) works. IMO this is misleading and may look like an attempt to benefit from the good name that "Git" has.
  2. Pronouncing it may be hard, as "geo" has a soft "g" [dʒ] whereas "git" has a hard "g" [g].

This may be a good time to consider such a name change.

Posted on Sat, 10/19/2013 - 11:10