You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be possible to allow numeric comparison like greater than, lesser than? This would be easier to understand (and might be more efficient?) than having to use a regular expression to match a range of numbers I think.--G0ldfish 16:56, 17 October 2012 (BST)
It would be cool if you could use numeric operators, like in " ["width">7] or ["fee"<10] --Gormo (talk) 11:08, 16 August 2013 (UTC)
Tags with numeric values (i.e. "width") may also contain units string ("5 m", "15 ft") or qualitative string values ("narrow").
Units are often implicit, i.e. "5" is the same as "5 m" for width because meters is the implicit default unit for Length.
We could have three cases in our pool of tags (qualitative values not taken into account here):
only numeric values without units
a mix of tags with and without indication of the same unit (most frequent case locally I presume).
a mix of tags without indication of units, and with indication of different units.
Basic assumptions:
I won't expect the query engine to make any unit conversion.
User should know the implicit units at work for the tag.
Qualitative values (which are deprecated for the width tag) cannot be dealt with numeric comparison and should be handled with a separated query. (i.e. width < 4 or width = 'narrow')
Then how to specify units?
["width"> "7"] returns only the numeric values > 7 which do not specify units
["width"> "7 m"] returns only the numeric values > 7 which do not specify units or specify m as units.
["width"> "7 +m"] returns only the numeric values > 7 which specify m as units.
The use and position of the plus sign in "+m" is just an idea.
This way we can handle the generic case easily (["width"> "7 m"]) and then handle the rest unioning with specific queries (["width"> "21 +ft"], ["width" = "wide"])
As a general rule, the user should always specify units when querying values which are expressed in some unit.
Is there any progress or plan on this feature ? Or course the ability to specify a unit is powerful, however as a first implementation using default units as specified in http://wiki.openstreetmap.org/wiki/Map_Features/Units would be a great enhancement to the Overpass API.
I just wanted to select addresses using addr:street and addr:housenumber. Doing that with a regex is very hard. A greater or less than operator would be really helpful.
I've seen this on the Overpass list and this is just great news (along with the other improvements coming up) ! I'll be very happy to play with this feature ... when I get a chance (overloaded at the moment).
Real great news, thanks for that good work !
Antoine.
The Language Guide currently has 8 (in words: eight) information message boxes referring to the Overpass QL wiki page for a comprehensive list of most recent features. The Language Guide hasn't been updated for at least 3 years, and all new features are only documented on the Overpass QL page.
@mmd-osm I've several times tried reading https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL and frankly, communication did not always occur. It suffers from a number of problems - the "florid nature" of the language, the difficulty of searching (it reads like a laundry list of features rather than examples to solve problems), and the frankly "unusual" Overpass QL syntax ([{{brackets}}]!).
It suffers from a number of problems - the "florid nature" of the language,
I get your point. However, that's pretty much the same as with the Language Guide page, right? Or, do you find the Language Guide easier to digest, and if so, why in particular?
the difficulty of searching (it reads like a laundry list of features rather than examples to solve problems),
I think if you encounter such issues, it might be worthwhile adding them to the Talk page.
the frankly "unusual" Overpass QL syntax ([{{brackets}}]!
Hmmm. this is all very similar to CSS, after all. Nowadays, the XML syntax variant is less common (but still fully supported), and all new documentation is written in Overpass QL syntax.
Also, if you're looking for some good examples, you probably want to head for our fine selection of examples: https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example - many of those help osm, osm forum, stackoverflow and GIS stackexchange questions can be found in that one central location.
I know (having occasionally tried to do it as part of an actual job) that writing good documentation is really, really hard
I believe the main issue really is that we need more people reviewing documentation and providing valuable input, especially from native speakers.
Yes, that's useful, though for example I would for example break up the "Find newbies mapping railway signals" example into two - "things last modified by a person" and "things modified after a date".
Activity
mmd-osm commentedon Jun 29, 2014
Some of the requirement were previously tracked on Wiki Discussion page.
sigfrido commentedon Jan 22, 2015
Tags with numeric values (i.e. "width") may also contain units string ("5 m", "15 ft") or qualitative string values ("narrow").
Units are often implicit, i.e. "5" is the same as "5 m" for width because meters is the implicit default unit for Length.
We could have three cases in our pool of tags (qualitative values not taken into account here):
Basic assumptions:
Then how to specify units?
The use and position of the plus sign in "+m" is just an idea.
This way we can handle the generic case easily (["width"> "7 m"]) and then handle the rest unioning with specific queries (["width"> "21 +ft"], ["width" = "wide"])
As a general rule, the user should always specify units when querying values which are expressed in some unit.
naomap commentedon Jan 28, 2016
Is there any progress or plan on this feature ? Or course the ability to specify a unit is powerful, however as a first implementation using default units as specified in http://wiki.openstreetmap.org/wiki/Map_Features/Units would be a great enhancement to the Overpass API.
marcelvb commentedon Apr 5, 2016
I just wanted to select addresses using addr:street and addr:housenumber. Doing that with a regex is very hard. A greater or less than operator would be really helpful.
lemio commentedon Aug 2, 2016
For populations of cities it could also be really useful to be able to define greater than or less than...
mmd-osm commentedon Dec 5, 2016
See announcement: http://gis.19327.n8.nabble.com/Date-ranges-with-Overpass-API-td5886864.html
naomap commentedon Dec 5, 2016
I've seen this on the Overpass list and this is just great news (along with the other improvements coming up) ! I'll be very happy to play with this feature ... when I get a chance (overloaded at the moment).
Real great news, thanks for that good work !
Antoine.
drolbr commentedon Apr 27, 2017
Numeric comparison has been implemented in version 0.7.54.
Support for suffixes implemented in e3dcf38.
matkoniecz commentedon Nov 11, 2017
It seems that syntax was changed, the example http://overpass-turbo.eu/s/ks1 gives now
Maybe I missed something but https://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide is not covering this syntax
mmd-osm commentedon Nov 11, 2017
Yes, that's correct, the new syntax looks like this:
The Language Guide currently has 8 (in words: eight) information message boxes referring to the Overpass QL wiki page for a comprehensive list of most recent features. The Language Guide hasn't been updated for at least 3 years, and all new features are only documented on the Overpass QL page.
SomeoneElseOSM commentedon Nov 11, 2017
@mmd-osm I've several times tried reading https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL and frankly, communication did not always occur. It suffers from a number of problems - the "florid nature" of the language, the difficulty of searching (it reads like a laundry list of features rather than examples to solve problems), and the frankly "unusual" Overpass QL syntax ([{{brackets}}]!).
I know (having occasionally tried to do it as part of an actual job) that writing good documentation is really, really hard, and these days some people seem to think that writing any documentation is a luxury, but I've still ended up resorting to help questions like https://help.openstreetmap.org/questions/53100/overpass-overpass-turbo-how-to-search-for-recent-changes-only .
mmd-osm commentedon Nov 11, 2017
@SomeoneElseOSM :
I get your point. However, that's pretty much the same as with the Language Guide page, right? Or, do you find the Language Guide easier to digest, and if so, why in particular?
I think if you encounter such issues, it might be worthwhile adding them to the Talk page.
Hmmm. this is all very similar to CSS, after all. Nowadays, the XML syntax variant is less common (but still fully supported), and all new documentation is written in Overpass QL syntax.
Also, if you're looking for some good examples, you probably want to head for our fine selection of examples: https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example - many of those help osm, osm forum, stackoverflow and GIS stackexchange questions can be found in that one central location.
I believe the main issue really is that we need more people reviewing documentation and providing valuable input, especially from native speakers.
SomeoneElseOSM commentedon Nov 11, 2017
Yes, both pages are similar - that's why I tend to trawl help questions and forum posts.
True, but not everyone is familar with CSS. The XML syntax version appeared (at least to my eyes) far more logical and understandable.
Yes, that's useful, though for example I would for example break up the "Find newbies mapping railway signals" example into two - "things last modified by a person" and "things modified after a date".