[mkgmap-dev] RFC: naming unnamed roads

Thu Apr 30 14:14:58 BST 2015

Gerd Petermann <gpetermann_muenchen at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150430/52fd6253/attachment.sig>