bug: area/density endpoint calculates area wrong

[Gigaszi]

Bug Description

When running the area/density endpoint the result is way too high (in swagger its over 4000).
From swagger UI examples for area endpoint (both request the same data):

curl -X POST "https://api.ohsome.org/v1/elements/area" -H  "accept: application/json" -H  "Content-Type: application/x-www-form-urlencoded" -d "bboxes=8.67%2C49.39%2C8.71%2C49.42&filter=type%3Away%20and%20natural%3D*&format=json&time=2014-01-01%2F2017-01-01%2FP1Y"

area/density endpoint:

curl -X POST "https://api.ohsome.org/v1/elements/area/density" -H  "accept: application/json" -H  "Content-Type: application/x-www-form-urlencoded" -d "bboxes=8.67%2C49.39%2C8.71%2C49.42&filter=type%3Away%20and%20natural%3D*&format=json&time=2014-01-01%2F2017-01-01%2FP1Y"

General Information

Please include the following general information about the issue and list any additional steps needed to reproduce the bug.

• Version of the ohsome API [e.g. 1.10.4]
• Which API instance was requested [e.g. remote instance at https://api.ohsome.org/v1, local instance with an h2 file or connected to the cluster, etc.]
• Affected endpoint(s) [e.g. /contributions/count]
• URL of your request (and request body if applicable)
• Used HTTP method [GET or POST]
• Utilized tool/library for the request [e.g. cURL, Postman, ohsome-py, etc.]

Expected Behaviour

Should return a value between 0 and 1.

Further Information

Currently, the data/density endpoint calculates the area of the input geometry in sqkm but the data of the OSHDB response is in sqm. The error is in this line:

ohsome-api/src/main/lombok/org/heigit/ohsome/ohsomeapi/executor/AggregateRequestExecutor.java

Line 317 in 2d62b62

df.format(entry.getValue().doubleValue() / (Geo.areaOf(geom) * 0.000001))));

thx @rtroilo
Just remove the multiplication and everything should work.

[tyrasd]

Well, this is currently the "intended" behavior: the density endpoints return the result in square-meters per square-kilometers, meaning that the returned values are between 0 and 1,000,000. This is because the area endpoints always return results in m², while the */density endpoints are based on km². The reasoning behind this is to avoid returning values with too many zeros behind the comma (e.g. something like 0.000000123), as such numbers are hard to read and comprehend. As polygonal features in OSM (e.g. buildings) can be quite small, they are best measured in m²: Thus we use m² for all area endpoints. But if one would also use m² for the */density calculations, the results for a typical question like: "how dense is the road network in a particular city" would again have a zero with many zeros behind the comma. So, we use km² as the base for the density calculations. Thus it follows, that the area/density endpoints are (arguably somewhat unexpectedly) returning values that are not purely dimensionless, but instead in m²/km².

If you need a value in m²/m², you should just divide the result by 1E6 in post-processing.

Should return a value between 0 and 1.

Slightly unrelated: but please note that even if the units would fully cancel out, the result could still be larger than 1: if there are overlapping areas in OSM (e.g. because of a mapping error, or when one counts both the landuse=residential area and the building=* areas within it), the sum of the areas can be larger than the area of the area of interest (e.g. the query bounding box).