[mkgmap-dev] Bug in LocationHook?From GerdP gpetermann_muenchen at hotmail.com on Sat Jan 7 21:01:33 GMT 2012
Oops, that was meant as an answer on http://gis.638310.n2.nabble.com/Question-reg-LocationHook-and-incomplete-data-tp7162156p7162156.html Gerd GerdP wrote > > Hi WanMil, > > I think the problem is that we sort the boundaries before analysing the > lies_in tag. If we first fill the missing zip code tag (and maybe the > admin_level tag as well) from the boundaries found in lies_in, we should > not see the problem that elements are removed too early. > I'm just trying that. > > Ciao, > Gerd > > > WanMil wrote >> >>> Hi, >>> >>> >>> WanMil wrote >>>> >>>> that sounds strange. I think recreating the quadtree would only be >>>> benficial if recreating takes less time than removing elements. I >>>> wonder >>>> if that's the case? >>>> >>> >>> I think the current quadtree implementation has one problem: As long as >>> it >>> still contains a few elements, a get(...) takes more or less the same >>> time. >>> I guess that's because it still calls a lot of intersect() calculations >>> to >>> return a result. >>> I am still searching for an error which seems to slow down the program >>> too >>> much, but my patch does this: >>> - It keeps the list elemList >>> - If currLevel is changed, it checks if the previous level caused any >>> changes to the elements in the quadTree. If not, the whole elemList is >>> tested, all elements that are fully worked out are removed. >>> If the remaining list is much smaller, the quadtree is replaced. >> >> Sounds reasonable. There might be another solution within the quadtree: >> At the moments subtrees are not reduced. At an early stage of >> implementation I did have implemented this but it did not have an >> advantage. >> Now the quadtree uses other datastructures which might be easier to >> reduce. So a node which is not a leaf can be reduced after a successful >> remove operation if all childs are leafs and the sum of points in the >> leafs are lower than the maxsize. That should be not too complicted to >> implement and does not require any special handling in the LocationHook. >> >> I will give it a try within the next days. >> >> WanMil >> >> >>> >>> Ciao, >>> Gerd >>> >>> >>> -- >>> View this message in context: >>> http://gis.638310.n2.nabble.com/Bug-in-LocationHook-tp7157897p7161772.html >>> Sent from the Mkgmap Development mailing list archive at Nabble.com. >>> _______________________________________________ >>> mkgmap-dev mailing list >>> mkgmap-dev at .org >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > -- View this message in context: http://gis.638310.n2.nabble.com/Bug-in-LocationHook-tp7157897p7162657.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
- Previous message: [mkgmap-dev] Bug in LocationHook?
- Next message: [mkgmap-dev] Bug in LocationHook?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list