Filter extra tags with osm_tag

[FaFre]

Since #576 we can include additional information in the results. This is a great feature, and saves from reloading of full elements a lot of times 👍
Would the data structure also allow to also include the extra tags in the already existing search-filter for osm_tag?

E.g.: api?q=berlin&osm_tag=cuisine

This would be a great addition :)

[lonvia]

The extra data is currently not indexed and thus not searchable. In any case, if we wanted to search for it, this would require some special infrastructure in the query builder. Not impossible but not very high on the TODO list at the moment.

[FaFre]

Has there been a PR recently, where another property got indexed? So I can get an idea about the effort required.

[henrik242]

Just dropping by to show my support for this issue. Filtering based on the extra properties is a necessity in our usecase.

[lonvia]

The most straight-forward solution here would be to have a dynamic mapping template for the extra field, so that we end up with one index per key. Based on that have an extra parameter that has the same syntax as the osm_tag parameter. Only the value filters are not implementable but that is no loss. #594 goes somewhat in that direction but is missing support for arbitrary keys and for querying key-value parameters.

That solution works probably okay as long as there is a restricted set of extra tags. It is unlikely to scale properly once we import all possible extra tags from Nominatim. That's why I was thinking to experiment with doc values instead. Basically the idea here is that the main result selection happens through the query and we can just do some lightweight result filtering by extra tags instead of doing a full index lookup. It is not yet clear to me if doc values can actually achieve that. And even if it works, the question is, what the difference is in terms of query speed and database size.

[henrik242]

PR up for discussion: #908

Feedback very welcome!