Hi WanMil,
Date: Sun, 15 Jan 2012 09:45:33 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] LocationHook with new Quadtree
Hi WanMil,
If I see this right, we would see only a few changes if we split the ways on boundaries first. If you have an idea how to do it, please let me know (if you don't want to do it).
There are some detail problems left: 1. Up to now there is no clipper that splits lines at polygon borders. (or I haven't found it in the mkgmap source code?) 2. In case we have a closed way it is not clear to the LocationHook if it is a line or a shape. This is decided by the styles. A workaround would be to cut this way twice - one as line and second as shape. The line variant would be applied to the line style whereas the shape variant is only applied to the polygons style. This is not 100% correct (the polygon style would not apply if the line style has a hit) but it will solve most cases. ?? By the way: I never checked if it makes sense to add location information to shapes. Are they used gy garmin?
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.
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. Ciao, Gerd