On 22/11/2007, <b class="gmail_sendername">Gerald A</b> <<a href="mailto:geraldablists@gmail.com">geraldablists@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi Richard,<br><br>On 11/22/07, Richard Fairhurst <<a href="mailto:richard@systemed.net">richard@systemed.net</a>> wrote:<br>> Sorry, but I'm getting fed up with this.<br>><br>> > A Potlatch-User now has half Rosenau  (Nuremberg) disposed :-( As

> > long as the tool does not work, you should be Off. On this same vein, maybe "rm" should be removed from Unix, because there is a possibility for widespread data loss if you add "-rf /" as an option?

</blockquote><div><br>I don't think that's a good comparison, rm is the tool that people who know what they are doing can use, especially if running it with root privs... the gui equivalent, more useful to the less experienced user, in most UIs go through the steps of asking you if you are really sure before moving it somewhere safe incase you do change your mind... 

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">While I agree that OSM needs a nice way to do revert/undo/restore, I too am<br>

tired of hearing how it's all the fault of Potlatch. An editor can be<br>as or more distructive<br>in JOSM, or any other tool for that matter. Potlatch just takes the<br>heat because it's<br>easier or even because it's the first tool people use. This speaks to

it's popularity, not it's broken-ness.</blockquote><div> When I first started contributing to OSM it took a while to work out that the GPS traces were just a background image effectively and that what I needed to do was first go along them drawing dots (nodes) manually, then go through joining the dots (segments) manually, before being able to then go through and join all the segments into ways at which point I could actually add descriptive information at each point while having to work out the somewhat strange behaviour of the various modes and functions compared to most other tools I'd used in the past (not geo related)... Potlatch provides a much simpler first step, and it and Richard can only be commended for the massive difference it has made... It's not perfect, I don't think even Richard would claim that, but it is under active development and things do keep improving... It doesn't seem to be the day to day tool for me for a number of reasons, including, the 'live' editing model is hopelessly slow and prone to failure with poor internet connectivity, I have poor internet connectivity, where I am, there's nothing better, it's hard enough with an offline editor when it takes 10 attempts to download data and 100s of upload restarts every time the editor encounters a small error, that's an something in JOSM that is a problem and would definitely be good to get improved, but, in live editing, it becomes unworkable... Also, my personal taste is to be able to fully control what the software is doing, potlatch hides things to make it simpler for new users, I prefer to not have things hidden, that's personal preference though... So, as it stands right now, I'm not using potlatch much, I've offered to test it where possible, especially on things relating to use over poor internet connections, but, I don't expect it to be the main tool I use...

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> As it says in the original mail, the functionality was temporarily<br>> disabled on the main OSM server in the hope of some peer review:

<br>> "because this is new ground for OSM, I'd appreciate it if people could<br>> test it on their local installs".<br>><br>> How many whingers like you have taken five minutes to test it and mail

<br>> me your results? Answer: 0. That is the sole, the only reason why<br>> there is no undo yet. And I don't see you committing any undo feature<br>> to the standard API or your beloved JOSM.<br><br>I read with great anticipation this change, but I'm still a mountain's

<br>climb away<br>from knowing how to get a working OSM replica going, forget even knowing what<br>Potlatch is coded in (Flash/Actionscript?). I'm willing to help, but<br>it'll take some time until I would be in a position to test,

</blockquote><div><br>I'm in the same boat, I have no local install, I would be willing to test it, but, it would be considerably more than 5 minutes of effort to get a test environment set up... Another worry is that if it worked well locally, I'd get more annoyed with my poor connectivity if I wanted to try to use it in production ;)

<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">unfortunately. And while I think this feature would greatly help _me_<br>if I make a mistake, I'm not sure it would help stem the flow of these

<br>e-mails.</blockquote><div><br> I do wonder how long it will be before we get the first 'please disable this feature, user b just undid all my changes :(' email...<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

While "undo" is a fabulous idea, and helps an editor that knows what<br>they are doing, for someone that doesn't yet know, or care, how things<br>look on the map, how does it help? There will still be cries of

<br>"disable that busted Potlatch, some idiot user deleted half my work".<br>The only way to solve that is to build true undo into the API itself,<br>to allow us to choose versions of the data.</blockquote><div>

<br>The whole concept of undo with OSM and how to implement it in a usable way is enough to make your head spin... I guess relating it to wikipedia, it would be like having a page that was actually constructed of 10s of thousands of bits of content, each with their own individual history and all linked together in different ways, potentially say having each character of a page as an individual entity... The use of transactions that's been discussed lots in the past as a way of bundling edits together and being able to revert transactions would seem like a good approach, but even that has it's drawbacks, 

e.g. damn, that last edit removed that street that I didn't want to do, revert, damn, that revert removed the 15 other streets I'd added... The whole things seems like a minefield, but one that really needs to be crossed... So, I'm really keen to see how Richard has done done it... I want to have a go with it... I have low, I'd hope realistic, expectations for this first implementation of revert function, not in any way reflecting on Richard's skill or abilities, but just due to massive difficulty that this problem presents, but, I think that having anything there will provide a great benefit and give something that can be built on as well as giving something that can mimicked in other tools... 

<br></div><br><br>d</div>