[OSM-talk] Potlatch :-)

[D Tucny]

On 22/11/2007, Gerald A <geraldablists at gmail.com> wrote:
>
> Hi Richard,
>
> On 11/22/07, Richard Fairhurst <richard at systemed.net> wrote:
> > Sorry, but I'm getting fed up with this.
> >
> > > 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?


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...

While I agree that OSM needs a nice way to do revert/undo/restore, I too am
> tired of hearing how it's all the fault of Potlatch. An editor can be
> as or more distructive
> in JOSM, or any other tool for that matter. Potlatch just takes the
> heat because it's
> easier or even because it's the first tool people use. This speaks to
> it's popularity, not
> it's broken-ness.


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...

> As it says in the original mail, the functionality was temporarily
> > disabled on the main OSM server in the hope of some peer review:
> > "because this is new ground for OSM, I'd appreciate it if people could
> > test it on their local installs".
> >
> > How many whingers like you have taken five minutes to test it and mail
> > me your results? Answer: 0. That is the sole, the only reason why
> > there is no undo yet. And I don't see you committing any undo feature
> > to the standard API or your beloved JOSM.
>
> I read with great anticipation this change, but I'm still a mountain's
> climb away
> from knowing how to get a working OSM replica going, forget even knowing
> what
> Potlatch is coded in (Flash/Actionscript?). I'm willing to help, but
> it'll take some time until I would be in a position to test,


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 ;)


unfortunately. And while I think this feature would greatly help _me_
> if I make a mistake, I'm not sure it would help stem the flow of these
> e-mails.


 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...

While "undo" is a fabulous idea, and helps an editor that knows what
> they are doing, for someone that doesn't yet know, or care, how things
> look on the map, how does it help? There will still be cries of
> "disable that busted Potlatch, some idiot user deleted half my work".
> The only way to solve that is to build true undo into the API itself,
> to allow us to choose versions of the data.


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...


d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20071123/865706dc/attachment.html>