area filter computes object area clipped to bpolys

[SlowMo24]

Bug Description

The area filter (and possibly the length filter) will compute the area of geometries only within the given area of interest. This is the case even if clipGeometry=false. This is not mentioned in the documentation.

General Information

• Version of the ohsome API: 1.6.1
• API instance: https://api.ohsome.org/v1
• Affected endpoint(s): any
• Used HTTP method: POST
• Utilized tool/library: ohsome-py and cURL

Please find a Repex here.

Expected Behaviour

All three requests should return the same geometry.

Error Messages

None.

Additional Information

Do we want this behaviour if clipGeometry=true?
Do we fix this or update the documentation?

[bonaparten]

Since the clipGeometry variable is set to true for all data aggregation endpoints, only data extraction endpoints are affected. The problem should be related to the filters themselves. @tyrasd what do you thing about it?
If it will not be fixed, it has to be mentioned in the documentation.

[tyrasd]

good catch, @SlowMo24! I would indeed consider this as a bug (in the OSHDB), and have created GIScience/oshdb#433 for this.

[tyrasd]

only data extraction endpoints are affected

I think this also affects aggregation endpoints, when you – for example – count features with given length/area properties. These requests would be affected since the filter would not respect the "complete" size of features which intersect the boundary.

Do we want this behaviour if clipGeometry=true?

IMHO we want filters to be based on the full/unclipped size of the features, regardless of the state of clipGeometry. clipGeometry should only affect the output (which is what the documentation currently states).

[SlowMo24]

we want filters to be based on the full/unclipped size of the features, regardless of the state of clipGeometry

sounds good. I suggest to mention this explicitly like: Note that all filter parameters are applied to the original elements while clipGeometry is a post-processing step. Adherence of the returned, possibly clipped, elements to the filters needs to be ensured by the client

[tyrasd]

FYI: this is already fixed in the oshdb master branch (see GIScience/oshdb#434). We'll wait for a release of the OSHDB to update the documentation here and close this issue.

[SlowMo24]

regarding the documentation, we might even be more specific and mark ALL post-processing steps as such. E.g. I think the boundingbox or centroid endpoints add post-processing steps that follow the filter.

...elements/centroid$filter=area:(5000..)... will return the centroids of all elements whose geometry-area is >5000 and not an empty result (as points do not have an area), while ...elements/bbox$filter=area:(5000..)... will return all bboxes for the same elements, not the bboxes whose area>5000.

In addition the order of the post-processing steps needs to be documented. I.e. is the clipGeometry first or the centroid, so do I get only those centroids that lie within the requested bbox or the centroids of the polygons after they were clipped to the bbox. Currently clipGeometry is first so we may declare that an intermediate step?

Proposal:

---

The API follows a certain processing workflow:

1. elements satisfying the filter, time and boundary parameters are extracted
2. in an intermediate step, elements are clipped to the requested boundary except if clipGeometry=false. In case the parameter clipGeometry is not available, it can be assumed TRUE. This means that e.g. only contributions occurring within the boundary will be returned for the contribution endpoint
3. any post-processing steps will be applied to the intermediate result. Post processing results are:
   • centroid
   • boundingbox
   • aggregations such as count, density, ratio or groupBy

---

Would it be possible to explicitely add the clipGeometry parameter to the other endpoints and maybe rename it to clipResult? This would enable users to decide e.g. if they want to all contributions that are made to elements that intersect with their query area or only contributions that lie within their query area.

[bonaparten]

Would it be possible to explicitely add the clipGeometry parameter to the other endpoints and maybe rename it to clipResult? This would enable users to decide e.g. if they want to all contributions that are made to elements that intersect with their query area or only contributions that lie within their query area.

I'll take a look at it. Could you please open for that a new issue? This issue will be closed when the documentation will be updated.