Skip to content

GeoGig Release 1.1.0

Compare
Choose a tag to compare
@emerkle826 emerkle826 released this 10 May 23:47
· 654 commits to master since this release

Downloads

LocationTech supported:

Plugins provided by Boundless:

GeoGig 1.1.0 Release Notes

May 10, 2017.

GeoGig 1.1 is now out for general consumption!

Stakeholders asked us to make GeoGig faster - and 1.1 is all about making things faster! Most importantly, we’ve added the Spatial-Index-With-Attributes and greatly improved the networking, caching, and rendering performance. We expect that all users will see substantial performance improvements.

For existing GeoGig installations, see our detailed Upgrade Guide (which includes helpful tips for installations).

Download bundles are available here

Release Overview:

This release introduces the long awaited spatial indexing capabilities to GeoGig.

GeoGig's spatial index can index the whole history of a repository's datasets. It was developed from scratch to take advantage of geogig's core design principle to efficiently store large amounts of features and quickly compute the differences between any two snapshots, the Merkle Tree (a.k.a. Hash Tree), that allows us to create a DAG (Directed Acyclic Graph) where each data snapshot is an entry point to the graph, while they share all but what changes internally.

To the best of our knowledge, this is the first spatial index that can effectively work on such a graph of data.

When an index is created for a feature tree (i.e. layer), a new tree is created mirroring the canonical tree contents, but using a quad-tree clustering strategy for its non terminal nodes.

Spatial indexing capabilities:

  • Indexes are automatically updated on commits. Create an index for a layer, and any operation that creates a new commit will trigger the update of the index (i.e. commit, rebase, merge, etc).

  • Materialized attributes: the spatial index can materialize any spatial or non spatial attribute of the FeatureType being indexed, in order to speed up attribute queries as well as spatial ones. For example, you might want to include the attributes needed by the Styled Layer Descriptor to properly filter out Features for rendering on a WMS; or include the time/elevation attributes to speed up queries on time series in GeoServer.

  • Spatial indexing command set: the geogig command line and its WEB API include a full set of commands to manage the indexes. Run geogig index --help or browse the online documentation at http://geogig.org/docs for more information.

Other improvements in this release:

  • Better support for foreign CRS definitions. Importing from datasets that define its coordinate reference system in non OGC WKT formats (e.g. most shapefiles) are now correctly matches to their corresponding CRS from the EPSG database, providing extra CRS metadata such as area of validity.
  • Better PostgreSQL backend caching. The PostgreSQL backend's internal cache uses an improved serialization format that's a lot faster to decode, while still allowing to control the cache size by storing serialized objects instead of Java objects.
  • Performance improvements to internal threading.
  • Fix a bug in updating quad-trees.
  • Fix a bug when retrieving repository logs for very old ancestors with large numbers of commits.
  • Enable and fix bugs around the ability to cancel many GeoGig operations.
  • Fix a bug in export-diff where incorrect commit IDs were sometimes being used.
  • Add and enhance concurrency testing.

The Spatial-Index-With-Attributes Index

Visualization of a Spatial-Index-With-Attributes Index

The new GeoGig index (a revision-sharing QuadTree index) greatly improves performance for the two most common types of queries - spatial queries and attribute queries.

For spatial searches, the QuadTree organization of the index makes for efficient retrieval of features.

The most common types of attribute query (“only display Highway and Freeways”, “only display data marked between these two dates” ) is also optimized by storing Extra Attributes inside the QuadTree. When executing the query, GeoGig can use the extra information in the index to quickly filter out unneeded features.

The end result is much faster query performance (and much less network traffic).