Overpass API developpement

[mmd <>]

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

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

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:

http://wiki.openstreetmap.org/wiki/DE:Overpass_API/Beispielsammlung#Abweichende_addr:postcode.3DXXXXX_Tags_innerhalb_einer_Grenzrelation_mit_postalcode.3C.3EXXXXX

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:
> http://overpass-turbo.eu/s/ks2
> 
> And find named objects that do not have any other tag:
> http://overpass-turbo.eu/s/ks3
> 

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

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

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
like:
- 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. 

Great!

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


best,
mmd