Reporter: owhite[at]yahoo.com
[Submitted to the original trac issue database at 9.53pm, Sunday, 3rd December 2006]

See also proposal #281 for another search API

==Background==

Applications such as the osm@home Places website need to download a full list of objects matching some query (e.g. all cities) but do not wish to download the entire OSM dataset (via API or planet) to do so due to bandwidth or CPU concerns

• The osm@home site would like to retrieve all nodes containing a place= tag

• A wikipedia robot might like to get all nodes containing a wikipedia= tag

• A sticky-note application like NickW's one might want all nodes with a notes= tag

==Proposal==

API that accepts a filter and optional bounding box, and returns nodes in OSM format

Filter

• By existance of tags (must_exist=place)

==Use in search==

There are many ideas on how best to do search, see wiki page for examples. By adding a node-filter API, it becomes possible for many different people to write their own version of an OSM search, each of which can use latest data

• "pubs near birmingham" could be split into two queries by the application: search for nodes with a place attribute to find the city, then another search for nodes with an amenity attribute using a bounding box around that city to find the pubs

• "pubs near london, england" would simply take the results of the first search and look in returned is_in tags for which country the city is in

• "poi:British Museum" could do a search for nodes with a wikipedia tag, then look for ones linking to British Museum

• "bedford station" could search for nodes with a railway tag

It would be good to cover the most common case by adding a text-based search into the node filter, so that if someone knows the name of a node then it can be filtered before leaving OSM, hence lower bandwidth

Filter:

• By case-insensitive name, e.g. "name=newcas"

(where caseinsensitive might need to be told about the UTF-8 locale)