GIScience
elements* returns some nodes with no tags
Bug Description
When using the properties=metadata parameter, the user expect to have nodes containing tags. When using elements or elementsFullHistory, some nodes containing no tag are returned. This seems to happen because an older revision of the node had tags.
Here is an example: https://www.openstreetmap.org/node/2168030908 In this case, someone spammed on a node belonging to a way, using tags; these tags have been removed, but the node is still in the API response
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: 1
- Which API instance was requested :
https://api.ohsome.org/v1 - Affected endpoint(s):
/elements/geometry,/elementsFullHistory/geometry, ... - URL of your request: https://api.ohsome.org/v1/elements/geometry?bboxes=9.188295196%2C45.4635324507%2C9.1926242813%2C45.4649771956&time=2021-06-28T09%3A00%3A00Z&types=node
- Used HTTP method: GET
- Utilized tool/library for the request: cURL
Expected Behaviour
No nodes with no tags should be returned, independently of their history.
Further Information
Additional Information
Using properties=metadata,tags just to filter out empty nodes can require 15 minutes, compared to 5 seconds of the very same query with just properties=metadata. Otherwise, a different API call to a different service should be used.
Notes
This behaviour seems inconsistent to me, as it does not affect *FullHistory endpoints only. That is why I opened a bug report instead of a feature request. If no nodes without tags belonging to a way are shown, why similar nodes which had an old revision with some tags should be returned?
some nodes containing no tag are returned.
This is actually the expected behaviour, for the reason you correctly identified that these nodes had tags in an earlier version. Currently, there is no way to filter these objects from the output, so the only way is for to filter these on the client side.
URL of your request: https://api.ohsome.org/v1/…&types=node
please note that the types parameter is deprecated since version 1.0 of the ohsome API. Since this parameter will be deactivated in some of the upcoming versions of the ohsome API, it would be better to already use the filter parameter instead: …&filter=type:node
Using properties=metadata,tags just to filter out empty nodes can require 15 minutes, compared to 5 seconds of the very same query with just properties=metadata.
I cannot confirm this behaviour. In my tests (using the example URL from above), the time to query tags in addition to the metadata properties increases from ~1.2s to ~3.4s. Yes, it's substantially slower, but it should still be fast enough for your use case, I suppose? Could it be that in your test, you changed not only the properties tag, perhaps?
This behaviour seems inconsistent to me, as it does not affect *FullHistory endpoints only. That is why I opened a bug report instead of a feature request. If no nodes without tags belonging to a way are shown, why similar nodes which had an old revision with some tags should be returned?
Sorry, I can't follow you here. Can you explain again what exactly you mean? In principle the behaviour of the ohsome API should be that OSM nodes which had at least one tag in their entire version history are considered in all endpoints. Can you give some examples where this is inconsistent?
