[Geoserver-devel] Propose a new community module: geoserver-sync (Rahkonen Jukka)

Q: Are the hashes indexed spatially so that the client can synchronize very fast a small area of interest? I saw “p: position” in the PDF but I am not sure if it means the position in the hast tree or in the world or if they are related.

A: The hashes are organized into a Merkle Tree (http://en.wikipedia.org/wiki/Merkle_tree) and are not indexed spatially. p:position is the position in the tree, since we try to just send the parts of the tree that are different. However, the use case of synchronizing a small area of interest is supported by combining the contributed Sha1 filter along with an area filter against the features. Since the features are indexed spatially, it should be very fast. The spatially filtered features skip SHA-1 computation. We’ve used other types of feature filters to split up the features based on feature attributes and then synchronized each set separately. For example, suppose you have a Vehicle feature with a type attribute that can be ‘Plane’, ‘Train’, or ‘Automobile’. You could synchronize the planes more frequently by having two sets, one with a filter for ‘Plane’ and the other that has a filter for not ‘Plane’.

Q: Can Geoserver act also as a client? Then there could be network of Geoservers acting as regional mirror servers which could be synchronized from the master service. The master could be reserved for maintaining data and synchoronizing and clients could take the burden of WMS, WFS etc services which could be flexible, scalable and cost effective.

A: Some more code is needed to make Geoserver act as a client. The client library has a listener interface for what it detects as the required changes to get in sync with the server:

public interface FeaturesChangedListener {
void featuresCreate(Feature feature);
void featuresUpdate(Feature feature);
void featuresDelete(Feature feature);
}

The code that is missing is to implement this interface and apply the changes to Geoserver. I guess the mirrow Geoserver would need some way to configure where the master is and what feature sets (or subsets) to sync. The current client library is combined with some other FSI code that updates World Wind. The model implemented is master-mirror. We are doing some more research into master-master synchronization where either side can make a change and then exchange messages to get back into synch. I’d have to get government permission to release this new work to opensource if folks are interested.

Finally, I just turned off digests to help me manage the mailings from the list better. If I’ve missed responding to anyone, poke me again please.

Robert Hastings, Lab-SDL: 619-553-7006, Cell: 858-395-4436, Moebius: 858-455-5431x210, Lab-250: 619-553-2263

This sounds similar to how things are done in GeoGit. GeoGit also has a synchronization system based on Merkle trees that runs inside of GeoServer (optionally; the server can run in a standalone mode as well.) The GeoGit project is currently moving quickly and breaking compatibility as needed so we have not contributed the extension to GeoServer yet, but you may find the project interesting anyway.

https://github.com/boundlessgeo/geogit/

···

On Sat, Dec 14, 2013 at 10:24 PM, Robert Hastings <rhastings@anonymised.com> wrote:

Q: Are the hashes indexed spatially so that the client can synchronize very fast a small area of interest? I saw “p: position” in the PDF but I am not sure if it means the position in the hast tree or in the world or if they are related.

A: The hashes are organized into a Merkle Tree (http://en.wikipedia.org/wiki/Merkle_tree) and are not indexed spatially. p:position is the position in the tree, since we try to just send the parts of the tree that are different. However, the use case of synchronizing a small area of interest is supported by combining the contributed Sha1 filter along with an area filter against the features. Since the features are indexed spatially, it should be very fast. The spatially filtered features skip SHA-1 computation. We’ve used other types of feature filters to split up the features based on feature attributes and then synchronized each set separately. For example, suppose you have a Vehicle feature with a type attribute that can be ‘Plane’, ‘Train’, or ‘Automobile’. You could synchronize the planes more frequently by having two sets, one with a filter for ‘Plane’ and the other that has a filter for not ‘Plane’.

Q: Can Geoserver act also as a client? Then there could be network of Geoservers acting as regional mirror servers which could be synchronized from the master service. The master could be reserved for maintaining data and synchoronizing and clients could take the burden of WMS, WFS etc services which could be flexible, scalable and cost effective.

A: Some more code is needed to make Geoserver act as a client. The client library has a listener interface for what it detects as the required changes to get in sync with the server:

public interface FeaturesChangedListener {
void featuresCreate(Feature feature);
void featuresUpdate(Feature feature);
void featuresDelete(Feature feature);
}

The code that is missing is to implement this interface and apply the changes to Geoserver. I guess the mirrow Geoserver would need some way to configure where the master is and what feature sets (or subsets) to sync. The current client library is combined with some other FSI code that updates World Wind. The model implemented is master-mirror. We are doing some more research into master-master synchronization where either side can make a change and then exchange messages to get back into synch. I’d have to get government permission to release this new work to opensource if folks are interested.

Finally, I just turned off digests to help me manage the mailings from the list better. If I’ve missed responding to anyone, poke me again please.

Robert Hastings, Lab-SDL: 619-553-7006, Cell: 858-395-4436, Moebius: 858-455-5431x210, Lab-250: 619-553-2263


Rapidly troubleshoot problems before they affect your business. Most IT
organizations don’t have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

David Winslow

Boundless - http://boundlessgeo.com/