empty filter is inconsistent with etl

[SlowMo24]

Problem Description

The empty filter "" indicates that the user wants all (or none?) OSM data. But the filter will not return that due to some reasonable filtering in the ETL like meta-relations or Nodes without tags.

Possible solutions

• disallow the empty filter because it is unreasonable
• warn the user about unreasonable results
• remove untagged ways and relations from the result and warn about missing meta-relations (and similar)
• return empty result (nothing matches)

In addition the ETL process could get a dedicated documentation stating the objects that are not featured in the oshdb and why/how to retrieve them.

[tyrasd]

indicates that the user wants all (or none?) OSM data.

Yeah, I can see that there is some potential confusion around how an empty filter would work. For me, implementing the empty filter as a catch-all instruction in 57e52f7eb172795cab0ec9cf455edb2d35d94e89 was quite "intuitive" since it mirrors the behavior of not calling filter(…) at all. But I can see that one could also interpret it otherwise.

disallow the empty filter

Strictly speaking, a user could always replace an empty filter with something like tag=value or tag!=value which is equivalent to an empty filter. But on the other hand, the disallowing could slightly incentivize the usage of an empty filter. :thinking:

warn the user

This seems like a very reasonable thing to do.

[SlowMo24]

great comment, did not think of the other situations where this can be a problem! In that case my vote goes for

1. removing untagged elements (meaning objects that currently don't have a tag should not match any filter, even not an empty one which would mean removing objects from the db that never had any tag), and
2. well document the missing data, filtered in the ETL and (optionally) additionally warn the user