<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, 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<br><br><div>> Date: Thu, 8 Jan 2015 20:55:46 +0100<br>> From: wmgcnfg@web.de<br>> To: mkgmap-dev@lists.mkgmap.org.uk<br>> Subject: Re: [mkgmap-dev] small issue with Way.getCofG()<br>> <br>> Hi Gerd,<br>> <br>> 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: 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>> > 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:*Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com]<br>> > *Sent:* 07 January 2015 06:55<br>> > *To:* mkgmap-dev@lists.mkgmap.org.uk<br>> > *Subject:* Re: [mkgmap-dev] small issue with Way.getCofG()<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>> > http://arxiv.org/ftp/arxiv/papers/1212/1212.3193.pdf<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 <mailto:gpetermann_muenchen@hotmail.com><br>> >> To:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><br>> >> Subject: Re: [mkgmap-dev] small issue withWay.getCofG()<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>> >> >mike@.co <mailto:mike@.co><br>> >><br>> >> > To:<br>> >><br>> >> >mkgmap-dev@.org <mailto:mkgmap-dev@.org><br>> >><br>> >> > Date: Tue, 6 Jan 2015 14:56:30 +0000<br>> >> > Subject: Re: [mkgmap-dev] small issue withWay.getCofG()<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>> >> > mkgmap-dev@.org <mailto:mkgmap-dev@.org><br>> >><br>> >> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> >> > _______________________________________________<br>> >> > mkgmap-dev mailing list<br>> >><br>> >> > mkgmap-dev@.org <mailto:mkgmap-dev@.org><br>> >><br>> >> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<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>> >>mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><br>> >>http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<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>> ><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>