[mkgmap-dev] Missing addr:place addresses

Mon Dec 3 14:54:27 GMT 2018

Hi Greg,

the effect on routing would be the increased number of so called routing nodes.
When I change mkgmap to add zero length service roads those have to be connected to the road network,
else you get problems with routing. Such a connection is a routing node.
My experience is that Garmin prefers roads with fewer routing nodes.

Gerd

________________________________________
Von: Greg Troxel <gdt at lexort.com>
Gesendet: Montag, 3. Dezember 2018 15:18
An: Gerd Petermann
Cc: Lorenzo Mastrogiacomi; Development list for mkgmap
Betreff: Re: [mkgmap-dev] Missing addr:place addresses

Gerd Petermann <gpetermann_muenchen at hotmail.com> writes:

> this is for sure confusing. I think the problem is in the data flow.

thanks - I am starting to understand.

> Current implementation works like this:
> 1) Single OSM ways are passed to the style rules
> 2) The style can create 0, 1 or more routable lines (=roads) and 0 or more other lines for this single OSM way.
> 3) The next step is to fix "wrong angles" so that zig-zagging is reduced
> 4) Now ways that represent roads are merged when they have similar attributes
> 5) The ways representing roads are then converted to a different data structure called MapRoad.
> 6) Finally the housenumber code tries to add address information to those MapRoad instances. There are several concepts in OSM
> to represent adresses, the normal one is addr:housenumber + addr:street, another one is the combination
> of addr:housenumber + addr:place. The latter is typically used in rural areas where you have a
> few buildings with the same addr:place value. In reality, those buildings often have a service way but it is rarely mapped.
> If it is mapped mkgmap tries to add the address information to that service road. This also means that it has to add a label to an
> unnamed road, else address search would not work. Without a nearby service road it adds the address information to the next best road.
> If that road has a name that doesn't match the name given with addr:place mkgmap adds another label for the place name.
> The problem starts when such a "next best road" passes several places with different names since roads can only have 4 labels.

I would say that the basic problem is that the way garmin format
represents addresses does not match the way the world is, and does not
match the OSM data model.  Adding street names to streets that do not
have names seems to me to risk unintended confusion.

(Note that I live in an area where there is a legal requirement for
addresses to be housenumber/road-name, driven by both the post office
and emergency services response.  In Massachusettts, US, we are talking
about importing government address data, and one of the quality checks
on individiual addresses is "is there a road in OSM with that name,
which is nearby enough".  But that's the plan in our area, legally, and
I realize other places are different.)

Wtih addr:housenumber and addr:place, I would expect that often there is
no road with the same value as addr:place.   I would think that if you
talked to the local inhabitants they would say that this is correct.
Even if a place of "Fooville" had a "Fooville Road", it probably doesn't
match exactly.  (Around me, roads are often named for the town they go
to, but it's town "Concord" and road "Concord Road".)

Perhaps the Garmin data structure reflects the US notions of addresses
being #/road-name.

Overall, I think your idea of having road objects with some
not-really-there attributes (zero length, if it works), and putting the
addressing information on them is the right approach, in cases when
there is not an actual road with a missing name.  That lets the address
search use the data structure, even though there is in fact no road with
that name, and it seems to cause the least amount of confusion.
Probably searching for that name as a road name will turn up things, but
that may not be avoidable.

I would suggest that if the road is zero length, then there's no worry
about road class and speed; if it appears as a service road with a 20
km/hr speed limit for the 0m, then that doesn't seem harmful in terms of
misleading any human or machine data consumers.  But there might be a
way to not have the road turn in up road name search.  And, if the route
ends near the address, it probably doesn't matter if it includes the
0-length way, as long as the way is found in address search.

I hope this is helpful, and thanks for your work over many years.
Being able to get OSM data on my garmin units is part of what made me
start mapping.