“No Map Data Available”.
I am having the same problem on a Garmin 60csx using mapsource 6.11.6.
I have ticked "Include Route Calculation Data in mapsource.
I use the process listed above - that is go to addresses, enter any old street number and then try to enter data into the street name and the response is “None Found” - zip…no streets are in the database.
Note that the map and street names are listed on the screen.
Anyone know what would be causing this?
thanks
Current MS version is 6.16.3. Unless you are using a very old operating system you should think of upgrading.
Have upgraded to the latest MS and downloaded the latest version of the OSM map and the outcome is identical as previously discussed.
Trying another approach I sent an older map to the GPS and it routed fine with that map (which is probably a year old) so there must be a problem with the current OSM configuration??
Ligfietser tipped me to use a new feature of Mkgmap that should improve the address search quite a bit (bounds and location-fill options). A new version using these options is being uploaded now and should come online within 12 24 hours or so.
Crap, I forgot to upload the updated script. Restarted the update process…
Your OSM’s work perfect in my Edge 800. Thanks!! We ride many paths and trails that show in the OSM maps but not in Garmin’s NT chip.
I’m having trouble getting my gf’s 705 to read them, though. Could be the sd card I’m using is too big at 4gb. Do I need to use a smaller card?
Dear Lambertus,
thanks a lot for this great service! I use it on my Vista HCx for navigation by foot and bike, where it works pretty good! Even the UI on your Server is fine for beginners, I recommended it multiple times to friends.
Now i noticed a strange routing behaviour: I tried to route by car to a distant place (Garmin routing setting: car/motorcycle) and my Garmin tried to take me multiple times over highway=track. In Germany there seems to be an agreement, that tracks without additional tags should not be used for car navigation (http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dtrack). Openrouteservice regards this, for example.
Is there any possibility, that your maps could regard this, too?
Once again, thanks a lot!
gis_jam
The Germans seem to think that routing should follow what they are doing, but it cannot possibly work that way. In most countries on this planet driving on tracks is allowed and often the norm. I can’t see anybody implementing a routing engine that will check whether a particular track is in Germany or not to decide whether to route over it or not. Certainly, I can’t see mkgmap implementing this.
I suggest you object to this in the appropriate German forum and the talk page for the wiki entry that you have linked to.
Worse: I have just discovered that Garmin’s own soft and firmware will happily route cars over walkways, unless they are specifically restricted. Now THAT I do not follow…
Hi Beddhist, thanks for your reply. I understand that the worldwide community will never use the tags in an absolutely identical way. But isn’t it unthinkable that a worldwide routable map should regard the regional characteristics? This service by Lambertus offers pre-defined regions for Download. Would it be problematic, that these regional datasets use the tags in a region-specific way? I think the commercial providers just do that…
Greetings, gis_jam
@gis_jam, how about avoid unpaved roads?
Btw, it is possible to adapt the styles so country specific rules can be added. Something like mkgmap:country=DEU & highway=track {add motorcar=no}
No idea, sorry. Can’t hurt to try though…
I certainly isn’t unthinkable. Indeed that would be great! But (there’s always a but), I can’t see any doable way to achieve this with my resources and tools.
This is why you pay them money…
Does it help if you configure the GPS to avoid unpaved roads?
I’m aware that this service doesn’t produce the ideal map for each country and each situation. It’s very generic which also means it’s not perfect. If you want a map that works better then you can have a look at any of the other map providers, many of whom specialize in a specific region or usage, or consider contributing to e.g. the Mkgmap project to make the software better…
How should a routing engine ‘know’ that a track is in Germany and not in, say, Belgium just across the border? The track would have to be tagged as German. That’s an additional redundant tag. You can be certain that many, if not most mappers wouldn’t put it in.
The alternative would be for the mkgmap programmers to add code to the compiler to check whether a track is inside the German border. I can imagine how hard that would be. And that’s just for one country. Then people will come along and say that in Undertibuktustan some other restriction does or does not apply and it is therefore implied and would the programmers please add code for that. They did it for Germany, Switzerland and Austria…
No, the Germans have to conform to the rest of the world and not the other way round. (I’m taking the liberty to say that as a German.)
If Openrouteservice works like that then I suspect that routing outside German speaking countries (I think they all work the same) will not work correctly.
E.g. Garmin buy their data from official sources and then compile the maps from that. So, it’s easy for them to add restrictions to all tracks.
If you need this kind of routing then you can quite easily compile your own map with mkgmap.
You mean to say that the code to determine what country any given coordinate is in is already in mkgmap? Or does it rely on tags?
Peter,
For the address search index, mkgmap uses already the locator engine that can see where a highway is located. It is using admin. boundaries, so it can be nation wide, or within a state, or city.
These rules can also be used for access tags. I use them to specify if certain highways (like trunk roads, pedestrian streets) are allowed or not for cycling by law.
So in my style file I set those trunk roads to motorways, in order that cyclists are not allowed on them:
highway=trunk & mkgmap:country ~ ‘(NLD|BEL|LUX|FRA|DEU|AUT|CHE|DNK|HUN|ROU)’ { set highway=motorway }
This kind of rules you can also set for tracks.
Ok, Thanks. I’ll go away and eat my words now…
My apologies to gis_jam.
That’s OK. We are all here to learn 
As Ligfietser pointed out it is possible by GIS-Means: You just need a catalogue of regional specifica. By processing every way inside/outside a country’s polygon you could see which characteristics would apply. But I absolutely understand that it goes beyond Lambertus’ capacity.
Thanks for pointing me to avoiding unpaved roads - I’ll try this out. Shouldn’t be there a FAQ instead of this Monster-thread? Maybe in the OSM Wiki?
Ligfietser and Beddhist are working on an improved generic routing stylesheet + TYP file. I’m sure the German specifics can find their way into this work.
I really must finish the server side stuff to use their promising work soon. Slap me in the face to get me moving! 
There is a FAQ that lists some Mkgmap specific quirks. I’d welcome a wiki help/FAQ page for the garmin.openstreetmap.nl service and can link from that site to a wiki page, but there are already a buch of manuals listed so I’m not sure how much it will add…
I’ll ask Beddhist to kick some ass 
Btw Lambertus, I tried the new update but still find some country ABC data in the address search that doesn’t belong there…
So it means the locator cannot assign all cities in the NLD’s to the right places.
Could it be that you need to update the mkgmap version on the server as well (still shows mkgmap r2009)?
Or do you still filter some admin boundaries out of the map by preprocessing (admin level 4?)
Humpf… But a whole lot better now, hopefully?
The Mkgmap on the server is only used to create the gmapsupp from all the pre-rendered *.img files. I fail to see how that impacts the address search.
Only the very lowest boundaries (9 and 10 afaik). But this is also disabled for the new setup to be (yet another reason to switch).
The addresses in the NLDs need Admin level=10 which are the place name boundaries. Maybe thats why the locator is confused?
Oh dear 
Yes, I reckon that’s the culprit then. This pre-filtering has really proven to be hopeless… Thank you for identifying the likely source of the problem.