A mapper suggested on OSMUS Slack that the search bar on openhistoricalmap.org should return chronology relations in response to simple queries (as opposed to structured queries). Chronology relations have become prominent within OHM, so a user would expect a way to find them. Currently, you can only access a chronology relation by searching or querying for one of its members, or by querying Overpass.
Chronology relations aren’t strictly geographical constructs, so it might be awkward to integrate them into Nominatim. I assume it would involve indexing the relation by the names and geographies of each of its members. Nominatim can be configured to import arbitrary relation types, but each relation must be processed as either a MultiPolygon or MultiLineString geometry, whereas a chronology relation is more like a GeometryCollection.
Alternatively, the website can supplement Nominatim results based on its own database views. At the point where we parse the responses, we could perhaps preload the feature to get its containing relations. But that could be slow depending on the feature. Or we could add another source that’s based on an Overpass query for chronology relations containing the Nominatim search results.
A mapper suggested on OSMUS Slack that the search bar on openhistoricalmap.org should return
chronology
relations in response to simple queries (as opposed to structured queries). Chronology relations have become prominent within OHM, so a user would expect a way to find them. Currently, you can only access a chronology relation by searching or querying for one of its members, or by querying Overpass.Chronology relations aren’t strictly geographical constructs, so it might be awkward to integrate them into Nominatim. I assume it would involve indexing the relation by the names and geographies of each of its members. Nominatim can be configured to import arbitrary relation types, but each relation must be processed as either a MultiPolygon or MultiLineString geometry, whereas a chronology relation is more like a GeometryCollection.
Alternatively, the website can supplement Nominatim results based on its own database views. At the point where we parse the responses, we could perhaps preload the feature to get its containing relations. But that could be slow depending on the feature. Or we could add another source that’s based on an Overpass query for chronology relations containing the Nominatim search results.