Skip to Content.
Sympa Menu

overpass - Re: [overpass] Date ranges with Overpass API

Subject: Overpass API developpement

List archive

Re: [overpass] Date ranges with Overpass API

Chronological Thread 
  • From: Roland Olbricht <>
  • To: ,
  • Subject: Re: [overpass] Date ranges with Overpass API
  • Date: Tue, 6 Dec 2016 07:09:50 +0100

Hi mmd,

Available logical operators are "||", "&&", and "!".

How do you define precedence rules for those operators, in which
sequence are they evaluated? It is also possible to specify brackets,
like a && (b || c) ?

Yes, brackets are possible. The operator precedence is the same as in C, C++, Java, and JavaScript:
although not all operators are implemented.

I think it would sense to at least consider the comma. Regarding unit of
measures, someone posted some ideas here:

Not sure if this is feasible or even useful, just wanted to mention it.

Thank you for the reminder. Honestly, I don't understand what the writer is after. In particular, unit conversion is cheap, and it makes sense to have custom units in some case (e.g. verbatim copies of traffic signs in "mph" and "ft"). I'm tending towards a set of functions

- si_length, is_length
- si_speed, is_speed

or so that deliver a number in SI units if the input unit is known. If no unit is given but the value is numerical then it is understood as number in SI units. A function "kph_speed" might do better, because the default unit for speed in OSM is "km/h" instead of "m/s".

This allows people to use less and greater regardless of units in the intuitive sense.

I noticed that those functions internally return "1" and "0", even for
boolean values. I guess there's a good reason for doing so (didn't look
into the details yet).

After all, I don't want to introduce a type system at this point. There is more than enough new stuff for the users to digest. The rule is that the logical operators understand the empty string or a string that can be parsed as number zero as false and everything else as true.

It would be extremely cool to have [tag] also on the right hand side,
and the value extracted from another inputset with just one element.

Please have a look at

You can leave out the "._" (or replace it by a different set). This is the placeholder for the set to take, and "_" is the default choice.

We already have an issue with lots of use cases around counting:

BTW: I'm in total considering these eleven issues for the design of this feature:
add synthetic tags to parts of the result
Numerical comparison
Additional sort orders
Refactoring of output architecture
simplification ?
number of tags of a object
New filters based on counting functions
Overpass result_set in overpass answer
Query by object version number
Add tags filter
Annotate per output step
Idea: add function to sum up spatial length of ways

Not all of them will get completely addressed. But solutions to them should be possible with the enhanced design, or at least the enhanced design should not impede their implementation.



Archive powered by MHonArc 2.6.18.

Top of Page