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

Steve Ratcliffe schreef:

...

What I found is the following. Splitting a file with a border will produce a file that has the exact "bounds", without the overlap, in the resulting map. That is intentional; the bounds should not overlap and should meet exactly.

Are you really (as in really-really-really) sure about the fact that the maps should not overlap? A map with overlapping bounds seemed to work better here - especially around the edges. (I hope I described the problem of getting a blank map sufficiently to reproduce it - it did not happen when I overlapped the maps). [...]

I think that three things must line up exactly, the tiles them selves, the areas within the overview map and the areas in the TDB file. Probably one or more of those are out of step.

The overview map seems to suffer from some rounding problem, as the boundary was a bit shifted to right, up; then when I decreased the numbers, it was shifted left, down. Luckily, I know just enough about programming to know that you can't decrease an integer by .5 ;)

Its also possible that it only goes wrong in certain circumstances such as +ve or -ve longitude. The next step is to find out exactly which one is wrong and compare with a working map if necessary.

I can reproduce the problem of a blank map at different map intersections (see my first mail). The problem shows at highest zooming levels, when the boundary of the map is viewable (or sometimes just out of view). If it were only the difference between the overview map and the real map, you would expect the map to disappear when the overview rectangle would be out of sight, but that's not what happens. Did anyone else notice this problem before? Were you able to reproduce it? If it helps, I can prepare a map that will have a routing problem just at the edge (there's a biking tunnel that MapSource avoids, no matter how hard I try, while letting mkgmap render the map without a boundary, the tunnel works just fine). Let me know if you need the map/script/other stuff to reproduce it. Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579

Hi Mark, Mark Burton schreef:

I believe (because the ML is not showered with emails complaining about it failing) that inter-tile routing is generally working OK.

It really does work great. In fact, it took me quite a while to come to the conclusion that the map edge seemed to be involved and that there might be a routing problem after all. At first I thought it was the tagging of tunnel, the fact that I tried to send a bike through a tunnel, the fact that I chose a bicycle for routing at all (Garmin doesn't do a really good job there - or maybe they like biking so much that they send you for 30 kilometer trips when 11 could do). But a few days ago I noticed that the map dissapeared at the same spot where the routing went wrong when I biked around with my Garmin Nuvi. Oh, and yes: I really think there aren't enough people riding around on their bicycles at OSM/splitter map edges, while looking at their Garmin Nuvis loaded with Openstreetmap-data in "Driving Direction Up" (i.e. non-3D), "Highest Detail", "Highest zoom" mode. I really should start a support group ;-)

Please provide an example of it failing so we can study it.

memory=1700m maxn=500000 wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2' bzcat netherlands.osm.bz2 > netherlands.osm wget 'http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz' tar -zxf mkgmap-latest.tar.gz wget 'http://www.mkgmap.org.uk/splitter/splitter.jar' java -Xmx$memory -jar ./splitter.jar --max-nodes=$maxn netherlands.osm java -enableassertions -Xmx$memory -jar mkgmap*/mkgmap.jar \ --country-name=Nederland --country-abbr=NL --latin1 \ --remove-short-arcs --lower-case --route --preserve-element-order \ --location-autofill-1 --gmapsupp --net 63240008.osm.gz 63240010.osm.gz Then load the resulting map in MapSource; to be sure, select Edit-Preferences-Routing, Bicycle, shortest distance. (Set detail to Highest if you want to see the biking path). Then route from N52.42701 E4.82707 to N52.42625 E4.82736, they are on the same biking path, some 80 metres apart. You'll see the route deviate 3 kilometers. Also, if you try to zoom on one of the points above, you'll see a blank map. (This is Mapsource 6.11.5 running under Wine, but as said before: my Garmin Nuvi does the same - only on highest zooming level though, and only around the edges on the OSM map - it does not do that on the Garmin native map - I did check that). I hope you can reproduce my findings - that would be a help. Thanks so far, best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579

Mark Burton schreef:

OK - I have looked at your example and can confirm there is a problem in that mapsource doesn't display the region near the tile boundary, it has a gap of 200m or so. Don't know whether this is just mapsource being it's usual crap self, or the problem also exists on the gps.

It will route through the tunnel (as the attached picture shows) but

Yes, I noticed that - but could not reproduce it yesterday. Please notice however, that the route you found has both starting points at the lower map. That may or may not have anything to do with it. Your picture also shows that the upper map vanishes (which you confirmed already).

