Worldwide routable Garmin maps: URL REMOVED

I don’t have a SD card to try it. I bought another map at the end (which works fine)…

In conjunction with this topic…
http://forum.openstreetmap.org/viewtopic.php?id=16232

Is it advisable to have primary roads non routable if you select no highways in your routing options on older devices?

And would this just be a dutch problem or could you expand this to the rest of the densely populated world?

Could it be that currently “natural water” is missing in OpenFietsMapLite from garmin.openstreetmap.nl?
In a version from 2014-04-25 I dó see these waters, in later versions they are missing (Basecamp, Mapsource, gps).

I see a lot of old posts talking about problems with address searches so I was wondering if searching for a specific house number on a given street is still not possible.

I can search for some addresses just fine on my Garmin Nuvi 265W but that other addresses don’t work. Yet, in terms of data, all the ones I’ve searched for are already in OpenStreetMap.

Example failing address:
3880 Valley Centre Drive
San Diego, CA

Example good address:
322 Encinitas Boulevard
Encinitas, CA

It seems that the failing address has not been mapped as an address, so it’s not in the map. A search on OSM only finds a hardware store with this address. I don’t think that is sufficient for the address to be mapped correctly.

However, in Germany way 37986013 housenumbers can’t be found in Mapsource, but can be in OSM and the numbers have mapped addresses.

I suspect that number searching is still an experimental feature. I can see a problem here in that OSM maps numbers to points or buildings, but in Garmin’s map format the numbers have to be mapped onto the roads and must be in ranges.

This address in OSM data is described as 3880 Valley Center Dr, while the road is Valley Center Drive. On Garmin map addresses are a part of a road. Since roads names don’t match, compiler is not able to attach address to a road and as a result you can’t find it.

not mapped as an address
Would you mind elaborating? I’m not sure what you mean for something to be mapped “as an address”.

mapped onto roads and ranges
Ah, that explains a lot such as how the GPS can seem to know where buildings go that didn’t exist back when the device was purchased.

road names don’t match
Good point; unfortunately, the problem happens even when the names match. Example:

4627 Carmel Mountain Road
San Diego, CA

I guess Beddhist is probably right that it is basically an experimental feature.

Thank you for the well thought out responses.

On a completely separate note…

Where do I start debugging if it seems a freeway exit is being announced as “Exit to Exit 3B” (number is made up) on Garmin rather than “Exit to Blah Street” or “Exit to Blah Street and Foo Street”? The motorway junction already has an exit_to tag that looks something like “Blah Street; Foo Street”.

This one exist, when compiling a map with default style.

… The new servers ARE REALLY fast, at least the que is gone :wink: and rendering is quick enough. I was expecting to wait for a couple of days but now it is done in 1,5 hour :open_mouth: :smiley:

Sorry for the big download… some serious driving on a still to be bought moto to be done soon :wink: file is here and could be removed.

p.s. I don’t know what storage hardware you are using now and I don’t really have any funds lying around. And I suppose you have considered the options already and don’t need somebody else questions :wink:
But considering the oeps 600gb remark, only local storage needed, only transient data(not really critical only kept 48hours anyway) and the fact I do have some experience in hardware(both enterprise and budget), is there something I can do?
More then:
sometimes wonder if I am doing something wrong.
Or that I am really happy with the improvements.

(pm or email is fine, but I read here as well)

Yes, there is some overcapacity again which allows me to dream of new functionality (only time is not permitting to implement them at the moment).

Some of the servers use local storage, some use a SAN e.g. MSA2000 (I believe), the servers are previously shutdown hardware and I gladly accepted anything useful that was offered to me. Currently there is no need for any new capacity (and I don’t have the time to configure new servers).

I don’t understand what you mean by “wondering if I am doing something wrong”?

Dear Lambertus,
I downloaded and installed maps for Iran from your site. Unfortunately, your Garmin maps suffer from a major flaw: Place names in non-Latin characters are not rendered properly. This makes the Iran map unusable for the most parts.
To further investigate the problem, I tried to compile the OSM data manually for Garmin. I found that the problem lies in the default code page setting assumed by mkgmap. You just need to instruct the program to default to Unicode encoding by passing the option --code-page=65001. Unicode support seems to have been added in the latest versions of mkgmap. I can confirm that the unicode map displays correctly on GPSMAP 62s (firmware version 2.80).
Could you at least rebuild your maps in Unicode for countries where non-Latin languages are used?

@Lambertus,
Latest map releases are routed through barriers like bollards, gates etc
This is probably caused by a mssing --link-pois-to-ways option in the mkgmap setting.
Can you check this and other options (see my mail)?

@AmZaf, I’m not sure unicode is supported by older devices, can anybody confirm this?

Thank you for this fantastic service :slight_smile:

I am curious about the address search in my Garmin (Oregon 650) device and in Mapsource for Danish Addresses (example: Kvikmarken 16, Gladsaxe Municipality). The addresses have proper house numbers (addr:housenumber) and street names (addr:street) in OSM, but with the Generic Routable map, all addresses on the road are found on the same place (mostly at one end of the road), whereas with the routable Bicycle map the address is found in exactly the right place. Is there any good explanation?

It is caused by a missing setting of --housenumbers in the configuration file. Thanks for noticing this Uougaard!
Lambertus, can you correct this (as well as the other settings like --link-pois-to-ways I mentioned earlier)?

Probably this has already been asked in the past but I couldn’t find an answer.
I downloaded the osm_generic (Generic routable) map of Italy.
The map is good but the address search has a great problem since italian addresses start with the type of the way and not with the name. If in english you write (and type) Main Street in Italy we write Via (Street) Principale (Main). As a result I have to know in advance if the way is a street, a square, an avenue and so on.
Is it possible to create a search database of the map (or whatever it is called) that ignores the more common way type names so that I can write “Main” and get a list of ways that start with Main, apart from the way type name?

Thank you
maxx

Excuse me but I dont understand your question. If the type of the way is on the OSM map, you must enter it in the search too. For instance if you look for Via X on your Garmin you have to type in the search Via X. Searching for simply X does not find the streets in your Garmin. I dont understand what you mean by “Main”.

I don’t know if this is a mkgmap issue, or a stylesheet issue:

I have discovered that several routes in Brazil is broken due to oneway=-1 is treated equal as oneway=true and oneway=yes, while a oneway=-1 should be treated as a oneway in opposite direction. I have tried to relate this problem to mkgmap developers without success.

I can’t find your question on http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/info.html
Can you send me the link?

He is using Main St as a hypothetical example. Translated it is Via Principale. In English we have road, avenue, crescent, lane and a few more. This is what he refers to as type. It seems common for Italians to know the name part, but not the type.

I believe the problem is with Garmin only searching from the beginning of the name string. Users of Spanish, Thai and no doubt many other users have the same problem.

It’s a usability problem. The street can only be found if you search for complete name. The problem is that you don’t always know the way qualifier (“St.” “Av.”, …) or how the contributor wrote it in OSM, and in other languages like spanish the qualifier is before the name.

There is some work in progress to solve or avoid the problem in the following South America map. http://www.i-nis.com.ar/osm/garmin (scripts to make the map are GPL)