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
Gerd Petermann <gpetermann_muenchen@hotmail.com> writes:
I see some cases where the automatic naming of "service roads" causes problems. Maybe you can help me to find better heuristics.
I don't quite follow how this is all about naming. I'm a bit disconnected from the garmin format issues, but have been thinking about routing/addressing as I use both mkgmap maps and OsmAnd. Stepping back from Garmin format issues, there are multiple separate issues: 1) the OSM data should have an object with address annotation that is actually where one should go (house, entrance, etc.) 2) address search should locate this OSM object 3) routing then needs to use ways, whether or not they have names that match, to route to the object
The target is to produce data that enables Garmin software to find an address / a house when OSM data shows an address.
Agreed. So my point 1 above is out of scope and uncontroversial.
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
True, and this is not a bug; it's how the world is. In the US, there's a clear dividing line between things that are legally roads ("public way", and "private way", where you need a license) and things that look like roads but are not (driveways, service roads, where arguably you need permission or non-objection from the owner instead). I believe this distinction corresponds loosely to the UK "public right of way" notion. Around me, there are many houses which are pretty far back from the road (200m is not odd), and there are driveways. Some of those are in OSM some aren't, but they are in theory mappable.
2) unnamed cylceways / footways are between the house and the named road
In the US, only car roads tend to get real names. Major cycleways do get names but that's more like a proper name for the cycleway than an address.
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.
This is a data bug and should be addressed by QA tools in OSM. I suggest ignoring it in mkgmap. Or if you don't, implement a fuzzy match and output a warning, and be very clear that this is a workaroudn for data bugs.
4) a named road is close to one side of the house but an unnamed track/footway is closer on an other side.
This has multiple subcases. The named road could be the matching one, or there could be a matching one on the side with the track (which might connect the house to the named road).
I think 1) is clear, we want that Garmin address search points us to a point on the service road.
What we really want is to select the coordinates of the object with the address as the goto point.
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.
Again I think we want to find the address.
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.
My opinion (counts for very little; you are the one doing the work) is that this situation is so difficult that it's best to ignore data errors.
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 .
This is hard, but the reason it is hard is that you want to be routed to the place on a road that is the actual entrance to the object with the address, and this may or may not be mapped adequately. If routing to the coordinates of the object with the address annotation produces a bad result (because there's a track in the back 10m from the house to another road, and there's 15m in the front to the right road, then IMHO this is bad map data, and there should be a driveway in the front. But, one can say that if one is supposed to park near the road and walk the 15m, the map is not so wrong. Then we are running into either a bug in the schema where we need to express that the location one should park at for an address is different, or always have car routing be an implied car and transition to foot routing All that said, I continue to have trouble following the situation, which is perhaps about me. It would probably be helpful to have a wiki page or a text design document that starts with goals and constraints and explains the plan. My own leaning, with fuzzy understanding, is that when mkgmap runs, any address point that is not "clearly near" the matching way should get an invisible non-routable way to hang the address on, so that we achieve "route to the object with the address". Then the hard part is "clearly near". Here, I would ignore footways and anything else not routable by cars (I don't think we can make an address map that is multi-modal, given garmin issues). If the matching name way is the closest way, the address can just be logically moved to that way. For extra credit, it can be moved along ways following routing. The real reason this is hard is because OSM's addressing data model is to label the building, and the car nav model is to label the address on the road. I wonder how badly complexity/size blows up if there is a address-only invisible way per address, or if those are only added when there's not an obvious match.
On Thu, Apr 30, 2015 at 09:14:58AM -0400, Greg Troxel wrote:
2) unnamed cylceways / footways are between the house and the named road
In the US, only car roads tend to get real names. Major cycleways do get names but that's more like a proper name for the cycleway than an address.
It is mostly the same in Finland, and I would guess in most part of Europe. The general assumption would seem to be that the street names attached to house addresses belong to roads that are reachable by car, or that each residence is reachable by car. Maybe in some rare case there is some access restriction on the road associated with the address, such as access=destination. There could be named cycleways or footways between the road and the address node, but no named public roads with a different name, unless there is an error in the map data.
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.
This is a data bug and should be addressed by QA tools in OSM. I suggest ignoring it in mkgmap. Or if you don't, implement a fuzzy match and output a warning, and be very clear that this is a workaroudn for data bugs.
If there is a fuzzy match, it should be attempted only if a full match fails. There could be similarly named ways near to each other, such as Mäyräkuja and Myyräkuja (only one letter difference). Marko
Marko Mäkelä <marko.makela@iki.fi> writes:
The general assumption would seem to be that the street names attached to house addresses belong to roads that are reachable by car, or that each residence is reachable by car. Maybe in some rare case there is some access restriction on the road associated with the address, such as access=destination. There could be named cycleways or footways between the road and the address node, but no named public roads with a different name, unless there is an error in the map data.
That's an interesting point. In the US, around me, there really aren't such assumptions. Instead, a lot (area of land that can be bought and sold as a unit) has an address, generally taken from a public or private way that borders the lot. Some lots don't really have addresses that are useful, if they aren't near roads. Then a building on the lot, certainly if there's only one, inherits the address of the lot. ANd if there's going to be a building, then the lot needs to have a proper address (for emergency services purposes) and one will get assigned. So it definitely tends to work out 99.99% of the time that a building's address is near the named road, and that one drives to that road to access the building, but it's not strictly by design. In confusing cases new addresses tend to get made up, usually by granting the (new) access road a proper legal name, so it that sense what you said describes how we do it. That's a long way of saying that it's messy and that general rules don't always hold (in mass.us; not saying that applies to .fi). This is quite separate from access. There are addresses on military cases, and very often in residential complexes with gates that you need a code/etc. to get through. So it's not just access=destination but access=private, and yet they are real addresses on named roads inside the gate.
Hi all, thanks for the input. Please don't mix up the routing part and the address search. I don't want to discuss here if you are allowed to get to that point, but yes, I'd prefer that address search returns a point on a public road if that point is close. We recently found out that we can use address search in Garmin software without even storing any routing information in the map, because all address information is stored in the NET sub file, while routing requires the NOD sub file. The big limit in the Garmin format is that address data is stored with roads. In other words, the result of Garmins address search is a point next to a road, and can only be next to a road, this also means that it requires quite a lot of bytes to store a single road for each address which would allow very precise address search (presuming that the OSM data is precise and not itself an approximation like the addr:interpolation ways). I think I have made up my mind now how to handle the special cases. I think mkgmap should only use the closest road if that is much closer than the road with the matching name. I have to find out how to calculate what "much closer" is ;-) Gerd From: gdt@ir.bbn.com To: marko.makela@iki.fi Date: Thu, 30 Apr 2015 09:57:04 -0400 CC: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] RFC: naming unnamed roads Marko Mäkelä <marko.makela@iki.fi> writes:
The general assumption would seem to be that the street names attached to house addresses belong to roads that are reachable by car, or that each residence is reachable by car. Maybe in some rare case there is some access restriction on the road associated with the address, such as access=destination. There could be named cycleways or footways between the road and the address node, but no named public roads with a different name, unless there is an error in the map data.
That's an interesting point. In the US, around me, there really aren't such assumptions. Instead, a lot (area of land that can be bought and sold as a unit) has an address, generally taken from a public or private way that borders the lot. Some lots don't really have addresses that are useful, if they aren't near roads. Then a building on the lot, certainly if there's only one, inherits the address of the lot. ANd if there's going to be a building, then the lot needs to have a proper address (for emergency services purposes) and one will get assigned. So it definitely tends to work out 99.99% of the time that a building's address is near the named road, and that one drives to that road to access the building, but it's not strictly by design. In confusing cases new addresses tend to get made up, usually by granting the (new) access road a proper legal name, so it that sense what you said describes how we do it. That's a long way of saying that it's messy and that general rules don't always hold (in mass.us; not saying that applies to .fi). This is quite separate from access. There are addresses on military cases, and very often in residential complexes with gates that you need a code/etc. to get through. So it's not just access=destination but access=private, and yet they are real addresses on named roads inside the gate. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Thu, Apr 30, 2015 at 09:57:04AM -0400, Greg Troxel wrote:
The general assumption would seem to be that the street names attached to house addresses belong to roads that are reachable by car, or that each residence is reachable by car. Maybe in some rare case there is some access restriction on the road associated with the address, such as access=destination. There could be named cycleways or footways between the road and the address node, but no named public roads with a different name, unless there is an error in the map data.
That's an interesting point. In the US, around me, there really aren't such assumptions. Instead, a lot (area of land that can be bought and sold as a unit) has an address, generally taken from a public or private way that borders the lot.
I see. I have some knowledge of the administrative system of properties in Finland. I do not think that street names play any role there. A property may have been assigned an arbitrary name by its owner, but it always has a registration number that uniquely identifies the lot. If the lot is split, I guess that all parts of it will get a longer registration number (adding some suffix to the original number). Nowadays, the fully qualified registration number should start with the NUTS (Nomenclature of Territorial Units for Statistics) prefix of the municipality. Streets may be renamed or renumbered (seldom, but possible when lots of properties have been split and new houses built, for example). This would not affect the registration numbers of the properties. BTW, I don't think that the registration numbers will or should be put to the OSM database. They are only relevant when buying or selling properties. It should suffice to have the administrative boundaries of the suburbs or villages. In Finland, when the same street goes through multiple municipalities, it usually changes names at the border. This is unlike what I saw in the US: El Camino Real in California would be called that for the whole way, and you would have to pay attention when crossing borders, because there could be multiple identical house numbers, maybe some tens of miles apart. Sure, in every country, you will have common street names such as "Main Street" or equivalent in every town, but those would typically not be part of a major route. However, this should not be a problem for the Garmin format. El Camino Real would be split to sections at municipality borders, and each section would be assigned its own house number data.
That's a long way of saying that it's messy and that general rules don't always hold (in mass.us; not saying that applies to .fi).
Right. We need to identify the least common denominator, and also need to find ways to circumvent some limitations of the Garmin format. I think that the simpler, the better, as long as we are not introducing too many artifacts, such as moving a housenumber to a street far away.
This is quite separate from access. There are addresses on military cases, and very often in residential complexes with gates that you need a code/etc. to get through. So it's not just access=destination but access=private, and yet they are real addresses on named roads inside the gate.
Oh, yes. I would not worry too much about access. From routing point of view, there should be not much difference between access=private and access=destination. The routing engine can tell you how to get to a location. It cannot know if you are really allowed to go there. All that matters is that it should not suggest a restricted road as a shortcut for some other location that is reachable via other roads. Marko
Marko Mäkelä <marko.makela@iki.fi> writes:
That's an interesting point. In the US, around me, there really aren't such assumptions. Instead, a lot (area of land that can be bought and sold as a unit) has an address, generally taken from a public or private way that borders the lot.
I see. I have some knowledge of the administrative system of properties in Finland. I do not think that street names play any role there. A property may have been assigned an arbitrary name by its owner, but it always has a registration number that uniquely identifies the lot. If the lot is split, I guess that all parts of it will get a longer registration number (adding some suffix to the original number). Nowadays, the fully qualified registration number should start with the NUTS (Nomenclature of Territorial Units for Statistics) prefix of the municipality.
Streets may be renamed or renumbered (seldom, but possible when lots of properties have been split and new houses built, for example). This would not affect the registration numbers of the properties. BTW, I don't think that the registration numbers will or should be put to the OSM database. They are only relevant when buying or selling properties. It should suffice to have the administrative boundaries of the suburbs or villages.
We also have parcel numbers which are more or less similar (town, zoning map sheet name, parcel number, and suffix on subdivision). We also do not use them in addressing and generally no one has an idea unless they are dealing with applications under zoning rules. So I think until we have an example of addresses being based on these, mkgmap can ignore them.
In Finland, when the same street goes through multiple municipalities, it usually changes names at the border. This is unlike what I saw in the US: El Camino Real in California would be called that for the whole way, and you would have to pay attention when crossing borders, because there could be multiple identical house numbers, maybe some tens of miles apart. Sure, in every country, you will have common street names such as "Main Street" or equivalent in every town, but those would typically not be part of a major route. However, this should not be a problem for the Garmin format. El Camino Real would be split to sections at municipality borders, and each section would be assigned its own house number data.
The US is highly variable and both styles exist. Around me, road names often change at the town border, and if they don't the addresses usually reset. For extra confusion, roads are named for the town they go to, so you can be on Lexington Road in Waltham and after crossing be on Waltham Road in Lexington. Agreed that this doesn't cause mkgmap/garmin problems.
On Tue, May 05, 2015 at 08:17:26PM -0400, Greg Troxel wrote:
The US is highly variable and both styles exist. Around me, road names often change at the town border, and if they don't the addresses usually reset.
Right. The resetting of the house numbers while keeping the road name was the confusing part for me (as a tourist who does not know or notice the town borders, in areas where the towns have grown together).
For extra confusion, roads are named for the town they go to, so you can be on Lexington Road in Waltham and after crossing be on Waltham Road in Lexington.
That sounds like standard practice in Europe too.
Agreed that this doesn't cause mkgmap/garmin problems.
Yes. Nevertheless, it is good to know how things are done in different parts of the world, to avoid choosing a bad design. Marko
Hi, On Thu, Apr 30, Gerd Petermann wrote:
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. [...] Any ideas ?
I would do the following: 1) is clear, use the service road or footway. 2) if they are not 1), ignore them and put the address on the named road. Because, most of the time in reality, there are connections between the named road and the footway, but the mapper didn't add them. Since the footway is somehow connected with the named road, you can end up with a 4.5km detour. I had that on Sunday, when I used a POI as destination for routing ... If the ways are not connected somewhere, you have routing islands and you will get a routing error, which is as worse. 3) I would ignore the house and write it as error in the log files, so that somebody can fix the wrong street name. 4) Since you calculates the distance between the house and the roads, you could calculate the distance between the two points of the roads, too. If this is larger as the distances between the house and both roads, use the named road. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)
participants (4)
-
Gerd Petermann -
Greg Troxel -
Marko Mäkelä -
Thorsten Kukuk