Now, this may be because mapsource thinks that using the tunnel and then looping back to the S again is not a good route so it decides you're better off going to the E. If that's the case, I don't think there is anything we can do about it.

If you could recheck with a map without the split, you'll see that routing through the tunnel is no problem at all. Just download some surroundings of the tunnel and build a map to try it. Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579

Mark Burton wrote:

OK - I have looked at your example and can confirm there is a problem in that mapsource doesn't display the region near the tile boundary, it has a gap of 200m or so. Don't know whether this is just mapsource being it's usual crap self, or the problem also exists on the gps.

My eTrex Legend HCx shows the data exactly how I cut them with the splitter but the outer tile boundaries of the map are shown a little (200 m - 500 m) bigger than the data. The offset is the same for all map layers, i.e. OSM and SRTM although the tiles are not the same. Looks like a rounding thing to me. Nothing I'd worry about.

Hi I've run your example and looked at the bounding boxes of everything important that I know about. First the actual bounds as given in the input files. All the bounds below I believe should be exactly equal to this. Also the first number on the first line should be the same as the third number on the second line bottom of 63240010 matches the top of 63240008 (only the last four digits of the map number shown below). 0010: 52.4267578125,3.2958984375 53.6572265625,5.625 0008: 52.119140625,3.2958984375 52.4267578125,4.9658203125 Inside the overview map there are definition areas that should cover the individual maps. 0010: 52.470703,3.339844 53.701172,5.668945 0008: 52.163086,3.339844 52.470703,5.009766 So top matches bottom, but not the same as the bounds. This could explain mapsource, but as it is not used on the device can't explain the problem in the GPS. In the Tdb file we have: 0010: 52.426758,3.295898 53.657227,5.625000 0008: 52.119141,3.295898 52.426758,4.965820 So top matches bottom, and matches bounds. All good. In the actual map the bounds are recorded in the TRE section in this case I found: TRE 0010: 52.4268,3.2959 53.6572,5.6250 TRE 0008: 52.1191,3.2959 52.4268,4.9658 So top matches bottom and matches bounds within the resolution that is printed. Inside the map there are also background polygons of type map coverage 0x4b. 0010: 52.426758,4.751587 52.734375,5.042725 0008: 52.119141,4.757080 52.426758,4.965820 Again these look correct. If I look at the actual location where roads etc get chopped it is correct at 52.426758 on both maps. So the conclusion is that the definition areas in the overview map are wrong. This would explain problems in mapsource, but not on the device. I'll next look at what is wrong, but this email is long enough already and it will give a chance for people to check to see if I've missed anything. ..Steve

On 18/07/09 13:09, Steve Ratcliffe wrote:

Hi

I've run your example and looked at the bounding boxes of everything important that I know about.

First the actual bounds as given in the input files. All the bounds below I believe should be exactly equal to this. Also the first number on the first line should be the same as the third number on the second line bottom of 63240010 matches the top of 63240008 (only the last four digits of the map number shown below). 0010: 52.4267578125,3.2958984375 53.6572265625,5.625 0008: 52.119140625,3.2958984375 52.4267578125,4.9658203125

Inside the overview map there are definition areas that should cover the individual maps. 0010: 52.470703,3.339844 53.701172,5.668945 0008: 52.163086,3.339844 52.470703,5.009766 So top matches bottom, but not the same as the bounds. This could explain mapsource, but as it is not used on the device can't explain the problem in the GPS.

So I know why this happens now. Coordinates in the file are recorded by using an offset from a central point in a subdivision. The central point is recorded exactly but the offset is in multiples of 2048 map units (in this case - it depends on the zoom level). This is called a 'shifted unit' elsewhere so that is the term I will use here. So if the tile height or width is an odd number of these shifted units then the centre point will be half way between a shifted unit boundary. Therefore adding any offset will leave you half a shifted unit out. I'm not sure if I explained that very well, but my conclusion is that 1. The tiles produced by splitter should be aligned on an even lower zoom boundary, so that they will be an even number of units on the overview map. 2. This is probably a problem throughout elsewhere. The central point should probably always be on a shifted unit boundary. A quick test with the attached patch shows that the boundaries shown in mapsource now line up with the map. The places where there are no tool-tips near the boundaries still exist though. I've not tried routing to see if it makes a difference. The attached patch is not a fix to the problem. ..Steve

Steve Ratcliffe wrote:

