Author: lonvia
[Added to the original trac issue at 9.56am, Saturday, 10th August 2013]

Addresses don't take into account importance, it is only computed based on distance and the kind of geometry. Boundary relations always win over place nodes because they are more precise.

You should be able to solve this particular one by adding a town boundary relation for Lowestoft.

Author: Pink Duck
[Added to the original trac issue at 6.13pm, Sunday, 11th August 2013]

The difficulty is that there's no publicly available definition for the extent of Lowestoft or its suburbs. What could be said though is that the average town has a radius of more than 700 metres, and thus the street in question could be presumed to belong to it.

Author: Pink Duck
[Added to the original trac issue at 7.01am, Sunday, 18th August 2013]

In thinking about it, the more specific issue here is that Nominatim returned a place=suburb node in preference to a place=town node, even though place=town was considerably nearer. Towns and suburbs typically work with a town centre area and suburbs situated further out. So if the town node is nearest then the street/address is probably not in a suburb.

As a district area and town node appear to be considered the same level, if a place=town node is nearer than a place=suburb then it would give a better result to pick the town over (or in addition to) the district.

Author: lonvia
[Added to the original trac issue at 8.23pm, Sunday, 18th August 2013]

The place=suburb node had nothing to do with that. Suburbs are on a level below towns, so they are evaluated independently.

I see you've fixed the issue by adding a rough town boundary, so closing this issue.

Author: Pink Duck
[Added to the original trac issue at 8.57pm, Sunday, 18th August 2013]

While I worked around this particular address, it would be better if Nominatim simply dropped the suburb in preference to the town if the town is nearer for all other cases.