[Talk-de] Potlatch (Re: Multi-User "randale" ( s?dlich Reutlingen/T?bingen ))

Mo Jun 9 15:05:55 UTC 2008

On Sun, 8 Jun 2008 21:52:27 +0100
Richard Fairhurst <richard at systemeD.net> wrote:

> 
> Andre Rechelt wrote:
> 
> > Ich frage mich ganz einfach, was sich die Entwickler von Potlach  
> > heraus nehmen, um im Gegensatz zu ALLEN ANDEREN direkt in der  
> > Datenbank herumzupfuschen und nicht den Weg ?ber die API gehen.
> 
> Potlatch does not have, as you have put it elsewhere, a "direct  
> tunnel to the data". This just isn't true.
> 
> Potlatch (the application) uses an API, just as JOSM does, which  
> sanitises requests, requires authentication, etc. There are three  
> significant differences between that part of the API used by  
> Potlatch, and that part of the API used by JOSM etc.
> 
> - Potlatch uses a different encoding (AMF rather than XML). This is  
> simply for the sake of efficiency: older (Actionscript 1)/free  
> (Gnash) Flash players work much better with AMF than with XML.  
> Encoding, of course, makes no difference to the data.
> 
> - Some of Potlatch's calls are constructed differently. Some of this  
> is for historical reasons - you might be too new to realise this,
> but in earlier versions of the API, we had three object types: ways  
> (comprising a chain of segments), segments (connecting two nodes),  
> and nodes. Potlatch (which has always had broadly the same UI)  
> abstracted segments away from the user. Therefore the API functions  
> provided _at_the_time_ were not particularly suitable.
> 
> Since then, the rest of the API has in fact moved closer to Potlatch  
> through the abolition of segments (Frederik and Gabriel's work,  
> thanks :) ). I believe that there is some will to provide the rest
> of the API with the remaining Potlatch-only functionality (in  
> particular, a PUT /way/<id>/full method).
> 
> Bear in mind too that, at present, the design of the main API calls  
> are better suited to an offline editor (like JOSM) than an online
> one (like Potlatch). In particular, the /map call pulls down the
> entire contents of the bounding box every single time. This would
> mean that, every time the user panned the map in Potlatch, all the
> ways and nodes would be sent again - even if the user had only panned
> left by 10% of the screen area. Instead, Potlatch takes an approach
> which does not require already-loaded ways to be resent, with
> significant benefits for bandwidth and server load.
> 
> - A significant proportion of the code in amf_controller.rb uses SQL  
> rather than Rails objects. Except in some cases where SQL provides a  
> significant speed advantage, this is generally accepted as a defect.  
> It's only the case because I don't speak Rails. If you want to do  
> something constructive, fixing this would be the single best place
> to start, and would be enormously welcomed by many people including  
> myself. Please take it forward to the dev list if so - you'll find  
> lots of people willing to help you!
> 
> 
> 
> While I'm here I might as well say something about the lack of a
> Save button.
> 
> I'm not violently against the concept: I think "unconvinced" is  
> perhaps the best way to describe my opinion.
> 
> There are two big issues with it. One is that for edit sessions  
> lasting more than a couple of seconds, there has to be conflict  
> management. If you're a JOSM user, then you are de facto a
> clued-up, computer-savvy type, so conflict management doesn't worry
> you. But if you are a newbie - maybe even a schoolkid - trying just
> to edit your local area, then being presented with "The following
> conflicts were detected. Accept/Resolve/Revert?" will just utterly
> confuse you, and you'll click the wrong thing and cause more errors.
> Or maybe just close Potlatch and never return to OSM.
> 
> The second is that, in JOSM, your "canvas" is usually quite small -  
> i.e. you have downloaded a particular area and are working on that  
> exclusively. In Potlatch, because you can pan around an infinite
> map, your canvas may be much bigger. You may have traced a 600km
> cycle route (I know, I've done that! :) ) in one session. Yet you
> can't zoom out to see the whole thing, because requesting a 600km
> bounding box would break both the server and the browser. So you
> would be clicking "Save" to upload changes that you can't actually
> see or review, and that - in my opinion - defeats the point of it.
> 
> But actually they're not my biggest problem with the idea.
> 
> What worries me most, because I've seen it before, is that people
> are seizing on the first thing they don't like, and thinking that's
> the reason why there are bad edits. People used to criticise Potlatch
> for causing bad edits because there was no 'revert' feature, so I
> added a revert feature (the H key). Then they criticised Potlatch for
> causing bad edits because there was no 'test' mode, so I added a test
> mode. Then they criticised Potlatch because there was no 'splash
> screen' explaining things, so I added a splash screen. Now they
> criticise Potlatch because there's no compulsory 'save' button.
> 
> But if I added a compulsory save button tomorrow, it wouldn't stop  
> the bad edits. The bad edits are principally because these guys are  
> newbies. Newbies make mistakes. (Experienced users don't make  
> mistakes with Potlatch just because it has no Save button.)
> 
> And in a week's time, someone would be saying "Potlatch must be  
> banned unless it has a pony" (or something) and there'd be a lot of  
> postings saying "yes, the reason there are all these bad edits is  
> BECAUSE POTLATCH HAS NO PONY". And so, a few weeks later, Potlatch  
> would get a pony, which would make it even harder to use (ponies are  
> quite stubborn, you know) and require newbies to learn even more,
> and then someone would decide on another "reason" for the bad
> edits... and so on.
> 
> That's not to say that Potlatch can't be improved. Of course it can,  
> a lot. One simple easy-to-fix thing which I'm planning to change  
> soon, and which I think would make an enormous difference, is  
> actually to have a very prominent "uploading..." display when a way  
> is being uploaded. This would make it pretty obvious the first time  
> that you changed something that it was writing to the map. You would  
> make one bad edit, maximum. (In general, making what's happening  
> "transparent" and obvious is a good thing, and Potlatch doesn't  
> follow that principle enough at the moment.)

Wouldn't that be to late? The edits (mistakes) made will be uploaded
already!
Isn't it better to prevent such uploads by adding a simple session
management to Potlatch and a better method to inform users about their
changes they have made.
Even because Potlatch is an online editor it should be possible to
resolve conflicts at the time they occure.

The conflict management could be simple, a new API call 'lock' could be
introduced to lock and unlock ways for editing (online editors only?).

Example:
User 'A' wants to edit way 'XYZ', Potlatch will request a lock for
that way with "/api/x.x/way/XYZ/lock". If the way is already locked
than the API returns a negative response, Potlatch has to inform the
user that the way is locked and he should try to edit again later.
On a positive response the way will be locked for that user until
he save his changes or a timeout occures.

Now you can use edit sessions with a save button and to keep the
sessions short, Potlatch should ask the user to review and than save
his changes if he pans to far away from his last changes or after 3 - 5
minutes or so.

And, how about showing a shadow copy of the moved ways and nodes?

> mfg :)
> Richard

With best Regards :)
    Christian
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20080609/24a080ad/attachment.sig>