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