[OSM-dev] [OSM-talk] Trouble in Rangoon
frederik at remote.org
Thu Feb 28 13:44:06 GMT 2008
> Why to you suppose the editor give a changeset-api?
> What about threating every upload as a new changeset
> and make it transparent to the client?
> This way all clients still work and they can implement
> support for "get_history", "revert_changeset" and "get_changeset"
> at any later time.
Usually if you want to revert things, you will want to revert a group
of edits. Instead of trying to create the group at the undo stage
("everything done by user X in time frame Y applying to area Z..."),
which I consider difficult and which would require extra API calls as
well, I want to create groups of edits while editing. This will also
have the beneficial effect of users being able to document their work
(i.e. you open JOSM, fix a complex junction, then upload your changes
with the comment "junction X fixed", and anyone tracking an area does
not see "user X changed 5 nodes, deleted 3 nodes, inserted 7 nodes,
and changed 5 ways" but you see "user X: junction X fixed", which is
Of course someone bent on hard vandalism could always write a script
to make 1 million individual changeset that each move one of London's
nodes, in which case we would have to think about reverting a group
of changesets at once.
The only thing I'd ask of editors is to support "create_changeset"
and then use the ID returned on subsequent edits. This, I believe, is
a small price to pay for the grouping advantages we would get.
Automatically creating one changeset for every single change would be
an option for a changeover time but not really desirable.
> For a revert I strungly suggest the revert be a conventional
> changeset with delete+create+modify -operations.
Yes, that was my thought as well.
> I also strongly
> suggest not to disallow dirty reverts completely, because then
> moving a single node after all of london is "misplaced" can break
> the revert of that edit.
Yes, some sort of "force" operation will probably be required.
Frederik Ramm ## eMail frederik at remote.org ## N49°00.09' E008°23.33'
More information about the dev