[mkgmap-dev] small issue with Way.getCofG()

Thu Jan 8 19:55:46 GMT 2015

Hi Gerd,

I think there are many drawbacks to move the POI generation into the 
style code. At least it will complicate the style code.

Maybe it is better to implement your idea directly in the POIGeneratorHook.
If it has access to the point style it could check itself if the polygon 
will (probably) create a POI. Maybe it could first test if there is any 
overlap of the polygon tags with the tags used in the points file. Then 
it could pass an artifical POI through the points style and check if a 
POI is created (finally rules might be disabled to speed up the 
processing).
The hook might also decide how to proceed dependent on the complexity of 
the polygon.

By the way: Did you think of having different methods depending on the 
use case? So one getCofG() for POI placement, one getHouseNumberPoint() 
for housenumber processing etc. It sounds like it is hard to find one 
algorithm that fits all.

WanMil

> Hi Mike,
>
> reg. POI for polygons like rivers etc:
>
> The current algo calculates a POI for each polygon before any style rule
> is applied.
> If the calculation of the Coord takes a lot of time, and many of the POI
> are later dropped in the points rules, maybe it is possible
> to create a dummy object first, pass it through the style rules, check
> if it
> produces a map object, and calculate the exact position only for those.
> I think we would have to change/remove the POIGeneratorHook and
> call it "on the fly", but I don't see any big problem with that.
>
> Gerd
>
> ------------------------------------------------------------------------
> From: mike at tvage.co.uk
> To: mkgmap-dev at lists.mkgmap.org.uk
> Date: Wed, 7 Jan 2015 09:29:51 +0000
> Subject: Re: [mkgmap-dev] small issue with Way.getCofG()
>
> HI Gerd, 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
> fillPolygon does if the points have no volume and form a line. If this
> renders nothing, then the algo 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 biggestSquaredDistanceToBlack 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 (biggestSquaredDistanceToBlack
> 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.
>
> Cheers,
>
> Mike
>
> *From:*Gerd Petermann [mailto:gpetermann_muenchen at hotmail.com]
> *Sent:* 07 January 2015 06:55
> *To:* mkgmap-dev at lists.mkgmap.org.uk
> *Subject:* Re: [mkgmap-dev] small issue with Way.getCofG()
>
> Hi Mike,
>
> on my PC the performance of your algo is quite good.
> Attached is a patch that contains your patch as well as my quick
> implementation
> of the algo described here:
> http://arxiv.org/ftp/arxiv/papers/1212/1212.3193.pdf
>
> The patch tests only performance, it computes the center with the 3
> different algos,
> I've commented the part that prints times and GPX data for debug purposes.
>
> I noticed that the results between both algos are very different, I did not
> yet try to find out which one is better, but mine is much slower on my PC.
> I also noticed that your algo doesn't always calculate a point in the
> polygon,
> see e.g.   way 178708143.
>
> If you like, please try to find a better compromise, I like to fix a
> problem in
> splitter first.
> I also did not yet look at the effect on the house number code, as there
> are many
> more small open problems, but I think it should be easy to sort that out.
>
> Gerd
>
>> Date: Tue, 6 Jan 2015 13:23:57 -0700
>> From:gpetermann_muenchen at hotmail.com <mailto:gpetermann_muenchen at hotmail.com>
>> To:mkgmap-dev at lists.mkgmap.org.uk <mailto:mkgmap-dev at lists.mkgmap.org.uk>
>> Subject: Re: [mkgmap-dev] small issue withWay.getCofG()
>>
>>  Hi Mike,
>>
>>  I like the idea, but it seems to be slow.
>> Is it possible that your algo suffers when no fast graphics card is
>> available?
>> On my netbook the performance is very poor, did not yet
>> try on the PC, but that also has no high speed graphics.
>>
>> Gerd
>>
>>
>> GerdP wrote
>> > Hi Mike,
>> >
>> > 50% sounds better than my algo, but still quite a lot. I'll have a closer
>> > look at your
>> > algo later.
>> > Please note that your change has a side effect on the house number
>> > generator.
>> > Up to now this doesn't contain a filter for generated POI, so each polygon
>> > with a house number is processed twice, once because of the POI, once
>> > because the Generator uses Way.getCofG(). If both have different positions
>> > this might have a negative impact.
>> >
>>  > Gerd
>> >
>>  >
>> > From:
>>
>> >mike at .co <mailto:mike at .co>
>>
>>  > To:
>>
>> >mkgmap-dev at .org <mailto:mkgmap-dev at .org>
>>
>>  > Date: Tue, 6 Jan 2015 14:56:30 +0000
>> > Subject: Re: [mkgmap-dev] small issue withWay.getCofG()
>> >
>>  > I have a working solution for ensuring that the created point is placed
>> > within the polygon when using --add-pois-to-areas, based on drawing the
>> > polygon on to a small monochrome bitmap and then looking for the point
>> > that
>> > is furthest from the surrounding area. I used a 9x9 bitmap for polygons
>> > having a small number of points and 15x15 for longer polygons. There is
>> > however a performance penalty. My standard map takes about 1 hour 20
>> > minutes; using this algorithm the time increases by about 50% to about 2
>> > hours. I am not currently able to commit changes to SVN (perhaps someone
>> > can
>> > help out with that) but I have attached the code changes. I suggest that
>> > due
>> > to the performance penalty, if we adopt this, then the --add-pois-to-areas
>> > option be extended to be --add-pois-to-areas[=centre|optimised] or
>> > something
>> > similar, with the default being centre and functioning as now and the
>> > optimised option invoking the new code. Please try out the suggested
>> > change.
>> > Note I don't expect this to work properly where a polygon is formed from a
>> > multiploygon relation, but the code could quite easily be adapted for this
>> > circumstance.
>> >
>>  >
>> > Regards,
>> > Mike
>> >
>> > _______________________________________________
>> > mkgmap-dev mailing list
>>
>>  > mkgmap-dev at .org <mailto:mkgmap-dev at .org>
>>
>>  > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> > _______________________________________________
>> > mkgmap-dev mailing list
>>
>>  > mkgmap-dev at .org <mailto:mkgmap-dev at .org>
>>
>>  > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>>
>>
>> --
>> View this message in context:http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5829247.html
>> Sent from theMkgmap Development mailing list archive at Nabble.com.
>> _______________________________________________
>>mkgmap-dev mailing list
>>mkgmap-dev at lists.mkgmap.org.uk <mailto:mkgmap-dev at lists.mkgmap.org.uk>
>>http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________ mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>