[OSM-talk] Blue sky API: Branching function

Peter Wendorff wendorff at uni-paderborn.de
Sat Oct 9 09:51:36 BST 2010


  Hi.
I'm not sure whether the branching function could work.
While the idea sounds great in the first moment, there are a lot of 
problems coming with it:
1) imports:
You will be able to prepare imports collaboratively outside the osm 
database, that's true; but merging would be the same problem as without 
branches.
Without branches you have to merge more or less starting with your first 
part of the import: check every object for existance and the need to 
merge them.
With branches you would prepare your import to ready-to-include objects 
- and you have to merge afterwards.
I don't see a substantial benefit here (as far as I imagine this feature).

2) what if...
People don't want to include data of outdated facts (abandoned highways 
where other highways are now build over, abandoned buildings etc.), and 
the main reason I think for people to oppose including that data (while 
I think it would be really worth including it - if editors and api could 
handle it).
For this kind I think it should be possible to easily set up a kind of 
"branch mirror" of OSM: database, api and perhaps mapnik renderer out of 
the box to play with using a small subset of data (say: one country or 
region covering the import or the "what if" alternatives).

regards
Peter
On 09.10.2010 03:23, Brendan Morley wrote:
> 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
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>




More information about the talk mailing list