Hi WanMil, yes, not a good idea, see also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2015q2/023332.html I try to sovle the problem that I see elements with addr:housenumber which have all the mkgmap:adminlevel tags but they don't have the mkgmap:city tag. It seems that RuleSet.merge() doesn't merge the finalize rules. I think that's would be an error although I am not sure how a merge would work. Gerd
Date: Thu, 16 Apr 2015 10:09:49 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] change inc/address to be a standalone ?
Hi experts,
Hi Gerd,
I am not happy with the current code regarding address data.
My understanding so far: - we have the --bounds option to specify precompiled bounds - we have the LocationHook that is used to assign tags mkgmap:admin_level2 to. mkgmap:admin_level10 and mkgmap:postcode. - we have inc/address to which uses either the data from the LocationHook or that from the OSM element to set mkgmap:city, mkgmap:region etc. The file inc/address in the default style doesn't care about any other tags, means, the result doesn't depend on the exstence of a highway tag or whether the element is a node, way, or polygon.
I think we should change that. My proposal: Instead of inc/address we have a file address (on the same level like points, lines, etc) this file is evaluated before the rules in points/lines/polygons when it exists. Probably the class RuleFileReader should make sure that the files points/lines/polygons do not include another inc/address.
I think that's hard to realize. Other style implementors do not need to use the same name inc/address. It is also possible that the address rules are written in a mixed style file. So it's not easy to detect which include file contains address rules only.
What is the major problem you have? Is it that inc/address does not differ between nodes, ways and polygons? You might change that (function type() returns node, way, relation depending on its type).
The major advantage of an included address file is that other style implementors can easily use it as it is so it would be good if its usage is not weaved into the default style too much.
WanMil
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev