Hi all, I see some cases where the automatic naming of "service roads" causes problems. Maybe you can help me to find better heuristics. The target is to produce data that enables Garmin software to find an address / a house when OSM data shows an address. Now, often houses have a tag addr:street=xyz, but the closest road(s) don't have the name xyz. This happens when 1) an unnamed service road or footway is connecting the house with a road named xyz 2) unnamed cylceways / footways are between the house and the named road 3) typos in the addr:street tag or the mkgmap:street tag prevent a clear match, e.g. the road is named "Alte Chausseestraße" and the houses have (probably wrong) "Alte Chaussestraße" (single e), or the addr:street tag is completely wrong, means, no street with a name like that is close. 4) a named road is close to one side of the house but an unnamed track/footway is closer on an other side. I think 1) is clear, we want that Garmin address search points us to a point on the service road. In case 2) I would prefer to find the named road, but it seems to cause no problems when mkgmap uses the closer way and gives it the name of the named road, at least as long as both roads are more or less parallel lines. Case 3) is a bit funny. The unnamed road will be used and address search will find the address as long as you type the (probably) wrong name. In trunk, these houses are ignored, which is sometimes better, sometimes not. Case 4) is causing real trouble. We don't want to be routed to the these roads, but up to now I found no rule(s) to distinguish them from 1) or 2) besides the tag mkgmap:numbers=false . Any ideas ? Gerd