2011/6/25 Frederik Ramm frede...@remote.org:
If you're editing in a place where you have reason to believe that you're
not the only one, uploading often isn't too bad a habit - reduces the
likelihood of conflicts!
Yes, but is there a point of doing this within the same changeset?
Cheers,
Am 26.06.2011 13:53, schrieb M∡rtin Koppenhoefer:
2011/6/25 Frederik Ramm frede...@remote.org:
If you're editing in a place where you have reason to believe that you're
not the only one, uploading often isn't too bad a habit - reduces the
likelihood of conflicts!
Yes, but is there a point
M∡rtin Koppenhoefer wrote:
Yes, but is there a point of doing this within the same changeset?
Yes, of course there is. If you're using an online editor you should save
early and save often. When the user chooses to start/finish a changeset has
no bearing on that.
cheers
Richard
--
View this
Richard Fairhurst wrote:
M∡rtin Koppenhoefer wrote:
Yes, but is there a point of doing this within the same changeset?
Yes, of course there is. If you're using an online editor you should save
early and save often. When the user chooses to start/finish a changeset has
no bearing on that.
Tobias Knerr writes:
The problem is that saving and committing are, in this case, the
same action. While it's of course desirable to commit somewhat
frequently (to avoid conflicts), it's not desirable to commit your
unfinished in-progress edits every few seconds.
I'm somewhat paranoid
On Sun, Jun 26, 2011 at 11:22 AM, Tobias Knerr o...@tobias-knerr.de wrote:
Richard Fairhurst wrote:
M∡rtin Koppenhoefer wrote:
Yes, but is there a point of doing this within the same changeset?
Yes, of course there is. If you're using an online editor you should save
early and save often.
On 26 Jun 2011, at 18:10, Serge Wroclawski wrote:
On Sun, Jun 26, 2011 at 11:22 AM, Tobias Knerr o...@tobias-knerr.de wrote:
Richard Fairhurst wrote:
M∡rtin Koppenhoefer wrote:
Yes, but is there a point of doing this within the same changeset?
Yes, of course there is. If you're using an
On Sun, Jun 26, 2011 at 2:01 PM, Shaun McDonald
sh...@shaunmcdonald.me.uk wrote:
If you use the diff uploads, then it is already the case that a changeset
could be called a collection of transactions, though the transaction id is
never exposed or stored. (Technically the transaction ids and
On 26/06/11 19:52, Serge Wroclawski wrote:
Another benefit of that would be the ability to have asynchronous
transactions, which could lead to a better editing experience.
An API call could happen quickly, the client could be given a
transaction ID and then optionally not need to wait for the
Hi,
Tobias Knerr wrote:
I've just spotted several changesets where a large number of versions of
the same node were created within a single changeset, e.g.:
http://www.openstreetmap.org/browse/changeset/8542345
Should that even be possible?
Sure, most editors allow you to keep a changeset
If the user is saving their changes on a regular basis, then yes I would expect
the same item to be in the changeset multiple times.
In this case it looks as though the user has been moving the bus stop and then
hitting the save button multiple times. (Potlatch2 will not automatically save
and
Frederik Ramm wrote:
Tobias Knerr wrote:
I've just spotted several changesets where a large number of versions of
the same node were created within a single changeset, e.g.:
http://www.openstreetmap.org/browse/changeset/8542345
Should that even be possible?
Sure, most editors allow you
Shaun McDonald wrote:
In this case it looks as though the user has been moving the bus stop and
then hitting the save button multiple times. (Potlatch2 will not
automatically save and requires the user to choose when to save).
I suspect he was seeing if and how it renders. Naughty :)
--
fun?
Maybe each node had its own license ?
/fun?
gert
-Oorspronkelijk bericht-
Van: Nathan Edgars II [mailto:nerou...@gmail.com]
Verzonden: zaterdag 25 juni 2011 20:18
Aan: talk@openstreetmap.org
Onderwerp: Re: [OSM-talk] Multiple versions of same node in changeset
Shaun McDonald
Hi,
Tobias Knerr wrote:
I optimistically assumed that the modifications are merged when the
changeset is closed, thus creating a changeset indistinguishable from
one that was created in one go.
That would only be possible if the API were to somehow have a
transaction for open changesets with
15 matches
Mail list logo