First off, thank you Lambertus for your efforts. I bought a Garmin a few years ago, and I’ve been using your site ever since.
Recently, someone tagged the island I live on (Vancouver Island, http://osm.org/go/WDzgVj-) as place=island. The tagging’s fine, that isn’t the problem. The problem is that now when I generate a map from your site, the place=island layer seems to cover up some other items, like parks, golf courses, and cemeteries, so these don’t display. With the Mapnik TYP, I was able to edit it to either remove that layer or re-order it so it’s underneath, but I can’t do that with the default, no-TYP style, which I prefer. Would it be possible for you to change the settings so the place=island layer doesn’t cover up other items? Sorry, I’m not very familiar with the map generation process, so I really don’t know how involved this may be.
I think there are two options, either remove place=island from the mkgmap polygon style (which seems plausible, because the shapes can be rendered with multipolygons now perfectly without this island tag) or leave it as it is and render the maps with a typ file (which can be customised like you have done). BTW, with a typ file editor you can edit the mapnik typ file and make the map appear as the map without a typ file by deleting the unwanted objects.
I have used the downloaded maps in Mapsource and now Basecamp for some time and have been very pleased. However the latest UK map download (02-12-2012) appears distorted in both Mapsource and Basecamp, the horizontal distances are shrunk and the whole map looks taller & thinner than it should be. The map looks OK on my Garmin Legend though!
I have not changed any setting in Mapsource or Basecamp and they both display the previous downloaded version OK.
Any thoughts about why this is happening?
Thanks
Ken
Thanks for the reply. I used Ctrl-Alt-A in Mapsource and chose “let MapSource choose the projection angle” and restarted MapSource but there was no difference.
I then chose an angle of 50 degrees, when I restarted MapSource the map looked OK. I then started Basecamp and that looked OK as well.
I reset the MapSource angle to “let MapSource choose the projection angle” and it reset both MapSource and Basecamp to the thin display.
I then chose an angle of 85 degrees, both MapSource and Basecamp changed back to an acceptable view which does not look any different to the 50 degree angle?
I’m not sure what changing the angle does, why the 50 degree looks like the 85 degree, why the default looks so thin and why changing it in MapSource automatically affects Basecamp but it is much better so I guess that I will use it as it is :).
Thanks once again
Ken
PS A bit of searching showed that the projection angle change is written to the registry which is why changing it in MapSource also changes it in Basecamp.
Probably 85 wasn’t accepted, since it was outside map area. Press Alt-Ctr-A again and check what is current value. I think default value is middle of the map. If area of recent release was extended more to north, then map view could change. Pity Garmin is not able to provide better conformal projection in current programs, like it was done in Mapsource 6.13.
The latest maps (2012-12-02) have an error in one of the highways in Northern Teritory, Australia. At first I though the 17 kilometre piece of road had been deleted in OSM, so I checked the road in JOSM and found it fine. It is strange as the road is one continuous straight way with very few nodes and the missing chunk is in the middle.
Check it out, the bounding Box is min lat: -19.7279276 min lon: 135.736084 max lat: -19.4898967 max lon: 136.0107422. The road is the Tableland Highway and the missing 17 kilometre piece of road is between these two points:
When I check the OSM data, there is not even a node anywhere near one of the two points and it looks clean. What would have caused this piece of road to disappear? It has no nodes in a perfectly straight 30 kilometre stretch. Could this be the problem? I will add some intermediate nodes and see if the problem exists in the next set of Routable Maps. The problem shows up in Mapsource. I have not transferred the map to my GPS so I don’t know if the piece of road is missing on the GPS. This road was fine in the previous (2012-11-29) edition of the Routable Maps.
The lack of nodes was indeed an issue by the tile splitter. Tile borders may vary from update to update.
There were made some major improvements with the splitter lately to prevent this. Don’t know if Lambertus used the experimental splitter version in the latest update?
I am looking at the latest routable maps (2012-12-17) and the problem that I mentioned is fixed (Northern Teritory of Australia). I have discovered another road that is now missing a chunk that was not missing in the 2012-12-02 map set and the OSM data has not changed since that last map set. The road is missing bewtween -33.36683, 137.05230 and -33.39845, 137.05230 In South Australia near Whyalla. The way is nodeless from -33.3668392, 137.0523009 to -33.4425591, 137.0523058, a distance of only 8.398 km.
I also noticed that the boundary between tiles AU-Adelade and AU-Mount Isa cuts through this nodeless section. Could it be that the splitter is not looking far enough to see if the way in one tile is connected to the same way in the other tile?
I will add some intervening nodes to prevent this from occuring again, however there seems to be a problem if the splitter is causing this to occur with nodeless runs of under 10 kilometre. There may be many other roads with missing chunks undiscovered, particularly in desert area like Australia where it is not uncommon to have straight roads for many hundreds of kilometres.
Is it possible to have two OSM maps of the same area (different type files) in the GPSr?
I can install two versions to the computer. First I install one with the Mapnik type file-change the name, ID with JaVaWa; then I install the the regular non-type file version. Both show up in Mapsource and Basecamp. But when I send them, individually (and change the names), to the GPSr, only one map shows up (probably since all the map segments are the same). Then JaVaWa shows errors- map segments sharing ID numbers.
Is there an easy way to edit the map segment IDs and still have the maps work correctly? Or would I have to take the segments, change the ID numbers, and compile my own map?
Why 2 maps of the same area? I am just trying to find out which features show up better on my Montana so I can pick and choose if I want to edit my own type file.
Any ideas or thoughts would be appreciated. Thanks and jama rek,
This can be done on img prepared for device. You can change ID for a set of img too, but not for a mpaset installed in Mapsorce, GMapTool won’t correct TDB file.
popej, aren’t those segment IDs also being used in the search index files? Changing them would break search possibilities I guess…
I did think of adding the option to change the segment IDs in GMTK, but this kept me from doing it…
It’s not a trivial task. GMapTool simultaneously changes map ID in many places including search index. Corrected subfiles are: TRE, GMP, MPS, MDR, MD2, TRF, MMR. You can find map ID in other files - TDB, MDX, JCV. These aren’t processed by GMapTool.
Is it possible that the latest Open Fietsmap Lite as downloaded from garmin.openstreetmap.nl misses the area-features?
I only get lines and points on a light green background (“Land”). Both from the installer and from the gmapsupp.img. And from both latest versions.
In the older versions this wasn’t the case.
Geert
You are right, it looks like something went wrong. If I remove the typ file, the area objects appear again so they are somehow invisible.
I can’t see any faults in my typ files, the light version on my openfietsmap.nl looks good (generated with mkgmap r2431).
Lambertus’ version is generated with mkgmap-r2423, maybe this version has some bugs.
I reported one issue which had to do with the typ file processing too, so maybe in the next update with an improved mkgmap version it’s solved?
Lambertus, can you check if the lite version uses the parameter --generate-sea=land-tag=natural=background?
I suspect it uses somehow natural=land as background (0x27) which covers almost everything because I use it for other purposes in my typ file (islands in a lake for instance).
A typ file to fix this issue can be downloaded here (temporarily workaround, need to be fixed in the compilation process)