Hi all - in the continuing series of “How should we do this on OHM?”, I’m wondering about the best way of handling search results.
For example, the Commonwealth of Virginia has a ton of different relations, and these are just for the state of Virginia… what about the pre-Constitution and colonial versions of Virginia?
Same issue arises for any entity that has gone through various iterations or ownerships… Texas was a Republic, then a state. Various evolutions of a building, growth of a campus, etc., all might have multiple instantiations in the search database. Should relatively similar items be lumped together?
There are numerous ways that might make sense:
Status quo: long list of place boundaries, settlement nodes, streets, buildings, etc.
Status quo, but add chronology relations to the top of the list
Return chronology relations for each type of an entity (e.g. Virginia as a state chronology + Virginia as a colony chronology)
Return chronology relations for all types of an entity (e.g. Virginia as a colony and as a state; Oregon as Oregon Country, Oregon UFT, Oregon Territory, and Oregon as a state all in one chronology)
I haven’t considered time-bounding results to match the current extent of the timeslider, but that could also make sense (although it might be more difficult or confusing UI-wise?).
Even in OSM, Nominatim tends to return lots of different versions of the same real-world feature, for example if a street is broken up into multiple ways (for any reason or no reason at all) or a school is mapped as both a schoolground and a school building. It looks bad in OHM because an oft-changing feature can spam the results so much, and also because the results are sorted by some invisible factor (size, proximity, edit distance) rather than chronologically.
Nominatim currently doesn’t return chronology relations at all. This is unfortunate, because a chronology is often more relevant than one of its members, especially if Nominatim apparently picks at random.
I haven’t considered time-bounding results to match the current extent of the timeslider, but that could also make sense (although it might be more difficult or confusing UI-wise?).
This has been requested as well. Nominatim would need new functionality to index features by date range.
The reverse would be more straightforward – making the time slider jump to the start date of any result you click on. That can be done on the client side rather than the server side.
