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