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: Jochen Topf <>
  • To: Roland Olbricht <>
  • Cc: , Andy Townsend <>
  • Subject: Re: [overpass] Date ranges with Overpass API
  • Date: Mon, 12 Dec 2016 14:00:15 +0100


On Sat, Dec 03, 2016 at 10:53:38PM +0100, Roland Olbricht wrote:
> way[start_date](if:[start_date]>1800 && [start_date]<1900)({{bbox}});
> out center;
> 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"

The overpass language has always been difficult to understand. Adding
this (if:...) stuff makes it even more complex. If I understand this
correctly, "way[start_date]" matches all ways with tag start_date. So
here "[]" is a kind of "condition" operator. The ({{bbox}}) means it has
to be inside that bbox, so the condition operator here is the "()". Now
there is a new condition operator "(if:..)" and inside it "[]" is not
used for conditions but to "evaluate" the tag. There must be a better

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

Handling units is difficult and I don't really have a good solution for
that. Maybe you need functions to extract the value and unit: So for tag
"width=10m", the functions "number([width])" and "unit([width])" would
return 10 and "m" respectively. But to use this you would have to write
things like "if (number([width]) > 10 and unit([width]) == "m") or
(number([width]) > 30 and unit([width]) == "ft")" to compare feet and
meter. Maybe something like number_with_unit([width], "meter") which
would give you 10 for "10m" and 3 for "10ft", so always converting into
the second parameter (here: meter). But once you go down this road,
you'll need floating point numbers probably and so on. At some point the
question is whether a query language can handle all this or if the user
has to do post-processing themselves.

> Available functions with one argument are:
> - "number" makes a number of its argument
> - "is_num" checks whether its argument can be parsed as number

Why is that "number", but "is_num"? "is_number" would be more

> - "date" makes a double representing a date out of its argument
> - "is_date" checks whether something can be parsed as date
> 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.
> There is a corresponding function "is_tag(...)" that returns 1 if there
> exists a tag of the key or 0 otherwise.
> 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:
> 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?), 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.

I don't see the need for bit shifts, but "!=" is definitely useful and
people will expect it to be there.

Jochen Topf +49-351-31778688

Archive powered by MHonArc 2.6.18.

Top of Page