[OSM-dev] OSM API Improvements work

[Frederik Ramm]

Hi,

On 11.10.2012 21:26, Tom MacWright wrote:
> * Filtering the API endpoints, so that POI editors don't have to sift
> through road data, and so on.

There is a relatively arcane search function in the API that has gon 
through a series of disabling stages - initially you could do a 
key/value search but not limit to area; later I believe that was limited 
to key-only search, and now it doesn't work at all (something like that).

Good and powerful replacements exist in JXAPI and Overpass; both have 
the advantage that they can be installed by people on their own machines 
without having to put the whole rails port in place. Due to the 
sychronisation delay, both services might incur a higher percentage of 
version conflicts when used in an editor (but then again, if the editor 
loads and uses the data for 10 minutes then the additional minute won't 
change much). Yes, these systems are different systems, but on the other 
hand it is quite possible that we'll separate the API database into a 
r/w core and a read-only mirror some day soon, satisfying read responses 
from a replicated database in order to take load off the r/w core - that 
would then be two systems as well. So the difference isn't that big perhaps.

Care must be taken to limit everything that goes via the central API to 
editing - that's why we like to call it the "editing API". It is not 
meant to be a "make interesting queries API" like JXAPI/Overpass are.

Doing filtering for an editor, and doing it right, is very difficult and 
will require intense analysis of existing data to get an idea of how 
things are interconnected. A POI editor that requests everything with 
amenity=* needs to receive the building (and its nodes) tagged 
amenity=restaurant; the fact that one of the building nodes is also part 
of a highway=steps that links the building to the nearest street must be 
made known to the editor lest it allows the user to move the building 
node and thereby, unknowingly, distort the staircase, stuff like that.

If you want to design API endpoint filtering mechanisms you will have to 
think: What is the stupidest thing an editor writer could do with this? 
And then assume that someone writes an editor that does just that... and 
hopefully find ways to reduce the impact of such.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"