[mkgmap-dev] LocationHook and tagging ways

Wed Jan 11 08:31:47 GMT 2012

Hi WanMil,

> Date: Tue, 10 Jan 2012 22:25:29 +0100
> From: wmgcnfg at web.de
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] LocationHook and tagging ways
> 
> > Hi list,
> >
> > as discussed before, the current implementation of LocationHook produces
> > somehow unpredictable results when it locates ways that cross boundaries.
> > A correct solution would be to split the way, but according to WanMil this
> > would be very slow.
> 
> I think so. But of course it would be good to try that. Maybe it's also 
> possible to differ between a quick mode (the one which is implemented) 
> and an exact mode (splitting ways and shapes at the boundaries).

I did not look at this until now, but I agree that it would result in higher quality. We already seem to have a class for  that stuff, see 
AreaClipper which is used in StyledConverter, and LineClipper which is used in ElementSaver. Maybe we just have to move 
some method calls?

> 
> > So, with bad luck, we may find a way with 100 points in a boundary that
> > contains only one of them.
> >
> > While thinking about a test for my optimized version I wondered why we put
> > all points of a way into the quadtree, and not only one (e.g. the 1st, the
> > last, or the one in the middle).
> > Using only one point makes the quadtree much smaller and faster, and the
> > result is (almost) as correct as before.
> > I see only one problem: If the way crosses boundaries, one of the boundaries
> > may contain better information (more complete) than the other(s). If we
> > chose the "wrong" point for searching, we may find only the incomplete
> > information.
> 
> That's the problem. In areas where boundaries are not 100% complete a 
> lot of elements are not assigned.

Oh oh!
I did not notice that until now. I thought it is a rare case that Node or Way is not found, because I only looked at the final result of LocationHook.
I thought I can ignore the few cases where the first point of a way is not found.
In fact, for some admin_levels we only have a few boundaries which do not nearly cover the whole bounding box, means, many ways are not found.
This means my current implementation is much slower than expected :-(( and I definetly have to change it so that I have all boundary info in my quadtree 
before starting to seach. The good news is that I now have an idea how that could be done in the BoundaryPreparer.

Ciao,
Gerd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120111/e7a652d6/attachment.html 