[OSM-talk] Searching and alt_name
David Earl
david at frankieandshadow.com
Thu May 1 11:44:02 BST 2008
I'd like to encourage you, when editing the map, to think about how
people might search for the features you are adding to the map and try
to accommodate them, to try to be helpful to future consumers of the
map data. Using alt_name is one way to do this.
The namefinder already deals automatically with some mechanical
variations(*). But there's often variations in what something is known
as which can't (easily) be accommodated automatically. For example, I
was reading Richard's blog from a few weeks ago about Heathrow
Terminal 5, where he says that we correctly yield the result in a
search. Yes we do, but what if someone had asked for "Heathrow Airport
Terminal 5". Yesterday, that wouldn't have got a hit; today it does
because I added an alt_name tag to it to accommodate this variation.
Namefinder recognises alt_name.
Of course you could put variations in the name tag (maybe separated by
semicolons, or in square brackets, or some such), but then it will all
render, possibly rather verbosely. You might want just "Terminal 5" to
show up on the map rendering, given that "Heathrow Airport" would be
rendered separately in the middle of the ring of terminals and so be
obvious, but searches for "Heathrow Terminal 5" still be successful.
Another example: the search test for tourist attractions has "British
Airways London Eye" and "V&A" as test searches. There's arguably no
need for the rendering to say other than "London Eye" (or "The London
Eye"?) but a search would ideally respond to its full title.
Similarly, the map is rightly labelled "Victoria and Albert Museum",
but searches should respond to V&A. Incidentally, variations aren't
needed for just for the presence or absence of the word "the" (or le,
la, el, il, die, das, der), which is automatically dealt with.
Another example might be function vs name. The name of an office block
in Cambridge is "Eastbrook", but if someone searches for "Inland
Revenue, Cambridge" it might be nice to be able to offer "Eastbrook"
as the answer. (That works, but "HMRC, Cambridge" or "Tax office,
Cambridge" don't and arguably should. Conversely "Chailey House,
Bedford" doesn't work - today - but "Inland Revenue, Bedford" does).
It's usually POIs affected, and it is usually just variations in names
rather than completely different names (when you would probably want
them rendered anyway). Occasionally though street names also have this
problem. Consider one I came across recently: signs say "Long Horse
Croft". You can imagine someone might search for "Longhorse Croft"
(especially as that's how the district council list it on their refuse
collection days list).
I guess in principle, I could automate this at some point, but it is
hard, especially the other way round (signs say "Longhorse Croft",
searcher asks for "Long Horse Croft"), so a variation would be helpful
here, though purists will say "don't code for the inadequacies of the
tools".
David
(*) in things like case, abbreviations (Rd vs Road), accented
characters and diacriticals (München vs Munchen or Muenchen),
ligatures, possessives (St John's vs St John or St Johns) and some
Germanic concatentations (Potsdammerplatz vs Potsdammer Platz). We are
also used to dealing with alternative languages with the name:<lang>
tags, so 'Londres' will find 'London'. Also, the item description is
included, so you don't necessarily need to say "school" in the name -
"King Edward School" will match name=King Edward, amenity=school
(though not at present Konig Albert Schule" unless schule is recorded
as part of the name).
More information about the talk
mailing list