[mkgmap-dev] Bug in LocationHook?

Sun Jan 8 08:06:42 GMT 2012

Hi WanMil,

okay, I try to find the source of the error: OSM or LocationHook ;-)

Gerd

WanMil wrote
> 
> No.
> An element can lie only in one admin_level with each number bound (one 
> for admin_level=11,10,9,8,7,etc.).
> There can be only one bound tagged with postcode.
> If an admin_level is tagged with a postcode there must be no other bound 
> at the same position tagged with postcode.
> That means it is sufficient to check for the admin_level.
> 
> That's tricky but it works if the input data is correct.
> 
> WanMil
> 
>> WanMil,
>>
>> the problem is this:
>> We 1st process all boundaries with postcode-only tag. That's ok.
>> We start processing boundaries that have an admin-level tag.
>> The first boundary that has an admin-level tag but no postcode-tag
>> switches
>> the currLevel from postcode to something starting with
>> mkgmap:admin-level,
>> but we still may have other boundaries that have the postcode tag coming
>> later.
>> So, I think we must first process all boundaries that have a postcode
>> tag.
>>
>> Gerd
>>
>>
>> WanMil wrote
>>>
>>> Hi Gerd,
>>>
>>> I don't see a problem just right now.
>>>
>>> The algorithm is as follows:
>>> 1. Load the precompiled bounds
>>> 2. Sort the bounds in the order
>>>      1. all bounds tagged with a postcode tag only
>>>      2. all bounds tagged with admin_level=11
>>>      3. all bounds tagged with admin_level=10
>>>      4. ..
>>>      5. all bounds tagged with admin_level=2
>>> 3. Go through the bounds and assign all tags and assign the referenced
>>> bounds tags also.
>>> 4. If an element is tagged with all remaining bounds tags it can be
>>> removed from the quadtree.
>>>
>>> Now comes the tricky thing:
>>> If a boundary with admin_level=4 also has a postcode tag it is ensured
>>> that no element without postcode tag is removed from the quadtree.
>>> Why?
>>> I assume that there must not be two overlapping postcode areas. So
>>> tagging admin_level=10 with postcode 12345 and admin_level=9 with
>>> postcode 12345 too would be an OSM error. There should be only one
>>> postcode area defining the whole area.
>>> With this assumption there can be only one bounds tagged with postcode
>>> only or one bounds tagged with an admin_level and the postcode.
>>> Postcode only bounds are handled first so after that it is only possible
>>> that an element lies in an area tagged with admin_level and postcode. So
>>> it's sufficient to check that the admin_level is set before removing it
>>> from the quadtree.
>>>
>>> WanMil
>>>
>>>
>>>> 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-tp7157897p7162654.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-tp7157897p7164147.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-tp7157897p7164181.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.