logo separator

[mkgmap-dev] Missing addr:place addresses

From Gerd Petermann gpetermann_muenchen at hotmail.com on Mon Dec 3 05:58:02 GMT 2018

Hi all,

this is for sure confusing. I think the problem is in the data flow.
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.

The merging (step 4) should probably be moved to the end of this chain and the housenumber processing should be able to split
a way when it cannot add enough labels or maybe add a "virtual" service road where needed. Such a virtual road would have a zero length,
zero road class and speed. I have to try how that would influence routing. Same with splitting. Both methods may make the road less attractive.


Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Greg Troxel <gdt at lexort.com>
Gesendet: Montag, 3. Dezember 2018 02:34
An: Lorenzo Mastrogiacomi
Cc: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Missing addr:place addresses

Lorenzo Mastrogiacomi <lomastrolo at gmail.com> writes:

> If I understand correctly I would say yes.
> unclassified roads should be tagged with name=* in osm if they have a
> name and should not take names from nearby roads.

I am really not following what's going on.

Most unclassified roads will have a name and some might not.

Some service roads (and tracks) will have names and most will not.

Addresses on building/nodes will have a variety of address components.
Typically, an address with a given addr:street will be located
reasonably close to some highway way with that same name.  But not
necessarily; the world is not designed by computer scientists :-)

I"m not really clear on addr:place; that sounds like a name from the
settlment hierarchy rather than the administrative hierarchy, and which
is used in addressing will depend on local customs.

I think this question is about putting address ranges on named highway
ways, because the garmin format doesn't represent individual addresses.
I can certainly see merging ways that are the same in tags that mkgmap
considers important (ignoring width changes, etc.).  But I don't
understand merging ways with names and ways without names.

A further complexity is address points far from the road in question,
and perhaps closer to some other road (e.g. a 1 km driveway).  There, I
could see a process of figuring out that the address point and the named
way are related by the service road and thus the address point should
perhaps be considered to be on the named way where the service road

I admit to never having taken the time to make addressing work in my
garmin maps so far; I mostly use them for hiking and I use OSMAnd for
car navigation.

mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk

More information about the mkgmap-dev mailing list