[OSM-talk] Namefinder priorities

[David Earl]

To avoid enormous numbers of confusing duplicates, the Name finder has 
an algorithm which says "items of the same kind with the same name 
within 3km of each other are only represented once".

On the whole, this works very well, but it sometimes causes problems 
with common names, for example many "Main Street" and "High Street" in 
closely spaced neighbouring villages. I tend to put "High Street 
(Cheveley)" for example which disambiguates and I think is often helpful 
visually on the map.

Also, it is often the case that a street will have one or more spurs off 
it with the same name. Then, the spur may be the one the name finder 
chooses rather than the main body of the street. (I sometimes put "Blah 
Street (spur)" as the name, but would prefer not to.)

I am wondering whether it would be useful to have a simple tag such as 
search=true which would override the name finder's algorithm, giving 
preference to that object, and always including it in the index. So if 
there are two nearby instances of High Street both tagged search=true 
they would both get included, and if the main part of Blah Street is 
tagged search=true it would be the one taken in preference to any other.

I've thought about not tagging for the rendering (and name finder is a 
kind of renderer), but there isn't a simple algorithmic solution. While 
it might be possible to do some analysis of connections to try to 
determine when two things are part of the same, this is a very expensive 
calculation in what is already a slow process, which makes practicality 
difficult, though not impossible; but in the case of indicating the 
preferred branch, I think this is a matter of judgement and can't be 
done algorithmically from the information that's already there (I could 
do some guesses based on length of number of nodes perhaps, but it would 
always be heuristic). Doing that might be useful anyway, but I don't 
think it will provide a perfect solution in all cases.

Thoughts?

David