Hi Steffen,
please try r3665. I think the code works now, but some parts are never reached,
e.g.
these lines:
sidesFlag |= 4; // signal end of a zip code/city
interval
if (indexes[0] == 0)
sidesFlag |= 1;
if (indexes[1] == 0)
sidesFlag |= 2;
If I got that right, one may write data to say that a part of the road doesn't
belong to a city.
I see no reason to do that until now.
Gerd
________________________________________
Von: [email protected]
<[email protected]> im Auftrag von Steffen Neumann
<[email protected]>
Gesendet: Sonntag, 7. Februar 2016 18:58
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] House number search - inaccuracy in city assignment
Hi Gerd,
understood, thanks for the analysis.
Cheers,
Steffen
On 07.02.2016 18:03, Gerd Petermann wrote:
> Hi Steffen, as I said, there is an error in mkgmap.
> The code is based on the results of Steve Ratcliffs analysis
> of the Garmin format and the code that he wrote in the display tool
> (which can print the img file in a kind of hex dump)
> My current understanding is that mkgmap writes invalid data because
> MapSource fails to interpret it the right way, but the
> display tool shows what the write routine "wanted" to write, so
> I assume that both the display tool and mkgmap are wrong.
> I don't know yet what makes this case special, I have to try some more
> test cases ...
>
> Gerd
>
> ________________________________________
> Von: [email protected]
> <[email protected]> im Auftrag von Steffen Neumann
> <[email protected]>
> Gesendet: Sonntag, 7. Februar 2016 17:32
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] House number search - inaccuracy in city assignment
>
> This is what I compiled the map with:
> --style-file=.\style^
> --list-styles^
> --check-styles^
> --style=snNuvi^
> --preserve-element-order^
> --latin1^
> --gmapsupp^
> --add-pois-to-areas^
> --remove-short-arcs^
> --merge-lines^
> --route^
> --index^
> --bounds="..\Boundaries\Europe"^
> --x-split-name-index^
> --process-exits^
> --housenumbers^
> --reduce-point-density=4^
> --reduce-point-density-polygon=8^
> --generate-sea:extend-sea-sectors,close-gaps=1000,floodblocker^
> --remove-ovm-work-files^
> --max-jobs=4^
> --family-name="OSM %COUNTRY%"^
> --description="OpenStreetMap %COUNTRY%(routable)"^
> --output-dir="%MAP_DIR%"^
>
> --poi-address switch is not used; referring to the help it is then
> enabled by default
>
> Using this map, on my Nuvi the following house numbers of the right
> street side of Ottostrasse in 85521 Hohenbrunn can be found:
> 8, 10, 12, 14, 16, 20, 28, 34, 36, 44, 50, 52, 82, 84, 90, 92, 94, 96,
> 98, 100, 102, 116, 118, 120, 122, 132
> The following house numbers of the right street side of Ottostrasse
> in 85521 Ottobrunn can be found:
> 4, 6, 22, 24, 38, 40, 42, 48, 54, 56, 62, 64, 70, 72, 78, 80, 86, 88,
> 134, 136
> On the left street side is all house numbers assigned to Ottobrunn.
>
> Similar problems occur in the Rosenheimer-Landstrasse in Ottobrunn.
> House number 111 can not be found with the Nuvi, neither in Ottobrunn,
> nor in Hohenbrunn.
>
> May be I did something wrong with the map compilation.
>
> Steffen
>
>
> On 07.02.2016 16:09, Gerd Petermann wrote:
>> OK, I think there is an error, but I have no idea where exactly it is.
>> My results so far (my bounds file is a bit older, your results may vary):
>> 1) With the default style, the city is normally taken from the bounds, not
>> from addr:city
>> 2) The road has more than 64 routing nodes and is therefore split into two
>> parts, the first part is completely in Ottobrunn,
>> the 2nd part starts somewhere before housenumber 95 (left side)
>> 3) The housenumber code calculates the right side numbers 116 to 120 to be
>> in Ottobrunn, 122 and following in Hohenbrunn
>> The numbers 116-118 are in one segment, followed by 120, followed by 122,
>> follwed by some empty segements, followed by 132,
>> follwed by some empty segements, followed by 134 and 136.
>> 4) With the result of an unmodified r3664 MapSource says that 116-122 are in
>> Hohenbrunn, and for higher numbers the city is empty
>> So that is for sure not what we want, probably the bit stream is wrong, but
>> out display tool is happy with it and displays what I expected
>>
>> I see no change in MapSource when I try with a modified version of mkgmap
>> that doesn't decrement the skip value.
>>
>> Will try again tomorrow.
>>
>> Gerd
>>
>> ________________________________________
>> Von: [email protected]
>> <[email protected]> im Auftrag von Gerd Petermann
>> <[email protected]>
>> Gesendet: Sonntag, 7. Februar 2016 13:22
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] House number search - inaccuracy in city assignment
>>
>> Hi Steffen,
>> I guess you found a bug, I remember that I also was
>> confused by this double decrement
>> of the skip value when I wrote the code.
>> I'll try to reproduce the problem later.
>>
>> Gerd
>> P.S: I'm a bit sick, so I can't concentrate well since weeks :(
>> ________________________________________
>> Von: [email protected]
>> <[email protected]> im Auftrag von Steffen Neumann
>> <[email protected]>
>> Gesendet: Sonntag, 7. Februar 2016 13:14
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] House number search - inaccuracy in city assignment
>>
>> On 07.02.2016 12:59, Thorsten Kukuk wrote:
>>> On Sun, Feb 07, Steffen Neumann wrote:
>>>
>>>> Morning everybody,
>>>>
>>>> playing around with my Garmin Nuvi I came across a problem with the
>>>> house number search.
>>>>
>>>> The location is:
>>>> Germany, Ottobrunn, Ottostrasse 132
>>>> +48.064630, +11.689558
>>>>
>>>> The Nuvi shows the address as:
>>>> Ottostrasse 132, Hohenbrunn (so the city is Hohenbrunn here)
>>>>
>>>> But in OSM the house is tagged as:
>>>> Ottostrasse 132, Ottobrunn (different city compared to Nuvi)
>>>>
>>>> So either the Garmin pulled the wrong city out of the house number
>>>> information or mkgmap put the wrong info in.
>>>
>>> Not sure if there is a bug in mkgmap or not, but the data in
>>> OSM is clearly not Ok. The address exits twice at the same place:
>>> once with addr:city=Ottobrunn, once with addr:city=Hohenbrunn.
>>> So maybe mkgmap creates both address records and you only looked
>>> at the wrong one?
>>> Since everything except this single address is tagged with
>>> addr:city=Hohenbrunn and the house is inside of the address
>>> boundary of Hohenbrunn, so the addr:city=Ottobrunn looks wrong to me.
>>>
>>> Thorsten
>>>
>>
>> Indeed, there's a contradiction in the address assignment at that
>> location. The building is referred to as belonging to Ottobrunn whereas
>> the POI nearby has the same address but located in Hohenbrunn.
>> Unfortunately my knowledge of mkgmap is not deep enough to asses whether
>> my remark in the code is reasonable.
>> The Nuvi does not find the house number Ottostrasse 132 in Ottobrunn.
>>
>> Thanks,
>> Steffen
>> _______________________________________________
>> mkgmap-dev mailing list
>> [email protected]
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> _______________________________________________
>> mkgmap-dev mailing list
>> [email protected]
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> _______________________________________________
>> mkgmap-dev mailing list
>> [email protected]
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
> _______________________________________________
> mkgmap-dev mailing list
> [email protected]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [email protected]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
