<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 Miike,<br><br>sounds great! Reg. mp-processing: <br>Not sure what you plan to do here. Maybe that is not so easy, keep in mind that we have<br>the area_size() style function, so you probably have to calculate at least the outer shape before <br>you can check if the style is creating a map object.<br><br>Gerd<br><br><br><div><hr id="stopSpelling">From: mike@tvage.co.uk<br>To: mkgmap-dev@lists.mkgmap.org.uk<br>Date: Fri, 9 Jan 2015 00:20:56 +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:#0563C1;
text-decoration:underline;
}
.ExternalClass span.ecxMsoHyperlinkFollowed {
color:#954F72;
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>/<span class="ecxSpellE">WanMil</span>, I now have a mechanism working that has no performance overhead. I have derived a new class from Node and have moved the evaluation of the location to when <span class="ecxSpellE">getLocation</span> is first called in the new class. I have also improved the algorithm by progressively using bigger bitmaps if a small one doesn’t produce a suitable result. I’m now looking at doing the same for multi-polygons before putting together a patch. I should have something for you to try shortly.</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;">Regards,</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> 08 January 2015 20:23<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><p class="ecxMsoNormal" style=""><span style="font-family:"Calibri",sans-serif;">Hi WanMil,<br><br>yes, I had something like this in mind.<br>StyledConverter could call the POIGenerator<br>for each polygon. The POIGenerator <br>creates a dummy node, opies the tags, adds the <br>mkgmap:area2poi=true tag and <br>checks if the style produces a map element.<br>If yes, it calculates the coords<br>and returns the node which is than passed to addNode.<br><br>Anyhow, this change is only useful when performance<br>is a problem. I once had a similar idea for mp-processing.<br><br>Gerd</span></p><div><p class="ecxMsoNormal"><span style="font-family:"Calibri",sans-serif;">> Date: Thu, 8 Jan 2015 20:55:46 +0100<br>> From: <a href="mailto:wmgcnfg@web.de">wmgcnfg@web.de</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 Gerd,<br><span class="ecxGramE">> <br>></span> I think there are many drawbacks to move the POI generation into the <br>> style code. At least it will complicate the style code.<br>> <br>> Maybe it is better to implement your idea directly in the POIGeneratorHook.<br>> If it has access to the point style it could check itself if the polygon <br>> will (probably) create a POI. Maybe it could first test if there is any <br>> overlap of the polygon tags with the tags used in the points file. Then <br>> it could pass an artifical POI through the points style and check if a <br>> POI is created (finally rules might be disabled to speed up the <br>> processing).<br>> The hook might also decide how to proceed dependent on the complexity of <br>> the polygon.<br>> <br>> <br>> By the way: Did you think of having different methods depending on the <br>> use case? So one getCofG() for POI placement, one getHouseNumberPoint() <br>> for housenumber processing etc. It sounds like it is hard to find one <br>> algorithm that fits all.<br>> <br>> WanMil<br>> <br>> > 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<br>> > 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>> > ------------------------------------------------------------------------<br>> > From: <a href="mailto:mike@tvage.co.uk">mike@tvage.co.uk</a><br>> > To: <a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>> > Date: Wed, 7 Jan 2015 09:29:51 +0000<br>> > Subject: Re: [mkgmap-dev] small issue with <span class="ecxGramE">Way.getCofG(</span>)<br>> ><br>> > HI Gerd, the method I’ve used won’t work if the polygon is thinner than<br>> > the resolution of the bitmap. I hadn’t considered that it might be used<br>> > on rivers; my main testing has been on car parks, which although they<br>> > may be irregularly shaped are not normally very long and very thin (I<br>> > handle river names from the underlying lines). There are two possible<br>> > problems that could occur – if a polygon is thin enough that it renders<br>> > in the bitmap as a line that is nowhere wider than 2 pixels the POI<br>> > could be placed just outside the polygon. I haven’t checked what<br>> > fillPolygon does if the points have no volume and form a line. If this<br>> > renders nothing, then the algo will just return the centre point, which<br>> > could be nowhere near the polygon. A simple solution to the first<br>> > problem would be to examine the biggestSquaredDistanceToBlack figure<br>> > before returning the coordinate and if the value is 1, repeat the<br>> > operation on a small area around the point to get a better accuracy.<br>> > I’ll look into that. For the second problem I’ll add an error message,<br>> > so we can determine if it actually occurs (biggestSquaredDistanceToBlack<br>> > is 0). I’ve also thought that having drawn the bitmap, it might be more<br>> > efficient to then copy its contents out into an array so that finding<br>> > the distances from pixels inside the polygon to those outside become<br>> > simple array lookups instead of graphics function calls. I’ll look into<br>> > that as well.<br>> ><br>> > Cheers,<br>> ><br>> > Mike<br>> ><br>> > *From:*<span class="ecxSpellE">Gerd</span> <span class="ecxSpellE">Petermann</span> [<a href="mailto:gpetermann_muenchen@hotmail.com">mailto:gpetermann_muenchen@hotmail.com</a>]<br>> > *Sent:* 07 January 2015 06:55<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>> ><br>> > 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<br>> > 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<br>> > 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<br>> > polygon,<br>> > see e.g. way 178708143.<br>> ><br>> > If you like, please try to find a better compromise, I like to fix a<br>> > problem in<br>> > splitter first.<br>> > I also did not yet look at the effect on the house number code, as there<br>> > are many<br>> > more small open problems, but I think it should be easy to sort that out.<br>> ><br>> > Gerd<br>> ><br>> >> Date: Tue, 6 Jan 2015 13:23:57 -0700<br>> >> From:gpetermann_muenchen@hotmail.com <<a href="mailto:gpetermann_muenchen@hotmail.com">mailto:gpetermann_muenchen@hotmail.com</a>><br>> >> To:mkgmap-dev@lists.mkgmap.org.uk <<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mailto:mkgmap-dev@lists.mkgmap.org.uk</a>><br>> >> Subject: Re: [mkgmap-dev] small issue <span class="ecxGramE">withWay.getCofG(</span>)<br>> >><br>> >> Hi Mike,<br>> >><br>> >> 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>> >> ><br>> >> > Gerd<br>> >> ><br>> >> ><br>> >> > From:<br>> >><br>> >> ><a href="mailto:mike@.co">mike@.co</a> <<a href="mailto:mike@.co">mailto:mike@.co</a>><br>> >><br>> >> > To:<br>> >><br>> >> ><a href="mailto:mkgmap-dev@.org">mkgmap-dev@.org</a> <<a href="mailto:mkgmap-dev@.org">mailto:mkgmap-dev@.org</a>><br>> >><br>> >> > Date: Tue, 6 Jan 2015 14:56:30 +0000<br>> >> > Subject: Re: [mkgmap-dev] small issue <span class="ecxGramE">withWay.getCofG(</span>)<br>> >> ><br>> >> > 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>> >> ><br>> >> ><br>> >> > Regards,<br>> >> > Mike<br>> >> ><br>> >> > _______________________________________________<br>> >> > mkgmap-dev mailing list<br>> >><br>> >> > <a href="mailto:mkgmap-dev@.org">mkgmap-dev@.org</a> <<a href="mailto:mkgmap-dev@.org">mailto:mkgmap-dev@.org</a>><br>> >><br>> >> > <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>> >><br>> >> > <a href="mailto:mkgmap-dev@.org">mkgmap-dev@.org</a> <<a href="mailto:mkgmap-dev@.org">mailto:mkgmap-dev@.org</a>><br>> >><br>> >> > <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:http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5829247.html<br>> >> Sent from theMkgmap Development mailing list archive at Nabble.com.<br>> >> _______________________________________________<br>> >>mkgmap-dev mailing list<br>> >><a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a> <<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mailto: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><br>> ><br>> ><br>> > _______________________________________________ mkgmap-dev 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><br>> ><br>> ><br>> > _______________________________________________<br>> > mkgmap-dev 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><br>> ><br>> <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><br>_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</div> </div></body>
</html>