Apologies, as a non-German speaker I can only half-follow this
discussion through Google Translate, and I realise it's very rude to
post in English on a German-speaking list. I thought it would
nonetheless be valuable to follow up two points in particular, hope
you don't mind.
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.)
Another thing is localisation, so that the advice at the start - "If
you click 'Start', you'll be editing the main map directly" - shows
up in German, too. Lots of you have offered help with that, which is
great - thank you all; I hope to have some more news on that really
soon.
mfg :)
Richard
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de