Author: david[at]frankieandshadow.com
[Added to the original trac issue at 2.24pm, Thursday, 23rd November 2006]

(David Earl david-frankieandshadow-com said...)

More intelligent street (and place) name searches

If I search for "Elizabeth Way" (to pick a random local example) in the map search at http://www.openstreetmap.org/, I get well over 1,000 hits. The one I'm looking for is number 336 (and also 337-340, because it is split into multiple pieces), preceded by loads of Elizabeth Streets. This can only get worse and is already impractical.

How about the following suggestions to improve the intelligence of the search.

Firstly, using already present data:

If I ask for "Elizabeth Way, Cambridge" (or put the Cambridge bit in a separate box, though the comma seems quite natural):

(i) look up nodes with "place" tags with "place_name=Cambridge" (or "name=Cambridge"),

(ii) for each search result calculate the average latitude and longitude from its nodes if it is a linear feature,

(iii) sort the results by the minimum of the (great circle) distances between that average point and each of the matched places (or possibly a simpler calculation, use 2D geometry - linear distances - first discarding anything not "nearby" - e.g. longitudes or latitudes differ by more than 3 degrees).

(iv) in each displayed result put something like "2.4km from Cambridge, Cambridgeshire, England, UK" (the latter parts from the is_in tag for the place, if there is one) according to which was the smallest distance, then you can immediately see which is the likely one you were searching for in context

Furthermore, I like the way the search is fairly loose, but can more precise matches be put near the front of the list (I think this should take precedence over the above ordering), so if I ask for Elizabeth Way, I get matches for both words before matches for just the first.

To be even better (probably essential) look for special cases among the search terms so that Rd and Road, St and Street, Ave and Avenue, StraBe and Strasse and Str (if that's the correct German abbreviation) etc are treated as equivalent (so if I look up "Elizabeth St", it would match "Elizabeth Street" in the database and vice-versa). This can't just be the last word as some languages (French) put the name last ("Avenue Champs Elysee", "Rue de 14 Juillet")

Secondly, do we want to advocate adding is_in on Ways? This could make the search much beter still:

So if I were to tag Ways as
"is_in=Cambridge" (*) or
"is_in=Cambridge,Cambridgeshire,England,UK"
for example, then:

(a) results could be labelled with the is_in tag, e.g. if I search for "Elizabeth Way" I see (among others) something like
Elizabeth Way (k:name) (in Cambridge, Cambridgeshire, England, UK)
...

(b) searches such as "Elizabeth Way, Cambridge" can be much more precise than my heuristic sort suggestion, narrowing the search to those results which have is_in tags matching Cambridge (i.e. "is_in LIKE '%Cambridge%'" in sql terms, though I'm sure it wouldn't be quite so simple).

Obviously as in the heuristic sort, (b) would pick up all instances of Cambridge, e.g. Cambridge in Massachusetts USA and Cambridge in Gloucestershire UK as well as Cambridge in Cambridgeshire UK. The qualifier could be in a different field if necessary, but the comma seems a pretty natural way to do this.

If I only use form (*) above, might it be further possible to use the hierarchy so that if I search for
"Elizabeth Way, Cambridgeshire"
and a node has "place=" and "place_name=Cambridge; is_in=Cambridgeshire" or "place_name=Cambridge; is_in=Cambridgeshire,England,UK" (or "name=...") then it will find my Elizabeth Way (possibly among a few others). Ditto "Elizabeth Way, UK" etc. That's clearly considerably harder to implement, though I think it is just a join or series of joins depending on how the database is implemented.

Author: osm[at]bcowan.fastmail.co.uk
[Added to the original trac issue at 1.56am, Thursday, 11th October 2007]

Searching is much better now