[OSM-dev] Potlatch based OSM walkers editor

Richard Fairhurst richard at systemeD.net
Fri Oct 19 11:33:59 BST 2007


Tom Hughes wrote:

> Exposing the Potlatch API more widely is definitely a concern
> actually - specifically the fact that it (at least in part) pushes
> out the responsibility for maintaining database integrity to the
> client.

The Potlatch API (specifically amf_controller.rb) should really  
handle integrity issues like the rest of the API. If it doesn't then  
that's more a fault of my coding sk1llz not being l33t enough, rather  
than an intentional design decision.

amf_controller.rb has four read-only actions (getpresets, getway,  
whichways, getpoi) which can be safely ignored. The three actions  
that write to the db are putway, deleteway and putpoi. These three  
are designed to work no matter what the state of the database was  
beforehand - in fact, the first thing that putway does is actually a  
getway query, so that it's comparing against the current state of the  
OSM db rather than the state at the last Potlatch download.

Now there may well be restrictions that are implemented in the  
standard API (whether as part of Rails or expressly) that aren't  
implemented in Potlatch. But that's most probably because I'm not  
aware of them and because no-one has got sufficiently pissed off that  
they've hacked amf_controller.rb to insist on them. If there's  
anything amf_controller should check but isn't doing, let me know  
what and I'll implement it.

There have been bugs (most recently putpoi wasn't checking whether a  
POI had become part of a way before deleting it), and there are  
doubtless still some to iron out, as per recent discussions! But on a  
wider level, the one conceptual failing in Potlatch's API at the  
moment is the lack of support for transactions. Really, each write  
action (especially putway) ought to be a single transaction, so that  
another client interrogating the db during Potlatch's putway doesn't  
get a half-complete state (e.g. nodes written but not the way).

cheers
Richard




More information about the dev mailing list