Overpass API developpement

Text archives Help


Re: [overpass] Date ranges with Overpass API


Chronological Thread 
  • From: Roland Olbricht <roland.olbricht@gmx.de>
  • To: overpass@listes.openstreetmap.fr, overpass@osm101.openstreetmap.fr
  • 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:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence
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:

https://github.com/drolbr/Overpass-API/issues/78#issuecomment-71068992

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
http://overpass-turbo.eu/s/ktW

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:

https://github.com/drolbr/Overpass-API/issues/197

BTW: I'm in total considering these eleven issues for the design of this feature:

https://github.com/drolbr/Overpass-API/issues/49
add synthetic tags to parts of the result

https://github.com/drolbr/Overpass-API/issues/78
Numerical comparison

https://github.com/drolbr/Overpass-API/issues/81
Additional sort orders

https://github.com/drolbr/Overpass-API/issues/136
Refactoring of output architecture

https://github.com/drolbr/Overpass-API/issues/171
simplification ?

https://github.com/drolbr/Overpass-API/issues/180
number of tags of a object

https://github.com/drolbr/Overpass-API/issues/197
New filters based on counting functions

https://github.com/drolbr/Overpass-API/issues/206
Overpass result_set in overpass answer

https://github.com/drolbr/Overpass-API/issues/219
Query by object version number

https://github.com/drolbr/Overpass-API/issues/221
Add tags filter

https://github.com/drolbr/Overpass-API/issues/236
Annotate per output step

https://github.com/drolbr/Overpass-API/issues/237
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.

Cheers,

Roland




Archive powered by MHonArc 2.6.18.

Top of page