Worldwide routable Garmin maps: URL REMOVED

The main problem is that during this subsplitting a tile ID is given that is already in use (Paris tile 63242546.img lies east of Phoenix, Arizona).
So it means there is a bug in your script, but its far too complicated for me to see where. :confused:

Correct, I think. But I haven’t found the bug yet. Perhaps it has something to do with buffering and the OS because I’m using filesystem functions to determine things like the current maximum tilenumber. The server is tremendously busy when generating a new map, so it is possible that e.g. some changes to the filesystem haven’t propagated yet when I check for the current status.

Just to let you all know:
I’ve updated the Mkgmap version that is used to combine the individual maps from a very old one to the latest. Now I’m seeing a lot of maps that fail to generate (only the tiles.zip is present). I’m investigating the cause.

Several folks have alerted me to a problem with email handling: it appears that the system doesn’t send emails anymore. The problem is being investigated.

Edit:
The email daemon has been restarted and is functioning again.

Emailing stopped around 19:20 CET on the 18th. Everyone who’s request finished between then and 10:50 CET today (19th) will not receive the ‘map ready’ email. If you suspect that this concerns you then it’s best to request your map again. Sorry for any inconvenience.

Thanks to all who signaled the problem!

Thanks! so it wasn’t just me …

Regarding the license change and redaction bot I’ve decided to postpone a new map version for a few weeks. I’m afraid I will get too much questions and confusion about broken routing, missing roads, etc. This service is not only used by OSM mappers for checking their surroundings anymore, but also a lot of users who just want a map “that works”, I have to consider this group when making decisions. I hope you’re all OK with this?

I also hope that a delayed update cycle will reduce the load on the system after a while which will allow the server to be upgraded to the latest LTS version of the operating system. Since the deployment of the new website and the addition of the OpenFietsMap Lite map the system has trouble keeping up with demand, which most of you will have noticed already :confused:

Hi
I was able to put the .img file on the SD card and it works.
I do only have one problem. The country (craotia) is not searchable…

I mean, if i want to put in adress, i can found all the countrys around it, but not croatia it self…
If i look for citys (an option on my garmin, don’t know if this standard), then i can find the croatian city’s.
The map is also complete (when browsing at least.)

How is it possible that is cannot find the country.
Curiously, there is country called Country? but that isn’t croatie, as i cannot find the right citys…

What is the solution to this?

Sorry solved Craotia is called Hrvatska :smiley:

Just finished configuring and testing a second server (same hardware as the current, only disk cache is twice as large), everything looks good. Now I need to think about how to efficiently use both machines, write the tools and update the website to use both servers.

/me scratching my head here…

For now I’ve resurrected the old method for spreading requests over multiple servers: decide which server to use based on whether the request is a country or a custom request. This works -as they say- “good enough”, though I’m still thinking about a more scalable method.

Something like Gearman seems promising. Configure a few Gearman workers depending on the server capabilities and issue render requests from a Gearman client. Requests are queued and automatically spread over the workers who are ready to do some work. Sounds perfect and allows for easy adding/removing of resources.

We’ll see… :slight_smile:

Naive questions. The California map I created for the Nüvi 1200 using your excellent tool worked very well but in big cities (e.g. San Francisco) many,many street names are missing.

I saw in an earlier post something about a road-name-pois parameter, and wonder whether I should follow the process described in the FAQ to create the image manually (instead of the server) so that the street names in major cities are also included.

Do the names you are looking for actually exist in the OSM map? If they do, do they not show up when you zoom in or put your mouse pointer on the road?

Hi Beddhist,
Yes, when I zoom in the street shows up on the Nüvi satnav (and web openstreetmap.org). But I can’t search for it.
So the problem is that the name isn’t making it to the searchable index on the satnav. E.g. Eureka street in San Francisco.

I’ve switched to another tool to generate the MacOSX version due to a bug in the gmapi-builder script concerning TYP-files. The new tool is the commandline interface version of JaVaWa’s MapConverter. Many thanks for Jaco for providing this tool.

Both servers should now also be creating valid gmapi containers when a TYP file is included.

The first update after the second server has been added is underway and -you’ve probably guessed it- the update isn’t going as smooth as hoped. The version on the website was already updated before the files were distributed to the second server, about 10-20 people have requested maps that don’t contain any data. I’ve deleted these requests, so if your browser is returning 404 Not Found then it’s best to request your map again. I’m sorry for any inconvenience.

The map data for the generic map is now distributed successfully. The openfietsmap data is still being rendered and should be released in about 24 hours.

The problem in which the tiles of Paris France are misconfigured is still present in the new update :frowning:

Yeah it takes the same tile as Brussels
http://osm.pleiades.uni-wuppertal.de/garmin/generic/07-08-2012/63241989.img

In the OFM Lite it looks ok:
Paris tile http://osm.pleiades.uni-wuppertal.de/garmin/openfietsmap_lite/09-08-2012/63240194.img
Brussels: http://osm.pleiades.uni-wuppertal.de/garmin/openfietsmap_lite/09-08-2012/63240196.img

Since the generic and OFM use the same splitted files, why is then the Generic map corrupt?
Is the generic map containing too many nodes, more than the OFM lite? Is there a diferrence in mkgmap settings that is causing this?

Two more remarks:
-I notice that the one OFM Brussels map is split in two tiles in the generic map
-I have noticed that using -ea (enable assertions) sometimes generates an empty tile when only one road was corrupt in my maps, and therefore i dont use this option anymore. Maybe this is causing trouble too in the Paris area?

Almost. The base split is the same for both maps. I.e. the first run of splitter is splitting the planet using the max-nodes=1400000 parameter. The generic map and the OpenFietsMap render scripts then render and split these initial splitted tiles with every decreasing max-nodes parameters until everything is successfully rendered and the resulting tile is smaller then 8 MB. So some of the initial tiles are rendered only once for each map and some tiles are splitted/rendered many times before the result is accepted. This can (but doesn’t have to) result in a different final tile layout for each map type.

There are differences in Mkgmap settings between both map types.

Yes, this is probably a result of what the Mkgmap styles include or exclude.

I’m using the -ea option to ensure that Mkgmap doesn’t produce a tile when it’s not correct. Tiles that are 0 bytes are detected and automatically deleted. The smallest tile in both maps is 14kB in size.

Plan of action:
Find the initial tile that contains Paris
Enable as much logging as possible
Execute the rendering/splitting on that tile only
Analyze, analyze, analyze

If you provide the initial splitted tile for Paris online maybe we can help testing with that tile?
Probably post it also on mkgmap with the mkgmap settings you use?

Currently I use the Open FietsMap from garmin.openstreetmap.nl for cycling with the gps.
When I create a route (not a track) I notice that since the july version there is a strange point in the Motieweg (Holten). In this point routing stops, both Mapsource and Basecamp don’t let you pass this point anymore. The road goes from tertiary to unclassified and a path connects in the same point.
Other OSM maps (like OMTB map) don’t show this problem. Only Open FietsMap does.
In Potlatch I can’t see what could be the cause. Joining the nodes didn’t help.
Any idea?