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). _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
