[mkgmap-dev] Bug in LocationHook?

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.