There is unrest among the people because of the search field. They can only do simple queries and the query doesn't affect the nodes we load from OSM. They say we eat their bandwidth with too much queries to OSM, which we filter at reception.
So I want to describe how our search works. We query our local database for area of the bounding box of our map extract. The bounding box is scaled to a bigger size for retrieving more nodes at once and do less queries. then these nodes are filtered with the search entries from the textfield. (I would be happy if this filtering could be done inside the sql query, but atm this works for me.) The filtering will give you all nodes to which any search term provided in the textfield matches. If you search "döner pizza" you will get all nodes, which have döner or pizza in any of their tags set. If there is e.g. a Pizzastreet you will get all nodes from this street with the given search. The search does not only affect the value of tags, but the tag name itself. A search for opening_hour will return all nodes, which have the tag opening_hour set. If there is a node, which has opening_hour somewhere set as a value, it will be returned too.
When I want to do the search better, I would like to have it easy to use. There should be no complex syntax to know. We should only query the nodes, we are interested in from the OSM Server. As a user I would definitely want to control if a string must be in every node or can be in any node.
I don't see any way to reduce our query load to OSM without changing the server API. The Overpass API provides e.g. unions and multiple queries in one request. Besides this it provides recursions or loops, but atm I don't see how we could use this.
Tell me what you want from the search syntax. I would keep it the way it is, but would add the feature to tell which words must match to every node. Looking at the software keyboard from android I will use . and & for tokens to tell if this word must math.
A string ".pizza döner" will give you nodes, which must have somewhere as key or value pizza set and may have döner set. This string is overspecified, because döner does not change the result. Maybe I find a way to handle this.
There is unrest among the people because of the search field. They can only do simple queries and the query doesn't affect the nodes we load from OSM. They say we eat their bandwidth with too much queries to OSM, which we filter at reception.
So I want to describe how our search works. We query our local database for area of the bounding box of our map extract. The bounding box is scaled to a bigger size for retrieving more nodes at once and do less queries. then these nodes are filtered with the search entries from the textfield. (I would be happy if this filtering could be done inside the sql query, but atm this works for me.) The filtering will give you all nodes to which any search term provided in the textfield matches. If you search "döner pizza" you will get all nodes, which have döner or pizza in any of their tags set. If there is e.g. a Pizzastreet you will get all nodes from this street with the given search. The search does not only affect the value of tags, but the tag name itself. A search for opening_hour will return all nodes, which have the tag opening_hour set. If there is a node, which has opening_hour somewhere set as a value, it will be returned too.
When I want to do the search better, I would like to have it easy to use. There should be no complex syntax to know. We should only query the nodes, we are interested in from the OSM Server. As a user I would definitely want to control if a string must be in every node or can be in any node.
So what for queries can we send to the Overpass XAPI? Obviously we can query nodes in bounding boxes. We can also say, that a node must have a certain tag present. http://www.overpass-api.de/api/xapi?node[bbox=7.1,51.2,7.2,51.3][highway=bus_stop|traffic_signals] We can query tags, which may have multiple values
http://www.overpass-api.de/api/xapi?node[bbox=7.1,51.2,7.2,51.3][highway=] We can use * for any word or incomplete words like re\ for rewe.
I don't see any way to reduce our query load to OSM without changing the server API. The Overpass API provides e.g. unions and multiple queries in one request. Besides this it provides recursions or loops, but atm I don't see how we could use this.
Tell me what you want from the search syntax. I would keep it the way it is, but would add the feature to tell which words must match to every node. Looking at the software keyboard from android I will use . and & for tokens to tell if this word must math. A string ".pizza döner" will give you nodes, which must have somewhere as key or value pizza set and may have döner set. This string is overspecified, because döner does not change the result. Maybe I find a way to handle this.