This object is in archive! 

Add overpass queries like: where is the next bicycle shop

Wolfgang Kufer shared this idea 8 years ago
Declined

Hello,

overpass (http://overpass-turbo.eu/) allows for special queries in OpenStreetMap, see following example.

/*

This has been generated by the overpass-turbo wizard.

The original search was:

“shop=bicycle”

*/

[out:json][timeout:25];

// gather results

(

// query part for: “shop=bicycle”

node["shop"="bicycle"]({{bbox}});

way["shop"="bicycle"]({{bbox}});

relation["shop"="bicycle"]({{bbox}});

);

// print results

out body;

>;

out skel qt;

Replies (8)

photo
1

A dialog for overpass query creation would be really helpful, even if it only does create the "skeleton" - it's quite difficult on a mobile while on the move!

photo
1

Hi guys,


is this really needed? Isn't better to use offline POI database that is already in Locus and that is generated from same source as use this wizard (OpenStreetMap)? Because search for some POI is already quite easy and I hope that in future it will be even easier :).

photo
1

From my point of view, offline POI DB is very different from Overpass turbo.

1) POI DB has to be downloaded "as sidecar" in a complete vector map, so it's a hundreds of mbytes heavy data transfer, whereas overpass offers a way for one single query only (few kbytes) - but on the other hand, Overpass requires Internet connection

2) Each POI DB file is limited to a single country, overpass can also search across boarders and even world wide

3) In POI DB, we can only search what you imagined we might need to search - or at least I did not find any possibility to search for cross country tracks (e.g. because the planned track is closed), climbing spots (e.g. because it's raining where we currently are), bridges or fords (e.g. important in Iceland),...

4) In POI DB, I did not find any way to add predicates to search, e.g. just gasoline stations currently open AND with LPG, cross country tracks of a certain difficulty AND minimum length, climbing sports with maximum ascend/rope length 30m AND min 5 routes between grade IV and VI, ...

5) Due to design principles, POI DB will always be outdated compared to OSM database


I'm happy that POI DB has finally come and I see a lot of potential, but not the potential to completely replace something like overpass - that would be too much work.

photo
1

Thank you for a summary Georg, understand perfectly.


Seems that there exists usable API: http://wiki.openstreetmap.org/wiki/Overpass_API , which may be used to creating an service in Locus. To be true, I can't imagine how I (or any user), write some search queries on mobile device. I can imagine also some kind of "wizard" for this, but such task is already far away from what I consider as important now.

photo
1

On _all_ devices it's no real fun to write the query XML from scratch - on small devices with tedious multitasking & copy'n'paste and a small / virtual keyboard it's worse than on PCs where you can have help and query side-by-side on the monitor and copy'n'paste is easy and you have all syntax characters available at one keystroke. That is why a wizard would be a big help, even if that would "just" create basic queries (so the skeleton/core of a more advanced query) - a little bit of fine tuning is much easier on a mobile device than creating from scratch.

photo
1

Hello,


have a look at http://overpass-turbo.eu/, there is a wizard to create simple queries. And as Georg already mentioned: If you need a certain type of POI on tour (ie. your glasses got broken and you need repair), most probably you don't have the right POI-DB with you.

photo
1

Oki and when you are on tour, can you imagine you will write such queries on a device to search for required POIs?

photo
1

