[mkgmap-dev] House number search - inaccuracy in city assignment

Sun Feb 7 11:13:53 GMT 2016

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