A quick test with the attached patch shows that the boundaries shown in mapsource now line up with the map. The places where there are no tool-tips near the boundaries still exist though. I've not tried routing to see if it makes a difference.

The attached patch is not a fix to the problem.

..Steve

In your patch, is the value of // TODO need to change this private final int topBits = 15; the first level in the overview map? If so, then could it not be read directly from the detailed maps, rather than being a constant? I noted the TODO. Thanks Garvan

Hello List, Tried to make sense of it. Tooltips seem not to work at all some 15-40 meters from a boundary. However, there are places where the tooltips dissapear more than a few meters from a boundary - specifically on a horizontal boundary. Wherever that happens, the map seems to dissapear at lower zooming levels. This seems to be tile dependent. For example: when I run splitter on netherlands.osm with the following areas: 63240008: 2430976,155648 to 2443264,233472 63240010: 2443264,155648 to 2500608,233472 ... then run mkgmap, it will: - show the map and show tooltips anywhere further East from E4.90522 - hide the upper map at high zoom levels between E4.80158 and E4.90522 - (there's a slight difference between << E4.80158 and > E4.80158, where the map will disappear earlier when << 4.80158.) The lower map seems all right, no matter what I try. I tried to look for structures that were larger than one tile or that would show up in one map, but not in the other (even splitter sometimes seems to loose ways when a node is not included), but I could not find anything sensible. Maybe someone else can find something with the areas.list above. Zoom to N52.42856 E4.90522 in Mapsource, note that to the right of the Meervalweg, you'll see tooltips, to the left, you don't. And when you zoom to 50m, the upper map dissapears. This is consistent with the way my Garmin Nuvi shows the result: to the right of E4.90522, show all; to the left, the map will disappear on higher zooming levels. Best regards, Valentijn

2009/7/18 Garvan & maew <garvan.maew@online.com.kh>

Did anyone else notice this problem before? Were you able to reproduce

...

it? If it helps, I can prepare a map that will have a routing problem just at the edge (there's a biking tunnel that MapSource avoids, no matter how hard I try, while letting mkgmap render the map without a boundary, the tunnel works just fine).

Let me know if you need the map/script/other stuff to reproduce it.

I have been experimenting with maps with only one tile, but I did notice the misalignment of the map selection box and the detailed map in mapsource. I assumed it was a rounding issue between the detailed map and the overview map which are at different scales, and never thought to report it as an issue. For a large map it is almost unnoticeable, but for a small sample it can be completely wrong. For small maps what I did was increased the size of the bounding box in the osm file, and the alignment problem was fixed, or no longer a problem, because the box was bigger than the tile.

One reason why others have not reported this may be because they do not use mapsource or QLandKarteGT. Those with external storage GPSr may never have seen this misalignment. Or like me, they just adjusted the boundaries.

Garvan

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Garvan, IMHO you misconcept real boundary overlay with the overview map overlay. There is in my opinion a problem that overview maps sometimes get created smaller than the actual map (i.e. when using gmaptool to create the mp overview map). I don't use mkgmap for overview map creation because it long was pretty buggy. Then in Mapsource maps will be cut off, while the data actually continues. Try a huge overview map (i.e. whole of europe) with your maps, to see if it is not an overview map problem instead of a real map data failure.

Steve Ratcliffe schreef:

So you will probably also find that in the area that disapears, if you hover over a road you do not also get the usual pop-up that tells you the name of the road.

Yes, but actually I blamed Wine instead of you ;-) (I feel I actually can safely blame whoever I want, being in an unroutable part of the world - if you come to get me by bike, that is ;-) But now you mention the pop-up, did you notice that the pop-ups work just above (so "within") the (shifted, see previous post) bounds of a map and when you hover outside the (grey lined) bounds, they immediately don't work? And that they do start to work again some 250 meters below the actual split and *that* is again the precise point where the map will not vanish anymore? So for the lower part of the split: the part of the map that will always show, is also the part of the map that has these pop-ups again. Since you know what you're talking about: is there a discussion, explanation or otherwise for the reason that you did not let the maps overlap? An overlap of 300 meters sounds like a good idea for the routing - but as said before, I'm saying this from a position of blessful ignorance. Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579

This issue of the area near a tile boundary not being drawn is weird because when I was first working on the inter-tile routing, I never noticed this occurring. So either I was lucky and just didn't come across it or something has changed since then to introduce this issue. So, a question to everyone: has this always been an issue or is it a regression? Cheers, Mark