Scientific notation in numbers

[westnordost]

I noticed that the Overpass API understands the scientific notation, i.e. ...

node[amenity=atm](51.0,1e-6,51.5,0.5);
out geom;

(overpass-turbo)

...but not if written with a capital E.

node[amenity=atm](51.0,1E-6,51.5,0.5);
out geom;

overpass-turbo

Is this deliberate?

In my opinion, it would be ideal if the overpass API would accept (and output) the same as the OSM API does. The OSM API understands scientific notation both with a small and a capital E.

1. Notes: https://api.openstreetmap.org/api/0.6/notes?bbox=1E-7,51.0,0.1,51.5
2. Trackpoints: https://api.openstreetmap.org/api/0.6/trackpoints?bbox=1E-6,51.5,0.25,51.75&page=0
3. Map: https://api.openstreetmap.org/api/0.6/map?bbox=1E-6,51.0,0.01,51.01

Java formats small floating point numbers by default with a capital E.

[mmd-osm]

Scientific notation is not documented as supported input, it's probably best to simply avoid it altogether. Overpass API uses standard C functions for number parsing, so what you see in case 1 is the result of atof. The error message for Case 2 is triggered by the tokenizer, as this format is unexpected. We already have an issue to improve number parsing (#356) and make it stricter, which would also reject Case 1.

[westnordost]

atof

This is odd, the C++ reference states:

A valid floating point number for atof using the "C" locale is formed by an optional sign character (+ or -), followed by a sequence of digits, optionally containing a decimal-point character (.), optionally followed by an exponent part (an e or E character followed by an optional sign and a sequence of digits).

[mmd-osm]

Right, that's why I wrote:

The error message for Case 2 is triggered by the tokenizer

The tokenizer happens way before atof has a chance to parse those numbers.

[westnordost]

Ok, so if this is your decision, I'd close this after I documented in the overpass reference that scientific notation is not officially supported.

[mmd-osm]

That's really up to @drolbr to decide (the respective issue is still open, which means it's not entirely clear if this format should be supported or not). Adding some comment to the documentation that it's not supported right now probably wouldn't hurt.

[westnordost]

Is he still active though? His last commit was in May.

[mmd-osm]

Sure. It seems like you're looking at the wrong branch, last commit was Aug 25 in api_keys, and there's lots of GDPR related activities going on right now in other repos.

[drolbr]

I don't think it makes much sense.

Valid values for lat and lon are within ranges where exponential notation on numbers does not make much sense. One valid reason to support it would be that tools to generate queries are stubborn on their number output formats.

As this does not hurt either, I will keep this as an enhancement.