> Date: Tue, 10 Jan 2012 22:25:29 +0100
> From: wmgcnfg@web.de
> To: mkgmap-dev@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