Overpass API developpement

Text archives Help


Re: [overpass] Date ranges with Overpass API


Chronological Thread 
  • From: Pierre Béland (via overpass Mailing List) <overpass@listes.openstreetmap.fr>
  • To: "overpass@listes.openstreetmap.fr" <overpass@listes.openstreetmap.fr>
  • Cc: Andy Townsend <ajtown@atownsend.org.uk>, Jochen Topf <jochen@remote.org>
  • Subject: Re: [overpass] Date ranges with Overpass API
  • Date: Sun, 4 Dec 2016 00:48:10 +0000 (UTC)

Hi Roland and MMD, Great work both for scalability and new features. It might take me a little bit then 2 weeks to react. I am in a mission in Haiti.

But first look, this looks great.
 
 
Pierre



De : Roland Olbricht <roland.olbricht@gmx.de>
À : overpass@listes.openstreetmap.fr
Cc : Andy Townsend <ajtown@atownsend.org.uk>; Jochen Topf <jochen@remote.org>
Envoyé le : samedi 3 décembre 2016 16h53
Objet : [overpass] Date ranges with Overpass API

Dear all, dear Andy, dear Jochen,

I've completed a public beta for (part of) the next Overpass API
release. It features a huge chunk of new query language elements to
allow "less" for dates. This should satisfy the request Andy has issued
during the SotM-US 2015 for Historic OSM. Jochen has brought up the idea
of a unified query language, and I would like to get as universal as
possible.

The reason for this public beta is that I would like to have some
feedback on the syntax to make it as intuitive as possible. I'm also
interested in all kinds of bugs found. Things are not necessarily fast,
but that can be fixed later on, I'm now only after syntax changes and
functional bugs.

To test against this beta, please use the API endpoint
https://dev.overpass-api.de/api_deriveds/

You can do so in Overpass Turbo by setting "Settings > General > Server"
to "//dev.overpass-api.de/api_deriveds/".

A sample query is to search around Birmingham for things created in the
19th century:
http://overpass-turbo.eu/s/ks1

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"

Available logical operators are "||", "&&", and "!".
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?

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 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 will now wait about two weeks for feedback, write a follow-up with
further features in this branch, and in the meantime return to the
minor_issues branch to fix open bugs.

Best regards,

Roland





Archive powered by MHonArc 2.6.18.

Top of page