Unions filter about osmnx

[gboeing]

Closed by #1204

[gboeing]

Interesting idea for a relatively minimal change to make this a bit smoother for the user. I'm trying to think through the implications and trade-offs of this technique. Please share any insights as such.

See also the discussion at gboeing/osmnx-examples#90 for another (possibly infeasible) idea of addressing this.

[arkty]

Another way to implement this is actually use overpass unions.
This will require to change query creation.

Example code (not tested).

    for polygon_coord_str in polygon_coord_strs:
        way_subquery_str = ""
        for way_filter_str in way_filter:
            way_subquery_str += f"(way{way_filter_str}(poly:{polygon_coord_str!r});"
        query_str = f"{overpass_settings};{way_subquery_str}>;);out;"
        yield _overpass_request(OrderedDict(data=query_str))

In some cases, polygon_coord_str can be really long (because poly statement will appear in each way query), therefore request payload size will be increased. I have not found any limits about request size on Overpass side, so this still can be an implementation option.

---

Adding support for custom_filter to be a list of filters looks like a simple change, but I am not sure will this confuse users or not, because it might be not clear that custom_filter: list[str] means union filter.

On the other hand, creating own query structure for custom_filter will lead to reproducing Overpass query language. And this not looks like a thing that can be easily developed and maintained.

[gboeing]

Overall I think making this change to custom_filter: str | list[str] | None = None would be a sensible enhancement to simplify union queries (thus avoiding nx.compose).

@arkty would you like to open a PR?

@EwoutH this may be of interest given your question at the examples repo.

[arkty]

@gboeing i've created a PR #1204.