<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 Mike,<br><br>reg. POI for polygons like rivers etc:<br><br>The current algo calculates a POI for each polygon before any style rule <br>is applied. <br>If the calculation of the Coord takes a lot of time, and many of the POI <br>are later dropped in the points rules, maybe it is possible<br>to create a dummy object first, pass it through the style rules, check if it <br>produces a map object, and calculate the exact position only for those.<br>I think we would have to change/remove the POIGeneratorHook and<br>call it "on the fly", but I don't see any big problem with that.<br><br>Gerd<br><br><div><hr id="stopSpelling">From: mike@tvage.co.uk<br>To: mkgmap-dev@lists.mkgmap.org.uk<br>Date: Wed, 7 Jan 2015 09:29:51 +0000<br>Subject: Re: [mkgmap-dev] small issue with Way.getCofG()<br><br><style><!--
.ExternalClass p.ecxMsoNormal, .ExternalClass li.ecxMsoNormal, .ExternalClass div.ecxMsoNormal {
font-size:12.0pt;
font-family:"Times New Roman",serif;
}
.ExternalClass a:link, .ExternalClass span.ecxMsoHyperlink {
color:blue;
text-decoration:underline;
}
.ExternalClass span.ecxMsoHyperlinkFollowed {
color:purple;
text-decoration:underline;
}
.ExternalClass p {
font-size:12.0pt;
font-family:"Times New Roman",serif;
}
.ExternalClass span.ecxEmailStyle18 {
font-family:"Calibri",sans-serif;
color:#1F497D;
}
.ExternalClass span.ecxSpellE {
}
.ExternalClass span.ecxGramE {
}
.ExternalClass .ecxMsoChpDefault {
font-size:10.0pt;
}
.ExternalClass div.ecxWordSection1 {
}
--></style><div class="ecxWordSection1"><p class="ecxMsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;">HI <span class="ecxSpellE">Gerd</span>, the method I’ve used won’t work if the polygon is thinner than the resolution of the bitmap. I hadn’t considered that it might be used on rivers; my main testing has been on car parks, which although they may be irregularly shaped are not normally very long and very thin (I handle river names from the underlying lines). There are two possible problems that could occur – if a polygon is thin enough that it renders in the bitmap as a line that is nowhere wider than 2 pixels the POI could be placed just outside the polygon. I haven’t checked what <span class="ecxSpellE">fillPolygon</span> does if the points have no volume and form a line. If this renders nothing, then the <span class="ecxSpellE">algo</span> will just return the centre point, which could be nowhere near the polygon. A simple solution to the first problem would be to examine the <span class="ecxSpellE">biggestSquaredDistanceToBlack</span> figure before returning the coordinate and if the value is 1, repeat the operation on a small area around the point to get a better accuracy. I’ll look into that. For the second problem I’ll add an error message, so we can determine if it actually occurs (<span class="ecxSpellE">biggestSquaredDistanceToBlack</span> is 0). I’ve also thought that having drawn the bitmap, it might be more efficient to then copy its contents out into an array so that finding the distances from pixels inside the polygon to those outside become simple array lookups instead of graphics function calls. I’ll look into that as well.</span></p><p class="ecxMsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;"> </span></p><p class="ecxMsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;">Cheers,</span></p><p class="ecxMsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;">Mike</span></p><p class="ecxMsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;"> </span></p><div><div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm;"><p class="ecxMsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;" lang="EN-US">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;" lang="EN-US"> Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] <br><b>Sent:</b> 07 January 2015 06:55<br><b>To:</b> mkgmap-dev@lists.mkgmap.org.uk<br><b>Subject:</b> Re: [mkgmap-dev] small issue with Way.getCofG()</span></p></div></div><p class="ecxMsoNormal"> </p><div><div><p class="ecxMsoNormal" style=""><span style="">Hi Mike,<br><br>on my PC the performance of your algo is quite good. <br>Attached is a patch that contains your patch as well as my quick implementation<br>of the algo described here:<br><a href="http://arxiv.org/ftp/arxiv/papers/1212/1212.3193.pdf" target="_blank">http://arxiv.org/ftp/arxiv/papers/1212/1212.3193.pdf</a><br><br>The patch tests only performance, it computes the center with the 3 different algos,<br>I've commented the part that prints times and GPX data for debug purposes.<br><br>I noticed that the results between both algos are very different, I did not<br>yet try to find out which one is better, but mine is much slower on my PC.<br>I also noticed that your algo doesn't always calculate a point in the polygon,<br>see e.g. way 178708143.<br><br>If you like, please try to find a better compromise, I like to fix a problem in<br>splitter first.<br>I also did not yet look at the effect on the house number code, as there are many<br>more small open problems, but I think it should be easy to sort that out.<br><br>Gerd<br style=""><br style=""></span></p><div><p class="ecxMsoNormal"><span style="">> Date: Tue, 6 Jan 2015 13:23:57 -0700<br>> From: <a href="mailto:gpetermann_muenchen@hotmail.com">gpetermann_muenchen@hotmail.com</a><br>> To: <a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>> Subject: Re: [mkgmap-dev] small issue with <span class="ecxGramE">Way.getCofG(</span>)<br><span class="ecxGramE">> <br>></span> Hi Mike,<br><span class="ecxGramE">> <br>></span> I like the idea, but it seems to be slow.<br>> Is it possible that your algo suffers when no fast graphics card is<br>> available?<br>> On my netbook the performance is very poor, did not yet<br>> try on the PC, but that also has no high speed graphics.<br>> <br>> Gerd<br>> <br>> <br>> GerdP wrote<br>> > Hi Mike,<br>> > <br>> > 50% sounds better than my algo, but still quite a lot. I'll have a closer<br>> > look at your<br>> > algo later.<br>> > Please note that your change has a side effect on the house number<br>> > generator.<br>> > Up to now this doesn't contain a filter for generated POI, so each polygon<br>> > with a house number is processed twice, once because of the POI, once<br>> > because the Generator uses Way.getCofG(). If both have different positions<br>> > this might have a negative impact.<br>> <span class="ecxGramE">> <br>></span> > Gerd<br>> <span class="ecxGramE">> <br>></span> > <br>> > From: <br>> <br>> > <a href="mailto:mike@.co">mike@.co</a><br><span class="ecxGramE">> <br>></span> > To: <br>> <br>> > <a href="mailto:mkgmap-dev@.org">mkgmap-dev@.org</a><br><span class="ecxGramE">> <br>></span> > Date: Tue, 6 Jan 2015 14:56:30 +0000<br>> > Subject: Re: [mkgmap-dev] small issue with <span class="ecxGramE">Way.getCofG(</span>)<br>> <span class="ecxGramE">> <br>></span> > I have a working solution for ensuring that the created point is placed<br>> > within the polygon when using --add-pois-to-areas, based on drawing the<br>> > polygon on to a small monochrome bitmap and then looking for the point<br>> > that<br>> > is furthest from the surrounding area. I used a 9x9 bitmap for polygons<br>> > having a small number of points and 15x15 for longer polygons. There is<br>> > however a performance penalty. My standard map takes about 1 hour 20<br>> > minutes; using this algorithm the time increases by about 50% to about 2<br>> > hours. I am not currently able to commit changes to SVN (perhaps someone<br>> > can<br>> > help out with that) but I have attached the code changes. I suggest that<br>> > due<br>> > to the performance penalty, if we adopt this, then the --add-pois-to-areas<br>> > option be extended to be --add-pois-to-areas[=centre|optimised] or<br>> > something<br>> > similar, with the default being centre and functioning as now and the<br>> > optimised option invoking the new code. Please try out the suggested<br>> > change.<br>> > Note I don't expect this to work properly where a polygon is formed from a<br>> > multiploygon relation, but the code could quite easily be adapted for this<br>> > circumstance.<br>> <span class="ecxGramE">> <br>></span> > <br>> > Regards,<br>> > Mike<br>> > <br>> > _______________________________________________<br>> > mkgmap-dev mailing list<br><span class="ecxGramE">> <br>></span> > <a href="mailto:mkgmap-dev@.org">mkgmap-dev@.org</a><br><span class="ecxGramE">> <br>></span> > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a> <br>> > _______________________________________________<br>> > mkgmap-dev mailing list<br><span class="ecxGramE">> <br>></span> > <a href="mailto:mkgmap-dev@.org">mkgmap-dev@.org</a><br><span class="ecxGramE">> <br>></span> > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>> <br>> <br>> <br>> <br>> <br>> --<br>> View this message in context: <a href="http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5829247.html" target="_blank">http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5829247.html</a><br>> Sent from the <span class="ecxSpellE">Mkgmap</span> Development mailing list archive at Nabble.com.<br>> _______________________________________________<br>> <span class="ecxGramE">mkgmap-dev</span> mailing list<br>> <a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a></span></p></div></div></div></div><br>_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</div> </div></body>
</html>