[OSM-talk] Blue sky API: Branching function

Brendan Morley morb.gis at beagle.com.au
Sat Oct 9 02:23:56 BST 2010


Hi all,

Firstly, put this in the "blue sky dreaming" bucket.  But I am 
interested in the latent demand out there.

Some of us will be familiar with subversion or git, which are source 
code version control systems.

We also know that OSM API v0.6 contains some Changeset semantics.

However, I don't think v0.6 has the concept of branching?  And 
http://wiki.openstreetmap.org/wiki/API_v0.7 doesn't mention it either?

I'd like to introduce the concept of branches in the OSM API.  Branches 
in the OSM API would be similar to branches in a more traditional VCS.  
You would use them to stage a set of changes that you hope to have 
eventually merged into the main map.

Now, consider these use-cases - somewhat contrived but not by much:

1. Several importable datasets can cover a particular region - e.g. a 
national dataset at low level of detail and a provincial dataset at a 
high level of detail.  Both are compatible with the licence of the day 
(CC BY or CC BY-SA, etc).  And we want to convert and present them to 
our userbase in the form they've come to know and love.

Right now, we can only feasibly pick one or the other.  To pick both 
would mean the major Ways would have a doubled-up representation.  An 
alternative is to go through the 2 datasets and manually merge them 
before uploading to the API.

If a concept of "branching" occurred, we could run a "trunk"/"master" 
(similar in concept to what we have today) and then 2 additional 
branches, e.g. "ca-gov" and "ca-gov-provincial".  Load them all up and 
then merge the branches into the trunk at a more leisurely pace.  Get 
your friends to help out.

The "gov" branches could also be a staging point for community changes 
to be accepted back into government repositories.


2. For "what-if" scenarios.  For example, to illustrate a proposal for a 
new motorway or something.  I suppose this could be extended to complete 
fantasy scenarios (though if this were the case I would discourage 
hosting them on the main OSM website).


Any plan would be to firstly achieve svn-like functionality and 
stabilise it; then secondly to try on a full DVCS scenario, like git, in 
an additional release (which would make the fantasy mappers happy).

I think we could introduce it in a way that doesn't break 0.6 XML 
parsers.  You might introduce a new XML attribute in Changesets, such as 
"branch name" or "parent" (I'm not sure how git does it).  Anything 
lacking the new tag would continue to be assumed as a implicit 
trunk/mainline change.

The API database schema itself would also have to be mutated.  I haven't 
yet worked out if this is trivial, either in the schema itself or its 
likely performance impacts.

There is an implied semantic being broken that I can think of: You could 
no longer assume that the change history is ordered by ID or timestamp.


Thoughts?


Brendan

ref: http://book.git-scm.com/1_the_git_object_model.html




More information about the talk mailing list