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: mmd <>
  • To:
  • Subject: Re: [overpass] Date ranges with Overpass API
  • Date: Mon, 5 Dec 2016 19:16:54 +0100

Hi Roland,

Am 03.12.2016 um 22:53 schrieb Roland Olbricht:

first impression, looks great!

> The new part is (if:[start_date]>1800 && [start_date]<1900).
> This is combined of
> - the framing (if:...)
> - the logical operator "&&"
> - the comparison operators "<" and ">"
> - the tag evaluator [...], applied on the tag with key "start_date"
> 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) ?

> Available comparison operators are "==", "<", "<=", ">", and ">=".
> The comparison is numerical if both values are numerical and as strings
> otherwise.
> One thing I'm not sure for example is what should be recognized as
> number and what is outside scope. I wanted to search for peaks outside
> Rome with elevation between 500 and 1000 meters. To cross-check whether
> all values are numbers I have used this:
> This is a function that returns 0 if the value cannot be parsed as
> number and 1 if it is a number.

> It turns out that entries with comma and entries with explicit
> measurement unit exist. Shall we treat them as first-class numbers or not?

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.

> Available functions with one argument are:
> - "number" makes a number of its argument
> - "is_num" checks whether its argument can be parsed as number
> - "date" makes a double representing a date out of its argument
> - "is_date" checks whether something can be parsed as date

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).

> I have already mentioned "[...]" as operator that takes a key and
> returns the value of the tag if it exists or the empty string otherwise.

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.
This would cover use cases like deviating zip codes combined with a
foreach clause, see:

Filtering objects depending on some other object is frequently asked for.

> Finally, you can also count tags and members. Find all ways with more
> than 1000 members around Birmingham:
> And find named objects that do not have any other tag:

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

Could you please take a look at those details and see what could also be
incorporated, or is already covered by your implementation? E.g. things
- distinct nodes, or
- how often a node is contained in a way/relation

> There is more to discover. But I would like to get feedback to adjust
> the syntax where appropriate. For example, if you have suggestions for
> extra operators (do we need "!=" or bit shifts?),

Right now, I don't see an obvious use case for bit shifts, but != might
come in handy for sure.

> I will try to
> incorporate them.


> The only thing I will stick to is the C-like syntax -
> I'm heading more towards JavaScript to relieve the programmer's mind
> from learning yet another query language.

This I didn't quite get. :)


Archive powered by MHonArc 2.6.18.

Top of Page