Release 1.4.0-beta.1

v1.4.0-beta.1

Version 1.4.0-beta.1

Release 1.2.1

GeoGig 1.2.1 Release Notes

November 23, 2018

1.2.1 is a maintenance release. It backports some fixes and improvements for managing GeoGig repositories in a PostgreSQL database. Hence you should only worry about an upgrade process if you have an existing GeoGig database in Postgres. On the contrary, if you're creating a new geogig database, there's nothing extra to do, GeoGig will create the correct database schema for you.

ls-repos

ls-repos shows repository names at a given base URI (i.e. directory or database). The verbose option can be used to generate CSV or a nice table with some extra information like number of branches, commits, feature types, and features per repository.

$ export repo="postgresql://localhost:5435/missouri?user=postgres&password=..."
$ geogig ls-repos --help
Usage: geogig ls-repos [options] <base URI> The URI without a repository name. (e.g. geogig ls-repos postgresql://localhost:5432/geogig_db?user=...&password=...)
  Options:
    -c, --csv
       If verbose output, use comma separated list instead of table output
       Default: false
    -v, --verbose
       verbose output
       Default: false
 $ geogig ls-repos $repo
groldan:missouri
volaya:missouri
 $ 
 $ geogig ls-repos -v $repo
╔══════════════════╤══════════╤═══════════════╤════════════════╤═══════════════╤════════════════╗
║ Name             │ Branches │ Total commits │ Unique commits │ Feature types │ Total features ║
╠══════════════════╪══════════╪═══════════════╪════════════════╪═══════════════╪════════════════╣
║ groldan:missouri │ 4        │ 125           │ 65             │ 5             │ 76,354,104     ║
║ volaya:missouri  │ 4        │ 122           │ 62             │ 5             │ 74,704,638     ║
╚══════════════════╧══════════╧═══════════════╧════════════════╧═══════════════╧════════════════╝

 $ geogig ls-repos -v --csv $repo
Name,Branches,Total commits,Unique commits,Feature types,Total features
groldan:missouri,4,125,65,5,76354104
volaya:missouri,4,122,62,5,74704638
 $ 

postgres-ddl

postgres-ddl is an utility to generate the DDL script to initialize
a PostgreSQL database to be used by Geogig. Most of the time Geogig
does it all by itself when first accessing the database, but it could be
the case where the database user used to connect with has no enough
proviledges and the script needs to be run by hand using psql for
example.

postgres-upgrade

postgres-upgrade is an utility to upgrade an existing geogig database
from any geogig version prior to 1.2.1. It will create a geogig_metadata
table and add a column to geogig_graph_edge in that is used to ensure the
correct order of commit parents in a commit graph traversal. Curiously,
in Postgres 9.4 it worked by accident, but Postgres 9.5+ returns the
parents in different order unless the query instructs it how to, which
is ok and exposed a bug in geogig itself.

If the PostgreSQL version is 10.0 or higher, and you're creating a new GeoGig
database, the DDL script that GeoGig runs to initialize it will now create HASH
indexes for the geogig_object_* tables, where the revision objects (commits,
tags, features, etc) are stored. This is because just since version 10.0, PostgreSQL
HASH indexes are WAL safe, and they result in slightly better performance under
load/with big datasets.

In order to fix an important bug, one of the geogig tables got a new column. For instance,
geogig_graph_edge has a new dstindex INT NOT NULL column, which is used to
ensure the parent commit ids of any given merge commit are returned in the correct
order when performing a commit graph traversal. For this reason, a new command has
being added to GeoGig's command line interface to aid in the upgrade process, both in
order to run the required DDL script, and to re-build the commit graph for all the repositories
in the database in one shot.

$ geogig postgres-upgrade "postgresql://<server>[:port]/<database>?user=<dbuser>&password=<dbpassword>"

Here is an example output of running postgres-upgrade:

$ geogig postgres-upgrade "postgresql://localhost:5432/geogig_repositories?user=geogig&password=..."

Running DDL script:

-- SCRIPT START --
CREATE TABLE public.geogig_medatada (key TEXT PRIMARY KEY, value TEXT, description TEXT);
INSERT INTO public.geogig_medatada (key, value) VALUES ('geogig.version', '1.2.1');
INSERT INTO public.geogig_medatada (key, value) VALUES ('geogig.commit-id', 'f34c8dfc07454b7fd2fa339a7ae36ebdd5f97159');
INSERT INTO public.geogig_medatada (key, value) VALUES ('schema.version', '1');
INSERT INTO public.geogig_medatada (key, value) VALUES ('schema.features.partitions', '16');
TRUNCATE public.geogig_graph_edge;
ALTER TABLE public.geogig_graph_edge ADD COLUMN dstindex INT NOT NULL;
-- SCRIPT END --
       
Upgrading commit graph for all 17 repositories...
Upgrading graph for repository reg_2016_wgs84_g_83ee687a
Finished upgrading the geogig database to the latest version.

This will connect to the database and run the necessary DDL sentences, as well as rebuild the commit graph of all the repositories, which is not something that can be done purely in SQL, and would be the same than running geogig rebuild-graph for each of the repositories in the database.

Finally, if the database is up to date with the latest geogig postgres schema, a message saying so will be displayed:

$ geogig postgres-upgrade "postgresql://localhost:5432/geogig_repositories?user=geogig&password=..."

Database schema is up to date, checking for non DDL related upgrade actions...

Nothing to upgrade. Database schema is up to date

v1.4.0-alpha-2

1.4.0-alpha-2 release

Release 1.2.0

The GeoGig team is pleased to announce the release of GeoGig 1.2.0!

This release has three major changes;

• Support for GeoServer 2.12 (web API Refresh)
• Improved performance for Replication - Clone/Fetch/Pull/Push
• Numerous usability improvements to support the GeoGig-QGIS plugin

Support for GeoServer 2.12 (web API Refresh)

One of the big changes in GeoServer 2.12 was to replace Restlet with Spring MVC. This necessitated GeoGig to also replace Restlet with Spring MVC. We made the new web API exactly equivalent to the old web API, so all the requests and responses are exactly the same - web client applications should not need any changes. We also made some improvements to the API documentation - see http://geogig.org/docs/interaction/web-api.html.

GeoServer 2.12 offers lots of new features and improvements: http://blog.geoserver.org/2017/10/17/geoserver-2-12-0-released/

NOTE:
For GeoServer 2.12 and newer, you must use GeoGig version 1.2.0 or newer (scroll down to the Downloads section).
For GeoServer 2.11 and older, you must use GeoGig version 1.1.1.

Improved performance for Replication - Clone/Fetch/Pull

The last few releases focused on performance related to rendering/querying data inside GeoGig. For this release, we have concentrated on improving how changes are shared among people (replication) in support of collaborative editing workflows.. This means that Clone/Fetch/Pull/Push operations are noticeably faster - sometime several orders of magnitude faster!

Numerous usability improvements to support the GeoGig-QGIS plugin

This release supports the upcoming GeoGig-QGIS plugin, which gives a powerful and user-friendly GUI front end to GeoGig. We've made some improvements - bug fixes and performance increases - to make this plugin as useable as possible. The GeoGig-QGIS plugin will be released on Boundless Connect (https://connect.boundlessgeo.com/) early 2018.

Bundles

LocationTech supported:

Command line app from LocationTech: geogig-1.2.0.zip

Plugins provided by Boundless:

OpenStreetmap data 1.2.0 plugin
GeoServer 2.12.x plugin
GeoServer 2.13.x plugin

NOTE: If you are looking for a plugin for GeoServer 2.11 or older, you must use version 1.1.1 of GeoGig

Release 1.2.0-RC1

The GeoGig team is pleased to announce the release of GeoGig 1.2.0-RC1!

This release has three major changes;

• Support for GeoServer 2.12 (WebAPI Refresh)
• Improved performance for Replication - Clone/Fetch/Pull/Push
• Numerous usability improvements to support the GeoGig-QGIS plugin

Support for GeoServer 2.12 (WebAPI Refresh)

One of the big changes in GeoServer 2.12 was to replace Restlet with Spring MVC. This necessitated GeoGig to also replace Restlet with Spring MVC. We made the new WebAPI exactly equivalent to the old WebAPI, so all the requests and responses are exactly the same - web client applications should not need any changes. We also made some improvements to the API documentation - see http://geogig.org/docs/interaction/web-api.html.

GeoServer 2.12 offers lots of new features and improvements: http://blog.geoserver.org/2017/10/17/geoserver-2-12-0-released/

NOTE:
For GeoServer 2.12 and newer, you must use GeoGig version 1.2.0 or newer (scroll down to the Downloads section).
For GeoServer 2.11 and older, you must use GeoGig version 1.1.1.

Improved performance for Replication - Clone/Fetch/Pull

The last few releases focused on performance related to rendering/querying data inside GeoGig. For this release, we have concentrated on improving how changes are shared among people (replication) in support of collaborative editing workflows.. This means that Clone/Fetch/Pull/Push operations are noticeably faster - sometime several orders of magnitude faster!

Numerous usability improvements to support the GeoGig-QGIS plugin

This release supports the upcoming GeoGig-QGIS plugin, which gives a powerful and user-friendly GUI front end to GeoGig. We've made some improvements - bug fixes and performance increases - to make this plugin as useable as possible. The GeoGig-QGIS plugin will be released on Boundless Connect (https://connect.boundlessgeo.com/) early 2018.

Bundles

LocationTech supported:

Command line app from LocationTech: geogig-1.2.0-RC1.zip

Plugins provided by Boundless:

OpenStreetmap data 1.2.0-RC1 plugin
GeoServer 2.12.x plugin
GeoServer 2.13.x plugin

NOTE: If you are looking for a plugin for GeoServer 2.11 or older, you must use version 1.1.1 of GeoGig

GeoGig Release 1.1.1

Downloads

LocationTech supported:

Command line app from LocationTech: geogig-1.1.1.zip

Plugins provided by Boundless:

OpenStreetmap data 1.1.1 plugin
GeoServer 2.9.x plugin
GeoServer 2.10.x plugin
GeoServer 2.11.x plugin

GeoGig 1.1.1 Release Notes

July 10, 2017.

This release sits on top of 1.1.0, adding even more performance and robustness improvements.

Performance

We’ve, again, improved communication between Geoserver/GeoGig and PostgreSQL - and that means it’s
FAST and requires 25% less network bandwidth. This means lower infrastructure requirements
and quicker responses.

NOTE: this requires an updated PostgreSQL driver; check the installation instructions.

Also, for this release we've started a performance assessment and improvement plan for geogig to geogig remoting (that is, cloning and synchronizing),
and introduced the first round of improvements for cloning from an HTTP remote to a local repository, with time savings of up to an order of magnitude!

There are still some rough edges specially when synchronizing a large number of commits that we'll be working on for the 1.2 series.

Caching

GeoGig 1.1.1 has a simplified and improved cache, offering;

• Very simple configuration - simply set the size of the cache with one number.
• Sharing - one cache is now shared among all your repos, allowing more heavily used repos more efficient access to the cache.
• Statistics - the cache’s effectiveness can now be explored, allowing administrators better information to make configuration decisions.
• Independence - the cache can be configured on a per-instance basis, allowing each instance to be individually tuned.

Please see the Shared cache documentation and how to
configure it on the GeoServer GUI.

Clustering

The GeoGig team have extensively tested the GeoGig GeoServer plugin in a clustered environment and we're more than glad with the results.
Please see the upgrade guide.

Bug Fixes

We performed more testing this release and found (and fixed) several minor problems. We also addressed a few issues reported on the mailing list.

• Fix Rocksdb backend's durability issues. A rocksdb backed repository was corrupted if edited through the WEB-API once the server was shut down.
• Avoid stack trace when trying to unalias a CLI command that doesn't exist.
• Avoid failure to return the pg config db if the repository does not exist.
• Fix error when cloning on Windows
• Fix an issue which prevents cloning into postgres from http.
• Fix empty string bug in custom geotools converter factories.It had the side effect of breaking the geoserver config UI
  for ImageMosaic layers as it uses the Converters framework to parse the "Bands" argument to an int[] that comes as an empty string.
• Upgrade downloadable postgres DDL script to include index tables
• Make sure PG connection pools are unique for a set of connection parameters add better formatting for documentation

Release 1.1.1-RC4

1.1.1 release candidate 4 for internal, cross-project testing.
Note 1.1.1-RC3 was dismissed and its tag removed as it introduced a small bug that was then fixed and lead to the immediate release of RC4.

Downloads

LocationTech supported:

• Command line app from LocationTech: geogig-1.1.1-RC4.zip

Plugins provided by Boundless:

• OpenStreetmap data 1.1.1-RC4 plugin
• GeoServer 2.9.x plugin
• GeoServer 2.10.x plugin
• GeoServer 2.11.x plugin

Release 1.1.1-RC2

1.1.1 release candidate 2 for internal, cross-project testing.

Downloads

LocationTech supported:

• Command line app from LocationTech: geogig-1.1.1-RC2.zip

Plugins provided by Boundless:

• OpenStreetmap data 1.1.1-RC2 plugin
• GeoServer 2.9.x plugin
• GeoServer 2.10.x plugin
• GeoServer 2.11.x plugin

Release 1.1.1-RC1

1.1.1 release candidate for internal, cross-project testing.

Downloads

LocationTech supported:

• Command line app from LocationTech: geogig-1.1.1-RC1.zip

Plugins provided by Boundless:

• OpenStreetmap data 1.1.1-RC1 plugin
• GeoServer 2.9.x plugin
• GeoServer 2.10.x plugin
• GeoServer 2.11.x plugin

GeoGig Release 1.1.0

Downloads

LocationTech supported:

• Command line app from LocationTech: geogig-1.1.0.zip

Plugins provided by Boundless:

• OpenStreetmap data 1.1.0 plugin
• GeoServer 2.9.x plugin
• GeoServer 2.10.x plugin
• GeoServer 2.11.x plugin

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).