Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 05:45:22PM +0200, Frederik Ramm wrote: I was not aware this is also a server load issue. And frankly if this is about server load then there are better ways to mitigate that like rewriting the map call as a C/C++ apache module... The map call is not involved. No, but it is probably 1000x more likely to be called than doing a changeset rollback. Hence a better target for optimization. Mm. I have a difficult time picturing the difficulty for the client. Use your imagination then. If the user requests, say, a graphical representation of the changes effected by change set X, you will not want to show the intermediate steps. So you would have to collapse the change set - something changed first and deleted later, show it only as deleted; something created at position A and moved to position B, show it as created at position B; something moved from X to Y and then from Y to Z, show it as moved from X to Z. It is trivial to do that kind of stuff on the clientside. On the contrary my hunch feeling is that rollback is going to be easier, more flexible and more robust if the changeset is not mangled but is presented as small piecewise changes. Au contraire. Rolling back a changeset requires the very same collapsing; if the changeset contained a change from X to Y to Z, then you want to rollback from Z to X and not from Z to Y to X. First of you might want to do rollback from Z to Y only because you want to keep Y to X. Or even worse, maybe there was a bug in the client that mangled only certain operations so you want to rollback only those. Or you misinterpreted something on the wiki and put in nodes at crosssections that shouldn't have them but you want to keep the other changes you did at the same time. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 06:45:01PM +0200, Frederik Ramm wrote: Out of interest, why's that a bad thing? We have several editors, for example: each of them works differently and presents information differently. Why do we have to have One True Rollback? We have enough trouble as it is with the small number of editors we have. I'm all for diversity and user choice but I'm prepared to accept limits to diversity where it seems sensible to me, and this is a point where it seems sensible. What difficulty specifically are you thinking off? cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
Hi, Use your imagination then. If the user requests, say, a graphical representation of the changes effected by change set X, you will not want to show the intermediate steps. So you would have to collapse the change set - something changed first and deleted later, show it only as deleted; something created at position A and moved to position B, show it as created at position B; something moved from X to Y and then from Y to Z, show it as moved from X to Z. It is trivial to do that kind of stuff on the clientside. Not trivial, and a benefit for all if implemented server-side. First of you might want to do rollback from Z to Y only because you want to keep Y to X. Changesets are a grouping of edits that make things easier because one only has to work with the groups - e.g. not show all individual edits, but show the group as a whole, etc. A changeset can only be rolled back as a whole. The rollback of a changeset leads to a new, inverted changeset that should be tagged in a way to express the fact that it is a rollback of changeset X. If you want to do partial rollbacks, then you don't need changesets at all - you might as well go with the already implemented restore historic version function in Potlatch. In that case you lose the changeset being rolled back - you do some changes but you don't do a rollback of a changeset. It is fully ok for clients to use the history of individual objects to return them to any state they were in at some time before, like Potlatch does, but this has nothing to do with rolling back changesets. I'm a bit tired of this. I understand that you're unhappy about not having been at the hack-a-thon but can we perhaps now proceed with the work at hand instead of making an endlessley protracted discussion about every single aspect of the new API. (The longer this goes on, the more reason there is for those that will one day do 0.7 to *not* discuss things on the lists, citing this discussion as an example that nothing good comes of it.) Rollback and the retrieval of changeset data aren't even on the critical path, they can be implemented at *any* *later* *time* without changing the API. We don't have to find a solution today. You want changesets as some universal access and documentation method for the history of everything, and I want them as closed, near-atomic changes. I'd say the person who codes it gets to decide, but as I said, it doesn't even have to be decided now. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
Dair Grant wrote: If an editor wants to monitor individual edits in order to provide coaching or feedback to users, that's best done by watching user actions as they happen and providing feedback based on that (recording that info in the DB for every action for every user is pointless, as who would ever really go back and process it?). This discussion seems to have gone a bit bizarre. The initial issue, unless I've got confused somewhere along the way, was for live[1] editors like Potlatch where a changeset covers more than just one commit. See http://lists.openstreetmap.org/pipermail/ dev/2008-May/010346.html . So saying recording that info in the DB for every action for every user isn't the issue - we already do that. Frederik wants, AIUI, the server to deliver such a changeset in just its final form, collapsing all the intermediate edits into one. (See http://lists.openstreetmap.org/pipermail/dev/2008-May/010354.html.) I disagree, largely because it seems a shame (and non-OSM) to impose a certain model on rollback clients when we don't yet know how they'll be used. There may be circumstances - some we know already, some we haven't thought of yet - where the extra information is necessary. One example that springs to mind is that splitting and joining ways are common user operations that have to be interpreted by the editor (there's no dedicated API method for either) and frequently result in editing mistakes. Having the intermediate changes visible could help a rollback client interpret these, thereby helping its user to see what mapping error occurred, if it was designed to do so. (Frederik thinks this is best catered for by using the existing history features, I think. I can see some logic in that, but there might need to be some additional API work to make the linkage between atomic history and changesets more explicit.) Bart disagrees, too, but has other reasons. Ultimately, of course, he who commits the code has the final say. cheers Richard [1] anagram of evil hmmm. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Fri, May 16, 2008 at 10:13 AM, Dair Grant [EMAIL PROTECTED] wrote: Frederik Ramm wrote: First of you might want to do rollback from Z to Y only because you want to keep Y to X. Changesets are a grouping of edits that make things easier because one only has to work with the groups - e.g. not show all individual edits, but show the group as a whole, etc. That is really the core idea of a changeset; it deals with a collection of changes as one entity. If an editor wants to be able to revert/have a check in comment for/etc individual changes, they can just commit each change in its own changeset. Looking at how this model is used elsewhere (any source control system), that'd be like committing after each keystroke/newline. I doubt that would be useful - the thing changesets bring is the ability to record why some changes were done as a whole. For most rcs systems such changes actually are atomic though, and don't allow multiple edits per changeset. We really have to support that if we're to keep Potlatch and the possibility of live editing systems, and still maintain a sensible number of useful changesets. I.e., if you look back at some old data you want to see that user X's Saturday morning contribution was added road names based on NPE map. Being able to see user changed tag X to Y, user dragged node here, user changed tag Y back to X, user changed tag X to Z is not useful; it's just information for the sake of it. If an editor wants to monitor individual edits in order to provide coaching or feedback to users, that's best done by watching user actions as they happen and providing feedback based on that (recording that info in the DB for every action for every user is pointless, as who would ever really go back and process it?). We already do store this information if they're using Potlatch. If they're using an editor with a save concept then obviously not. Is it useful? Probably not most of the time. You want changesets as some universal access and documentation method for the history of everything, and I want them as closed, near-atomic changes. +1 to the latter; changesets let us group related changes together, and document what they were for - that's the point of having them. Which comes down to how these changesets are actually being implemented in the server. I was under the impression that it was just a changeset ID column added to the node/way/relation history tables that could then be used to query what changes happened for a particular changeset. In this model we already have the detailed information, and this whole argument is over the format of a changeset query where it would be quite possible to implement it both ways, and have both available at the same time. Of course if it's intended to collapse changesets as they are created, then that's a different matter. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
Dave Stubbs wrote: this whole argument is over the format of a changeset query where it would be quite possible to implement it both ways, and have both available at the same time. That's a very good point. cheers Richard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
In message [EMAIL PROTECTED] Richard Fairhurst [EMAIL PROTECTED] wrote: Dave Stubbs wrote: this whole argument is over the format of a changeset query where it would be quite possible to implement it both ways, and have both available at the same time. That's a very good point. An even better point is that we don't even know if collapsing the edits is even practical - I imagine it would be quite an expensive thing for the server to do. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Wed, May 14, 2008 at 11:04 PM, bvh [EMAIL PROTECTED] wrote: But apparently the server code expects version, not old_version. Personally I slightly prefer version as it would then become identical code from just saving the file. Heh. We started from the same principles and ended up in a different place. When we discussed this at the hack-a-thon we figured the diff upload had more in common with the changeset download then with the map call. And in a changeset download you want to give both the old and the new version number. So, we specced out what you would need for a changeset download, invented old_version and new_version and then used old_version everywhere we needed it. If we do it your way then we would get old_version and version for the changeset download, right? This is inconsistent with section 1.5 of the wiki page on 0.6 that says the changeset_id attribute should be on the osm tag for diff upload. So it would be interesting to find out the reason for this difference. You're right. I'm pretty sure it's not what I wrote on the whiteboard, but if it says it in the wiki then we do it that way. The bit about the changeset_id in the osm tag introduces an asymmetry between what you upload and what you save to a file, so I think at least JOSM will put it in both places so you can read it back from files saved on disk. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 08:30:08AM +0200, Martijn van Oosterhout wrote: So, we specced out what you would need for a changeset download, invented old_version and new_version and then used old_version everywhere we needed it. If we do it your way then we would get old_version and version for the changeset download, right? Well, see my earlier mail on the subject. I don't think we should be sending full object definitions as a response to diff uploads. You're right. I'm pretty sure it's not what I wrote on the whiteboard, but if it says it in the wiki then we do it that way. The bit about the changeset_id in the osm tag introduces an asymmetry between what you upload and what you save to a file, so I think at least JOSM will put it in both places so you can read it back from files saved on disk. Well the changeset_id is certainly bogus when you save it to disk no? What would you put in it? Scenario : I am somewhere in the woods with JOSM/merkaartor on a laptop charting new territory without internet. Now I want to save my work to a file so I can later upload it. What would we save in the changeset_id? cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 7:28 AM, bvh [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 08:30:08AM +0200, Martijn van Oosterhout wrote: So, we specced out what you would need for a changeset download, invented old_version and new_version and then used old_version everywhere we needed it. If we do it your way then we would get old_version and version for the changeset download, right? Well, see my earlier mail on the subject. I don't think we should be sending full object definitions as a response to diff uploads. I'm not talking abot diff upload responses, I'm talking about changeset downloads. Say I note that object 123 was modified in changeset 456 six weeks ago. And I go to the API and say: show me everything done in changeset 456. You're right, the response to an upload doesn't need it. Well the changeset_id is certainly bogus when you save it to disk no? What would you put in it? Scenario : I am somewhere in the woods with JOSM/merkaartor on a laptop charting new territory without internet. Now I want to save my work to a file so I can later upload it. What would we save in the changeset_id? Leave it out, obviously. Say I do a map call for an area, currently you get for example the user_id, soon you will get the changeset ID. So in JOSM if you see a way changed, you will be able to ask which other things were changed at the same time?. This information should be saved if I save the data to disk and load it up later. It isn't necessary for uploading though. If you download an area in general every object will have a different changeset id so you can't stick it in the header... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 09:10:42AM +0200, Martijn van Oosterhout wrote: I'm not talking abot diff upload responses, I'm talking about changeset downloads. Say I note that object 123 was modified in changeset 456 six weeks ago. And I go to the API and say: show me everything done in changeset 456. You're right, the response to an upload doesn't need it. But isn't old_version+1 always equal to version? Leave it out, obviously. Say I do a map call for an area, currently you get for example the user_id, soon you will get the changeset ID. So in JOSM if you see a way changed, you will be able to ask which other things were changed at the same time?. Ha, I wasn't aware this is going to be done. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
In message [EMAIL PROTECTED] bvh [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 09:10:42AM +0200, Martijn van Oosterhout wrote: I'm not talking abot diff upload responses, I'm talking about changeset downloads. Say I note that object 123 was modified in changeset 456 six weeks ago. And I go to the API and say: show me everything done in changeset 456. You're right, the response to an upload doesn't need it. But isn't old_version+1 always equal to version? Under the current plan, yes. We didn't think it was reasonable to push that assumption down to the clients thought. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 09:02:04AM +0100, Tom Hughes wrote: But isn't old_version+1 always equal to version? Under the current plan, yes. We didn't think it was reasonable to push that assumption down to the clients thought. Why would that be unreasonable? In what (futuristic) scenario would version numbers not increment monotonically one by one? cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
Hi, But isn't old_version+1 always equal to version? Under the current plan, yes. We didn't think it was reasonable to push that assumption down to the clients thought. Why would that be unreasonable? In what (futuristic) scenario would version numbers not increment monotonically one by one? In the current scenario, you are basically not allowed to upload a new version of an object if you haven't got the previous version. This is unnecessarily strict. For example, two people could download version 1 of a node; one adds the foo tag, another adds the bar tag, both upload. With the plans for API 0.6, one of the uploads will simply fail. In theory, both uploads could be accepted without conflict, and we would then have one change that goes from v1 to v2, and one change that goes from v1 to v3. It is also possible to change the same object multiple times within the same changeset, so one single changeset might catapult the object version from 1 to 15. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 12:50:39PM +0200, Frederik Ramm wrote: An online editor like Potlatch will open a changeset and then let the user do whatever he wants, including changing an object again and again and again; since edits are not buffered by the editor but rather uploaded whenever they happen, it is inevitable to have multiple changes to the same object within the same changeset. Sorry, I was confusing 'changeset' and 'diff'. A single changeset can change an object from version 1-15, but in that case, each of the changes within that changeset should still be laid out in the changeset response, right? so one would be the change from 1-2, 2-3, ... 14-15? Or not? Regards, -- Christopher Schmidt MetaCarta ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 07:28:29AM +0200, bvh wrote: On Thu, May 15, 2008 at 08:30:08AM +0200, Martijn van Oosterhout wrote: So, we specced out what you would need for a changeset download, invented old_version and new_version and then used old_version everywhere we needed it. If we do it your way then we would get old_version and version for the changeset download, right? Well, see my earlier mail on the subject. I don't think we should be sending full object definitions as a response to diff uploads. This isn't about diff uploads, it's about downloading the full contents of changed data in a changeset. Regards, -- Christopher Schmidt MetaCarta ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 08:30:08AM +0200, Martijn van Oosterhout wrote: On Wed, May 14, 2008 at 11:04 PM, bvh [EMAIL PROTECTED] wrote: But apparently the server code expects version, not old_version. Personally I slightly prefer version as it would then become identical code from just saving the file. Heh. We started from the same principles and ended up in a different place. When we discussed this at the hack-a-thon we figured the diff upload had more in common with the changeset download then with the map call. And in a changeset download you want to give both the old and the new version number. So, we specced out what you would need for a changeset download, invented old_version and new_version and then used old_version everywhere we needed it. If we do it your way then we would get old_version and version for the changeset download, right? Okay, I didn't see a specced out version of changset download, and didn't factor that into my decision. However, 'version' and 'old_version' still makes sense to me, even in that case. This is inconsistent with section 1.5 of the wiki page on 0.6 that says the changeset_id attribute should be on the osm tag for diff upload. So it would be interesting to find out the reason for this difference. You're right. I'm pretty sure it's not what I wrote on the whiteboard, but if it says it in the wiki then we do it that way. The bit about the changeset_id in the osm tag introduces an asymmetry between what you upload and what you save to a file, How so? Why would you save the changeset of an individual object to a file? Regards, -- Christopher Schmidt MetaCarta ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 11:46 AM, Christopher Schmidt [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote: It is also possible to change the same object multiple times within the same changeset, so one single changeset might catapult the object version from 1 to 15. Is that a design goal? That behavior seems unexpected to me. It's a goal to let it happen, think Potlatch style live editing. It's also possible for another changeset to edit the object in between as well, so this probably shouldn't be as transparent as catapult might suggest. The changeset data download will have to take this into account. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
Hi, It is also possible to change the same object multiple times within the same changeset, so one single changeset might catapult the object version from 1 to 15. Is that a design goal? That behavior seems unexpected to me. An online editor like Potlatch will open a changeset and then let the user do whatever he wants, including changing an object again and again and again; since edits are not buffered by the editor but rather uploaded whenever they happen, it is inevitable to have multiple changes to the same object within the same changeset. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 06:40:41AM -0400, Christopher Schmidt wrote: How so? Why would you save the changeset of an individual object to a file? (read entire thread, then respond, Chris: Responding in order is silly.) -- Christopher Schmidt MetaCarta ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote: Under the current plan, yes. We didn't think it was reasonable to push that assumption down to the clients thought. Why would that be unreasonable? In what (futuristic) scenario would version numbers not increment monotonically one by one? In the current scenario, you are basically not allowed to upload a new version of an object if you haven't got the previous version. This is unnecessarily strict. For example, two people could download version 1 of a node; one adds the foo tag, another adds the bar tag, both upload. With the plans for API 0.6, one of the uploads will simply fail. In theory, both uploads could be accepted without conflict, and we would then have one change that goes from v1 to v2, and one change that goes from v1 to v3. But one of them will be accepted first and the other will later be judged as sufficiently different, right? So the actually history in the database will have two transitions, one from v1 to v2 and the other from v2 to v3. It is also possible to change the same object multiple times within the same changeset, so one single changeset might catapult the object version from 1 to 15. Wouldn't it be better then to just throw away consecutive changes to the same object and only keep the last one within each diff? cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 12:02:39PM +0100, Dave Stubbs wrote: On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote: It is also possible to change the same object multiple times within the same changeset, so one single changeset might catapult the object version from 1 to 15. Is that a design goal? That behavior seems unexpected to me. It's a goal to let it happen, think Potlatch style live editing. Sure but in such a changeset there would be multiple occurences of modify... for the same object, each incrementing the version number by 1. It's also possible for another changeset to edit the object in between as well, so this probably shouldn't be as transparent as catapult might suggest. The changeset data download will have to take this into account. You will then have things like osmChange modify node id=x version=3.../ node id=x version=4.../ node id=x version=7.../ /osmChange So now the first change incremented the version from 2 to 3, second from 3 to 4 and the last one from 6 to 7. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 11:42:03AM +0200, bvh wrote: On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote: Under the current plan, yes. We didn't think it was reasonable to push that assumption down to the clients thought. Why would that be unreasonable? In what (futuristic) scenario would version numbers not increment monotonically one by one? In the current scenario, you are basically not allowed to upload a new version of an object if you haven't got the previous version. This is unnecessarily strict. For example, two people could download version 1 of a node; one adds the foo tag, another adds the bar tag, both upload. With the plans for API 0.6, one of the uploads will simply fail. In theory, both uploads could be accepted without conflict, and we would then have one change that goes from v1 to v2, and one change that goes from v1 to v3. But one of them will be accepted first and the other will later be judged as sufficiently different, right? So the actually history in the database will have two transitions, one from v1 to v2 and the other from v2 to v3. Yes, but the client uploaded version=1, and the server handed back version=3. The client couldn't assume that current_version + 1 - new_version. It is also possible to change the same object multiple times within the same changeset, so one single changeset might catapult the object version from 1 to 15. Wouldn't it be better then to just throw away consecutive changes to the same object and only keep the last one within each diff? This is about changeset serialization, not diffs. (I made the same mistake.) Regards, -- Christopher Schmidt MetaCarta ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 07:18:30AM -0400, Christopher Schmidt wrote: But one of them will be accepted first and the other will later be judged as sufficiently different, right? So the actually history in the database will have two transitions, one from v1 to v2 and the other from v2 to v3. Yes, but the client uploaded version=1, and the server handed back version=3. The client couldn't assume that current_version + 1 - new_version. That is ok. The server only needs to send you the new version, you already have the old one. So again no need to have two different versions in your response. It is also possible to change the same object multiple times within the same changeset, so one single changeset might catapult the object version from 1 to 15. Wouldn't it be better then to just throw away consecutive changes to the same object and only keep the last one within each diff? This is about changeset serialization, not diffs. (I made the same mistake.) See my other email regarding changeset serialization. (But you also came to the same conclusion I think) cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
Hi, A single changeset can change an object from version 1-15, but in that case, each of the changes within that changeset should still be laid out in the changeset response, right? so one would be the change from 1- 2, 2-3, ... 14-15? Or not? Don't know. The most usable type of response for the user would certainly be: As a result of this changeset, Object X was changed from state A to state B. As a user, I am not interested in the 318 intermediate editing steps; I want to know the before and after versions of the object. So if someone requests a list of all changes for one changeset, my suggestion would be to return: * exactly two versions of each object changed in that changeset (before and after) * only the before version for deleted objects * only the after version for created objects If an object is created and deleted within the same change set, do not return anything at all. The one thing I am unsure about is whether this can be coded efficiently ;-) basically you have to retrieve the highest and smallest version number of each object linked to this changeset and then return the object with the highest version and the object with the version smallest-1. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
Hi, I think it is the client who should filter what to present to the user. The response of the database should be as complete as possible, including sending intermediate states. I disagree. If you wanted raw access, then you can have it - just download the history of every object. You can do that even now. Changesets are introduced to lessen the complexity. We want one big edit, ideally associated with a comment where the user says what he meant to achieve with this edit. The very reason for having changesets is to do some grouping and filtering on the server side, instead of having to let the client do everything (and incur a lot of server load and traffic along the way). Once a changeset is complete, we should view it as atomic (even if it was created in an atomic fashion). Changeset No 1234 changed object A from state X to state Y - that's what a changeset should represent. And not: During changeset 123, the user first idled for 10 minutes, then moved node A a bit further north, five minutes later moved it back south, then decided to add a tag; subsequently deleted the whole node and repeated the procedure with a new one This is completely unnecessary and only confusing for any clients who want to work with the changeset data. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 01:26:56PM +0200, Frederik Ramm wrote: The most usable type of response for the user would certainly be: As a result of this changeset, Object X was changed from state A to state B. As a user, I am not interested in the 318 intermediate editing steps; I want to know the before and after versions of the object. For a user this is a moot point, he or she is never going to interact using version numbers directly. The client should present him/her the _state_ of the object. So if someone requests a list of all changes for one changeset, my suggestion would be to return: * exactly two versions of each object changed in that changeset (before and after) * only the before version for deleted objects * only the after version for created objects If an object is created and deleted within the same change set, do not return anything at all. I think it is the client who should filter what to present to the user. The response of the database should be as complete as possible, including sending intermediate states. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On 15 May 2008, at 11:30, bvh wrote: [...] I think it is the client who should filter what to present to the user. The response of the database should be as complete as possible, including sending intermediate states. There may be cases, such as wanting to visualise the data changes, or where the user has reverted their good change (in the same change set) and wants it back (only realising some time after quiting the editor). Hence why you should send all changes back. It could always be made optional, as to whether the intermediate changes are returned. Shaun ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
On Thu, May 15, 2008 at 02:20:42PM +0200, Frederik Ramm wrote: If you wanted raw access, then you can have it - just download the history of every object. You can do that even now. Changesets are introduced to lessen the complexity. We want one big edit, ideally associated with a comment where the user says what he meant to achieve with this edit. The very reason for having changesets is to do some grouping and filtering on the server side, instead of having to let the client do everything (and incur a lot of server load and traffic along the way). I thought the reason for changesets was to have some grouping so we could do rollback. I was not aware this is also a server load issue. And frankly if this is about server load then there are better ways to mitigate that like rewriting the map call as a C/C++ apache module... And not: During changeset 123, the user first idled for 10 minutes, then moved node A a bit further north, five minutes later moved it back south, then decided to add a tag; subsequently deleted the whole node and repeated the procedure with a new one This is completely unnecessary and only confusing for any clients who want to work with the changeset data. Mm. I have a difficult time picturing the difficulty for the client. On the contrary my hunch feeling is that rollback is going to be easier, more flexible and more robust if the changeset is not mangled but is presented as small piecewise changes. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
Frederik Ramm wrote: We could do rollback even now without any grouping (We do!) [...] This collapsing would have to be implemented in every piece of software that deals with changesets, and my hunch is that everybody would implement it slightly differently. Out of interest, why's that a bad thing? We have several editors, for example: each of them works differently and presents information differently. Why do we have to have One True Rollback? I can foresee ways in which different collapsing methods could be of benefit - for example, one rollback tool might want to visualise (via animation) consecutive edits within a particular changeset to see what the user was doing. cheers Richard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
Hi, Out of interest, why's that a bad thing? We have several editors, for example: each of them works differently and presents information differently. Why do we have to have One True Rollback? We have enough trouble as it is with the small number of editors we have. I'm all for diversity and user choice but I'm prepared to accept limits to diversity where it seems sensible to me, and this is a point where it seems sensible. I can foresee ways in which different collapsing methods could be of benefit - for example, one rollback tool might want to visualise (via animation) consecutive edits within a particular changeset to see what the user was doing. That's none of your business what I was doing ;-) oh look, that must have been one of Fred's drunken edit sessions, let's watch that animation again... If you are really interested in that kind of detail, load individual object histories or the minutely change files. A changeset, to me, should be like an SVN commit: I check stuff out, then I make umpteen edits using my favourite editor, then I check stuff in with a commit message. A changeset is *not* intended to be a video recording of what happened on the user's desktop between point A and point B. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederik Ramm schrieb: Hi, If you are really interested in that kind of detail, load individual object histories or the minutely change files. A changeset, to me, should be like an SVN commit: I check stuff out, then I make umpteen edits using my favourite editor, then I check stuff in with a commit message. A changeset is *not* intended to be a video recording of what happened on the user's desktop between point A and point B. should it be as SVN in the way that the moment I touch an object in an open changeset, it is locked, so my changeset can be committed as an atom? Or seen from the other side, how do you rollback meshed changesets? for example User A creates node 1, version 1, then B edits the tags (-version 2), then User A moves it, and changes some tags (- version 3) then both close their changesets. - -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILGpWFUbODdpRVDwRAtooAJ9seuA98x7faxrvrsmqPRLTFCbbDQCfRHHu O4/tmP5tBgFggMwSuSZiXtM= =A9cV -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
Hi, should it be as SVN in the way that the moment I touch an object in an open changeset, it is locked, so my changeset can be committed as an atom? Would be nice to have but totally unusable because everything would be constantly locked. Or seen from the other side, how do you rollback meshed changesets? A difficult question (but unrelated to the discussion whether or not to include details when retrieving a changeset). It doesn't have to be a meshed changeset - even if you have a situation where A vandalises the database and B makes one or two manual changes afterwards, then the changeset created by A cannot be reverted in its entirety because first B's changes would have to be reverted... My initial proposal had support for changeset reverts in the API. At the hack-a-thon we decided not to implement this *at this time*, instead just pass the info to clients (there might be special rollback clients - it doesn't have to be the editors!) and let them decide what to do. This doesn't mean that there will not be any rollback support in a future API, but on the whole, rollback is probably a complex thing that will often require user interaction (rolling back changeset X will also destroy some more recent edits done by user Z, are you sure... etc). Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
2008/5/15 Dirk-Lüder Kreie [EMAIL PROTECTED]: should it be as SVN in the way that the moment I touch an object in an open changeset, it is locked, so my changeset can be committed as an atom? Or seen from the other side, how do you rollback meshed changesets? for example User A creates node 1, version 1, then B edits the tags (-version 2), then User A moves it, and changes some tags (- version 3) then both close their changesets. Changesets are not atomic, so you'll have to get multiple versions if multiple people editted the same object at the same time... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] 0.6 API clarifications and corrections
Now who is unilaterally making decisions? :) Sorry the wiki wasn't clear enough. On Wed, May 14, 2008 at 7:52 PM, bvh [EMAIL PROTECTED] wrote: - When updating or deleting an object, the wiki says you need to include an attribute old_version with the version on which you base the changes (opportunistic locking). The server however looks for a tag named version and not old_version. I shall change the wiki to reflect this. It's supposed to be old_version and that what JOSM implements but I'm fine either way. The reasoning being that it's clearly not the version being uploaded and in some contexts (diff output) you might want old_version and new_version. - When creating, updating or deleting a single object the wiki says that you need to add the changeset and old_version attributes but does not state on which tag. crschmidt and me agreed on IRC that * the changeset attribute should be on the osm tag * the version attribute should be on the object tag At the hackathon we had quite a bit of discussion about this and we decided they should both go on the object tag (the reason escapes me right now, I'm sure it will come to me. something to do with being consistant with how the data will be retreived). This is also what JOSM implements. But I'm fine either way... Just as long as we end up with one way of doing it and not lots of variations. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
