[mkgmap-dev] Missing addr:place addressesFrom Greg Troxel gdt at lexort.com on Mon Dec 3 14:18:35 GMT 2018
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.
- Previous message: [mkgmap-dev] Missing addr:place addresses
- Next message: [mkgmap-dev] Missing addr:place addresses
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list