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: m...@tvage.co.uk
To: mkgmap-dev@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_muenc...@hotmail.com]
*Sent:* 07 January 2015 06:55
*To:* mkgmap-dev@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_muenc...@hotmail.com <mailto:gpetermann_muenc...@hotmail.com>
To:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@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@.co <mailto:mike@.co>
> To:
>mkgmap-dev@.org <mailto:mkgmap-dev@.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@.org <mailto:mkgmap-dev@.org>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev@.org <mailto:mkgmap-dev@.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@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
