<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>I've committed a fix for the link-poi-to-ways option. With r2867 the POI<br>of merged ways were ignored.<br>(An alternative to the mkgmap:way-poi-node-ids tag would be <br>a HashSet<Node> in class Way which is only initialised when used.<br>Maybe that would be clearer?)<br><br>I also tried to implement the solution that you suggested here:<br><a href="http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778414.html" target="_blank">http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778414.html</a><br>in the high-prec-branch.<br><br>It looked simpler, but it turned out that the code to save the original <br>positions of CoordPOI and later the restoring of the info was<br>much more complex than the treatment in the replace routine.<br><br>I think the only problem that can occur with the implementation in r2869<br>is when two CoordPOI are merged. This is very unlikely, and the corresponding<br>error is very small.<br><br>Gerd<br><br><div>> Date: Mon, 9 Dec 2013 19:59:33 +0100<br>> From: wmgcnfg@web.de<br>> To: mkgmap-dev@lists.mkgmap.org.uk<br>> Subject: [mkgmap-dev] Merge the mergeroads branch?<br>> <br>> I think the mergeroads branch is "functional complete". I want to know <br>> if you are happy with all changes?<br>> <br>> In such a case I would start to document the changes which need to be <br>> done before merging the changes to the trunk.<br>> <br>> A short overview of the changes:<br>> * Roads are merged which reduces the number of road entries by 7-25% <br>> using the default style. This results in slightly better routing <br>> calculation times and slightly smaller img file sizes.<br>> * The four labels to pois/lines/roads/polygons are no longer assigned <br>> automatically. They must be assigned using the 'name' and 'addlabel' <br>> function. This also means that ref tags are no longer used as labels <br>> automatically.<br>> * Access restrictions of roads are now defined by setting special <br>> mkgmap:** access tags (e.g. mkgmap:car, mkgmap:foot, mkgmap:bicycle etc.).<br>> * mkgmap:carpool does no longer automatically set all access <br>> restrictions. In the trunk mkgmap:carpool=yes/1/true lead to set all <br>> access restrictions to "no" except emergency, bus and carpool.<br>> * The road speed is no longer automatically calculated using the <br>> maxspeed tag. New style functions maxspeedkmh() and maxspeedmph() allow <br>> style developers to perform the same by setting the <br>> mkgmap:road-speed-class tag.<br>> * Styles can now have a <finalize> block. This block is executed for <br>> each element if an element style definition matches. The finalize block <br>> must contain actions only.<br>> <br>> There is no need to convert the "old" style files instantly when adding <br>> compatibility include files to the finalize block. Example for the lines <br>> file:<br>> <finalize><br>> include 'inc/compat_lines';<br>> <br>> Anyhow I strongly propose to use the new degree of freedom in assigning <br>> access restrictions etc. In case you are not convinced about the new <br>> features just open the compatibility includes and you will see that <br>> access handling in the trunk has some shortcomings.<br>> <br>> WanMil<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>