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

Thu Jan 8 20:23:14 GMT 2015

Hi WanMil,

yes, I had something like this in mind.
StyledConverter could call the POIGenerator
for each polygon. The POIGenerator 
creates a dummy node, opies the tags, adds the 
mkgmap:area2poi=true tag and 
checks if the style produces a map element.
If yes, it calculates the coords
and returns the node which is than passed to addNode.

Anyhow, this change is only useful when performance
is a problem. I once had a similar idea for mp-processing.

Gerd

> Date: Thu, 8 Jan 2015 20:55:46 +0100
> From: wmgcnfg at web.de
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] small issue with Way.getCofG()
> 
> 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
> >
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150108/1e30de2a/attachment.html>