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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
