drolbr
commented
2 years ago This is an unresolved paradox of the transition to faithful OSM data. The conditions are too weak to compute the matching areas, but the conditions are strong enough to compute the matching ways. Admittedly, this is somewhat confusing at the moment. OTOH it is of no service to the user to discard the result although a computation is possible.
In the general framework, I do consider invalid request to be rejected on the base of undefined behaviour. This allows enhancements without breaking backwards compatibility in a rather fussy case. I.e. a request that is invalid in the semantics of an earlier version is allowed to be served anyway, and thus if a newer version can do that then a valid result is a legit outcome in the older version's semantics only if the assertion is undefined behaviour.
Of course, in most cases any invalid request is answered with no results and an error message. However, for complex requests it may always happen that an error occurs after quite some results have already been written.
https://github.com/drolbr/Overpass-API/blob/minor_issues/osm-3s_testing/expected/area/area_bbox.err includes an error "
runtime error: Filters too weak in query statement: specify in addition a bbox, a tag filter, or similar.", while at the same time https://github.com/drolbr/Overpass-API/blob/minor_issues/osm-3s_testing/expected/area/area_bbox.out prints out some result.It's not exactly clear if this is intentional. If the filter is too weak, why is there even an attempt to fetch and print out the data?