Overpass API developpement

[Jochen Topf <>]

Hi!

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
way!

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

> - "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:
> http://overpass-turbo.eu/s/ks2
> 
> And find named objects that do not have any other tag:
> http://overpass-turbo.eu/s/ks3
> 
> 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
-- 
Jochen Topf    https://www.jochentopf.com/  +49-351-31778688