House number search - inaccuracy in city assignment
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. Tracking down the phenomenon in mkgmap I believe that CityZipWriter::write(int skip, int[] indexes, int[] prevIndexes) causes the problem. Please let's take a closer look into the mkgmap source below - keep an eye on my comments. class CityZipWriter { -- snip -- private void write(int skip, int[] indexes, int[] prevIndexes) { if (Arrays.equals(indexes, prevIndexes)) return; // we can signal new values for left and / or right side int sidesFlag = 0; if (indexes[0] <= 0 && indexes[1] <= 0){ sidesFlag |= 4; // signal end of a zip code/city interval if (indexes[0] == 0) sidesFlag |= 1; if (indexes[1] == 0) sidesFlag |= 2; } else { if (indexes[1] != indexes[0]){ if (indexes[0] > 0 && indexes[0] != prevIndexes[0]) sidesFlag |= 1; if (indexes[1] > 0 && indexes[1] != prevIndexes[1]) sidesFlag |= 2; } } /*################################### Here the node index will be decremented by 1 but the caller has already cut 1 off (in public boolean compile(List<Numbers> numbers). In my case the actual index offset is 75 but 74 will be written into the file. This in turn would lead to the effect that the stretch before would be assigned to the city of Hohenbrunn (wrong) instead of Ottobrunn. The actual node index sequence is: 0 Ottobrunn 75 Hohenbrunn This is what the Garmin probably reads: 0 Ottobrunn 74 Hohenbrunn The house number 132 belongs to a stretch defined by number node 74-75 (Ottobrunn) but the Garmin believes it is already Hohenbrunn (the city of the next stretch). Don't know why we write skip-1 because skip already represents the offset of the node index before to the current node index - reduced by 1. So we actually write curNodeIndex-lastNodeIndex-2. That can't be right because the reader can not distinguish between skip 1 and skip 2. ###################################*/ int initFlag = Math.max(skip-1,0); if (initFlag > 31){ // we have to write two bytes buf.write((byte) (initFlag & 0x1f | 0x7<<5)); initFlag >>= 5; } initFlag |= sidesFlag << 5; /*################################### Not the problem but just a remark. It's hard to guess for the reader if there's a 2-byte flag coming in when the reader hits 11100000b. It might be the 1st byte of a 2-byte flag or a 1-byte flag with all sidesFlags set. ###################################*/ buf.write((byte) (initFlag & 0xff)); if ((sidesFlag & 4) == 0) { if (indexes[0] > 0 && (sidesFlag == 0 || (sidesFlag & 1) == 1)) writeIndex(indexes[0]); if (indexes[1] > 0 && (sidesFlag & 2) != 0) writeIndex(indexes[1]); } System.arraycopy(indexes, 0, prevIndexes, 0, indexes.length); } I'm probably wrong but it would at least explain the Garmin Nuvi behavior. But any clarification is welcome. Unfortunately I'm neither familiar with the habits of this project nor have I the means for proper testing in order to commit any changes. I just wanted to point out a possible problem. Cheers and thanks for your attention, Steffen
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 -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
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
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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I'm impressed, that was fast - excellent work! Here my test results of r3665 on the Nuvi: Ottobrunn, Ottostrasse, right road side: 4,6,8,10,12,14,16,20,22,24,28,34,36,38,40,42,44,48,50,52,54,56,62,64,70,72,78,80,82,86,88,90,92,94,96,98,100,102,116,118,120,122,134,136 Hohenbrunn, Ottostrasse, right road side: 132 - might be a special case because building and a poi have contradictory addresses Ottobrunn, Rosenheimer Landstrasse: 109, 111 not found Funny observation: Using --no-poi-address the Nuvi permutes the order of pages during address input. It asks for city, house number, road instead of city, road, house number. Nice peculiarity of the device. So your fix actually worked - thanks a lot. One question - how did you find out the proper encoding, it could have been a hundred other variants? Good Night, Steffen On 08.02.2016 18:20, Gerd Petermann wrote:
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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Steffen, thanks for the feedback, my results were a bit different, so I assume that you use a different style or a different bounds file. I've only changed the write routine, not the evaluation. You may enable the debug logging to find out more details if you want. Reg. the dev. process: Steve has done the complex work of understanding the img format. He has written the display tool based on that knowledge, see http://www.mkgmap.org.uk/websvn/listing.php?repname=display& I've looked at the sources for display tool to guess what mkgmap should write, and use it to verify that the output of display tool matches the data that mkgmap calculated (using debugging mode in Eclipse). When this is the case I try a few cases in MapSource to check if that works as well. ciao, Gerd ________________________________________ Von: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> Gesendet: Montag, 8. Februar 2016 22:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] House number search - inaccuracy in city assignment Hi Gerd, I'm impressed, that was fast - excellent work! Here my test results of r3665 on the Nuvi: Ottobrunn, Ottostrasse, right road side: 4,6,8,10,12,14,16,20,22,24,28,34,36,38,40,42,44,48,50,52,54,56,62,64,70,72,78,80,82,86,88,90,92,94,96,98,100,102,116,118,120,122,134,136 Hohenbrunn, Ottostrasse, right road side: 132 - might be a special case because building and a poi have contradictory addresses Ottobrunn, Rosenheimer Landstrasse: 109, 111 not found Funny observation: Using --no-poi-address the Nuvi permutes the order of pages during address input. It asks for city, house number, road instead of city, road, house number. Nice peculiarity of the device. So your fix actually worked - thanks a lot. One question - how did you find out the proper encoding, it could have been a hundred other variants? Good Night, Steffen On 08.02.2016 18:20, Gerd Petermann wrote:
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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> 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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steffen Neumann <sn@litotes.de> 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd and Steffen
Steve has done the complex work of understanding the img format. He has written the display tool based on that knowledge, see
In this case (and house numbers) I looked at the mapRead code from the part of cgpsmapper that was open sourced to get an idea of how it all worked. See: https://sourceforge.net/p/cgpsmapper/code/HEAD/tree/cgpsmapper/mapRead/img_i... - search for 'city_left'. ..Steve
Hi Gerd
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.
I believe it is, but I haven't found an example to check in a map to check it out further. It is strange that the bits are active when set for one case and active when unset for the other. So I am a little unsure about it. I see you've also the Polish format support, that is great as I can construct all the different cases to test. ..Steve
Hi Steve, I am not sure how well the Polish format reader works, I coded it to be able to process the first examples provided by Andrzej long ago. If you find problems, don't hesitate to fix them. I also think that the current implementation is a bit different to what the Garmin format suggests. If I got that right, the img format allows to say that a road is in different cities even if no adrresses are encoded. If that is wanted we would have to change the code in several places. Again, I see no need for that. Gerd ________________________________________ Von: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Dienstag, 9. Februar 2016 15:03 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] House number search - inaccuracy in city assignment Hi Gerd
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.
I believe it is, but I haven't found an example to check in a map to check it out further. It is strange that the bits are active when set for one case and active when unset for the other. So I am a little unsure about it. I see you've also the Polish format support, that is great as I can construct all the different cases to test. ..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Will have to look at some real examples tomorrow.. I made a very small change to the NetDisplay to display the node range. Previously it was displaying the end of the range, now it displays start-end, which will be less misleading.
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)
..Steve
Hi Steve, sounds like a good change, but svn complains when I try to update: Error validating server certificate for 'https://svn.parabola.me.uk:443': - The certificate hostname does not match. Certificate information: - Hostname: mkgmap.org.uk - Valid: from Dec 17 19:13:00 2015 GMT until Mar 16 19:13:00 2016 GMT - Issuer: Let's Encrypt Authority X1, Let's Encrypt, US - Fingerprint: 2C:54:EB:13:37:91:B0:B3:4C:DC:E4:65:82:1F:17:97:46:7A:10:0D Did you change something ? Gerd ________________________________________ Von: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Sonntag, 7. Februar 2016 22:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] House number search - inaccuracy in city assignment Hi Gerd Will have to look at some real examples tomorrow.. I made a very small change to the NetDisplay to display the node range. Previously it was displaying the end of the range, now it displays start-end, which will be less misleading.
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)
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd
sounds like a good change, but svn complains when I try to update: Error validating server certificate for 'https://svn.parabola.me.uk:443':
I'd much prefer if you could use svn.mkgmap.org.uk instead of svn.parabola.me.uk. I've added svn.parabola.me.uk into the certificate so it should work either way. At least for a while. The changed the ssl certificate to one that is issued by a real certificate authority and so should be trusted by default by browsers and (hopefully) svn. Previously I was using a self issued certificate. ..Steve
Hi Steve, I see. Don't know why I still used svn.parabola.me.uk, update worked. I see that I got the meaning of the data completely wrong, no idea why it worked sometimes. I am now writing a new algo... Gerd ________________________________________ Von: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Montag, 8. Februar 2016 12:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] House number search - inaccuracy in city assignment Hi Gerd
sounds like a good change, but svn complains when I try to update: Error validating server certificate for 'https://svn.parabola.me.uk:443':
I'd much prefer if you could use svn.mkgmap.org.uk instead of svn.parabola.me.uk. I've added svn.parabola.me.uk into the certificate so it should work either way. At least for a while. The changed the ssl certificate to one that is issued by a real certificate authority and so should be trusted by default by browsers and (hopefully) svn. Previously I was using a self issued certificate. ..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (4)
-
Gerd Petermann -
Steffen Neumann -
Steve Ratcliffe -
Thorsten Kukuk