[mkgmap-dev] problems at map intersections?

Fri Jul 17 20:45:30 BST 2009

Hello list, I'm having a great time corresponding to myself here :)
but these are my observations so far.

Running Splitter, then Mkgmap.jar, then MapSetToolKit.exe, then
Mapsource, the resulting submaps are shifted from their bounding box:
they are about 2.4 kilometers left, up, from the map itself. (So you
have a bounding box that does not bound the map).

The resulting submaps have no overlap now, which results in strange
behaviour around the edges of the map:
1) It looks like sometimes Mapsource doesn't know how to get to the
other map - a sort of short-arc between maps; it will refuse to take
certain ways and will stubbornly route you around something, even if
it's a trivial, 50 meters route on the map.
2) Also, sometimes Mapsource (and my Garmin Nuvi) seem to choose the
wrong submap to display data from - resulting in a blank screen instead
of mapping information. This is best seen at high zooming levels.

Now I tried to get around this. If I use splitter to output a header of
writer.append(String.valueOf(Utils.toDegrees(extendedBounds.getMinLat())));

instead of the regular bounds.getMinLat(), I'm getting better results -
the maps now overlap. I decreased the bounds size in addToOverviewMap in
mkgmap. But is probably not be the correct way, as the bounding box
still seems a bit off - I'm guessing that now the map itself grows,
which will only work as long as the result will round down to a value
within the map itself? If I'm unlucky, the new bounding box will - again
- be larger than the map?

If I knew Java, I would try to get Splitter to output something like
Utils.toDegrees(bounds.getMinLat() + (extra / 2)), but as I don't know
enough about scope of variables, I will leave that to more knowledgeable
people. And maybe it's a stupid idea after all.

I'll stop hacking around in unknown code now and have a beer, but my
feeling is that
1) something should be done about the bounds in the overview map
2) I'm guessing that Garmin wants some overlap in submaps, so it can
choose from what file to display the data from.

Maybe 1 and 2 are the same problem (i.e. if the bounds are right, the
choice of map will be right as well).

I realise that I should have tried to hack an area.list with overlap,
then use --split-file=areas.list, which is easier than randomly hacking
around the source.

Anyway. Maybe someone with knowledge of Mkgmap could say something about
it?

Best regards,

Valentijn
-- 
Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579