On Wed, Jan 25, WanMil wrote:
On Wed, Jan 25, Gerd Petermann wrote:
Yes, but that shouldn't matter in the LocationHook. The LocationHook just adds tags like mkgmap:postal_code to the nodes that form such a building, and I guess that persons who are interested in postal codes will use coresponding lines in their styles to analyse mkgmnap:postal_code AND e.g. addr:postcode. Right?
I think yes ;) At least most styles have:
mkgmap:postal_code!=*& mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postcode}' } mkgmap:postal_code!=*& addr:postcode=* { set mkgmap:postal_code='${addr:postcode}' }
The only question is: should we assume mkgmap:postcode is more correct than addr:postcode? I think the order should be switched in the default style.
Do you have an example where this would improve the postal code assignment? From my point of view it is better to believe the postal code information from the boundaries. One simple reason for this:
A postal_code relation catches all nodes and ways and it has to be tagged once. In constrast you have N elements all tagged individual. The chances are much higher that there are one or more typo errors in the elements than there is one in the relation.
Let's say it this way: I trust the elements much more than the postal_code boundaries in my region. There are two reasons: - in my region nearly all postal_code boundaries are tagged with a fixme: boundaries are guessed and needs to be confirmed. I don't know if the fixme tags are still valid or not. But at least in the office, which is on a postal_code border, they don't really fit with the official addresses. - every second week somebody breaks several postcal_codes, because they split/merge ways and don't care about the relations using this ways. So in my opinion address nodes are more reliable if they exist. While I'm strictly against removing the postcal_codes from the precompiled boundaries: Far too many addresses are missing or incomplete, and here we can use the postal_code from the boundaries if they are currently not broken. But in the end: I don't care much what is in the default style, since everybody can modify his own style how it fits best for him. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)