Hi WanMil,
Date: Mon, 16 Jan 2012 22:16:21 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] LocationHook with new Quadtree
Hi Gerd,
3. I expect that most streets do not end exactly at a city border but lots will end some meters after it. Cutting them will increase the number of objects much and we will have a lot of short streets. So maybe an overlapping threshold is required for the decision not to split a line.
Okay, since I am not yet familiar with the part of the program that uses the location info, I'll leave that for now.
I don't want you hold off from changing that and playing around a bit. I only want to list up things that come into my mind that have to be solved so you can be aware of that :-)
Don't worry, I'll keep on searching for optimizations. When I say I leave it for now that means that I let my brain do its work without forcing it. Sometimes I wake up with an idea, and than I start coding.
The remaining differences should be errors caused by the "insideness" problem of contains().
Problems with the bounding box of the quadtree should be solved by adding +1 to maxlat/maxlong of the java area object.
Hmm, does that mean you want to shift the whole area or only selected points? Which ones? I thought about using the Area.transform() method to blow up the area a little bit, but did not yet find something useful. I think searching the shifted point is easy to implement and this double (or multiple) search will not happen very often.
I think it's much easier: In the constructor of BoundaryQuadTree.Node use the following line: this.bbox = new Rectangle(bbox.getMinLong(), bbox.getMinLat(), bbox.getMaxLong() - bbox.getMinLong() + 1, bbox.getMaxLat() - bbox.getMinLat() + 1);
So just increase the width and height of the (java.awt.geom.Area) bounding box by 1. That should do it(?). I don't think so. The area keeps it's own internal bbox in field cachedBounds, and that is tested first when contains() is called . Anyway, while searching for the discrepancies with and without using the lies_in info I found a problem with rounding errors that can result in endless loops. I've added a check for this, but it slows down processing a little bit. Also, some of the postal_code boundaries are intersecting (probably errors in OSM, but the algorithm went amok when it happened).
I have compared the remaining differences and found them only for ways that are crossing boundaries, and for those both results looked good to me. I'll post a new patch tomorrow. ciao, Gerd
WanMil
Ciao, Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev