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