Well, yes :) as I have a full keyboard on my phone, which I already use often in Locus, e.g. when adding descriptions, opening times, addresses, ... for waypoints (BTW, that's also why I am using Locus so often in landscape layout, which is usually becoming less usable when GUI is reworked - I simply gave up reporting those issues). At least fine tuning a search skeleton that the wizard created is done quite quickly.

photo
2

Hello,


a proposal:


I select 'around_me', then I get a choice like:

doctor | mechanican | shop | restaurant | leisure ...


If I choose ie doctor, I get:

dentist | practioner | ent | surgeon ...


Addionally I can choose:

open now | open next hours | ingnore opening hours

distance 500m | 1km | 10km.


Probably, this is just a xml-list with tag keywords and corresponding icons.

photo
1

@Menion: Sorry, it's long, but as far as I know you, you'll still like the basic idea (understandable from the bold formatted text). The below proposed wizard is quite general, so it could be re-used for any other search provider besides Overpass, e.g. for the offline POI-DB when it shall get predicate support. Of course, it needs a certain context sensitivity, e.g. the supported comparison operators or condition types (key-value/bounding box/element kind/...).

Where you, Wolfgang, write "Addionally I can choose:" I would prefer the simpler yet more generic requirement "the wizard shall offer to add another condition", i.e. users start with one line, choose the type of condition like e.g. a key-value-pair, then 3 fields/columns appear: first an input field for the key, second a dropdown for possible operators (=, ~, !=, !~ and none which means "key has to exist, value is irrelevant"), and and input field for the value. I'd provide e.g. [sport=climbing] and then press "add condition" to add a further line. Here, users can again choose another key-value-pair like ["climbing:bolted"=yes] so I get all bolted climbing possibilities nearby, i.e. http://overpass-turbo.eu/s/cW8

As syntax support for key-value, I guess it's sufficient that quotes are added automatically to avoid errors (e.g. [climbing:bolted=yes] provokes an error as well as [name=Plaza major]) and a ? button gives a short reminder of the most used parts of regex syntax, e.g. [name~"^StartsWith"] and EndsWith$ and [aA]nyOfTheseLetters and one|or|other and . for one arbitrary character and * for any number of arbitrary characters. That static text helps for queries where I just remember "that rock name was starting with fallesia or the like", i.e. http://overpass-turbo.eu/s/cWd

If there is an easy way to once download (similar to download of icon sets, elevation files, etc) an existing key/value database like taginfo or the OSM wiki, the wizard may offer auto-completion, e.g. I typed key "sport" and in the value field I type "cl" and it suggests "climbing" (as I might not recall whether the value is written climb or climbing), as well as a full text search, e.g. I search for "climb" and it returns "sport=climbing" (as I might not recall for which key the value is valid, happens often for amenity/tourism/sport).

Other condition types would be the element kind (node/way/relation) and the bounding box ("currently visible map" or location (existing dialog with GPS/pick/mapCenter/coordinates/...) plus max distance) and maybe around keyword (see http://wiki.openstreetmap.org/wiki/Overpass_API#Around) - remember, the wizard shall IMHO just help with the most often required search parts, so it shall be able to completely create simple searches, and to quickly create the major part / core of complex searches. Users shall be able to switch from the wizard to the generated "pure Overpass QL" query source code in order to fine tune or add advanced query parts/commands. Finally, Locus would send that query code to Overpass and display the results as it does with the existing searches (e.g. addresses).

For such a wizard - AFAIK it would be unique across map apps - I guess the implementation work is a few days, but I never coded for Android so it may be more or less.

@Conditions for opening hours: I guess it's one of the most complicated things that are used very often. We cannot just provide a textual list of the common syntax elements (similar approach as above for regex) as that will not work for very common use cases, e.g. it's practically impossible to get a list of shops that are currently open, as myriads of different opening hour strings can have that result (e.g. 24/7 or Sa 09:00-18:00 or sunrise-sunset are all satisfied at Saturday noon). In the end, I guess Locus needs to provide a date-time-picker so the user can provide a desired opening time (e.g. 2015-11-26 12:33) and then Locus needs to evaluate the search result's opening hours strings (locally or using a web service, with more or less accuracy) against the user provided time. The Locus team may have a short look whether existing code to evaluate opening hours can be reused (technically, so concerning programming language etc), see e.g. on https://wiki.openstreetmap.org/wiki/Key:opening_hours or http://openingh.openstreetmap.de or http://www.osm24.eu

photo
1

Hello Georg D and others.


I'm had discussion about this with Petr, who use this tool also during his work on maps/pois etc. We both agree that it may be an useful tool. But, not a tool that should be available as another feature in Locus. Sorry to say this, but this should be very complex feature that should take huge amount of time. If anyone will be really interested, it should be possible to create this as an add-on - separate application - that will do all hard work and display result in Locus or any other map application.


I see you invested a lot of time to previous post, but such feature is really far beyond from what I wants to have in Locus. Thanks for understanding.

Replies have been locked on this page!