This is cool. I feel like "versioned editing" and "data merging and validation workflows" are things that have been talked about vaguely as part of the roadmap, but we've never done a real in-depth exploration of what it would take to actually do that well. It does seem like its a very deep problem.
David, we've talked a bit about meeting at some point to take a look at the project roadmap and break the high-level items into their technical dependencies. I think that process, and emails like this one, will help us form a plan so that we can make sure we get to implementing all this. As a corollary to that, if there are any other big roadmap item ideas that are out there, I'd encourage people to get those onto the project roadmap soon, so that we can crunch through them when we do our first-pass technical evaluation (probably some time next week) On Wed, Jun 23, 2010 at 5:13 PM, David Winslow <[email protected]> wrote: > On the GeoWebCache thread I brought up the idea of caching features (as > opposed to tiles) and Gabriel asked me to start a thread on the topic. > Here goes! > > For some features under discussion for the GeoNode roadmap - notably > http://code.google.com/p/geonode-roadmap/issues/detail?id=4 - it would > useful or necessary to have a GeoNode site cache all or part of a > feature layer. Some features related to this include: > > * Incremental caching - Watch some sort of feed of modifications to a > "master" data source and synchronize only the changes. Some related > tech for this includes the GeoSync extension to GeoServer, the osmosis > tool for applying OpenStreetMap diffs to a PostGIS database, and > rsync/subversion/git in non-spatial fields. > > * Changeset Merging - Have changes go back into the "master" from a > downstream cache. I think there are a lot of use cases for this, bonus > points for having things other than a GeoNode website able to upload > batches of changes... Think of an iPhone or Android app that could batch > up some data collected "in the field" by volunteers. > > * Distributed editing - Not just merging changes through a "master" data > owner, but using a more git-like model where the topology of the change > graph follows the usage rather than the other way around. This would > allow caches to populate from other caches but still be able to send > changes back to the original provider. > > * Rendering from local feature data cache. I guess we'd need to cache > styles as well, but it might be nice to avoid hitting a remote source > for tiles after we already have the necessary feature data. > > My imagination is failing me here but I am sure there is lots of > interesting discussion to be had on this topic. > > -- > David Winslow > OpenGeo - http://opengeo.org/ > -- Sebastian Benthall OpenGeo - http://opengeo.org
