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.
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
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…
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.
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.
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.
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?
Hi GRI, I have corrected the node in the Motieweg at the point where the footway connects. The end-node of the footway was placed on top of the Motieweg node, but was not connected. Routing should be ok now, but may take some time before it is effective in downloaded maps. http://www.openstreetmap.org/?lat=52.297415&lon=6.418943&zoom=18&layers=M
Well, after working through thousands of lines of logging again (one map update results in 127.000 lines of logging :/), the source of the problem for Paris is found: When Splitter still cannot split the initial Paris tile in at least two subtiles using the parameter max-nodes=100.000 (remember: the initial split is using max-nodes=1.400.000!) the script simply gives up. Apparently Paris is the most complex area in OSM and the script is giving up too early.
Random other tiles are included as tiles for Paris because not everything is cleaned-up after giving up (especially the XML files that contain the tile definitions from the splitting action).
Phiew, finally!
The necessary changes to the scripts are made (lowest max-nodes is now 10.000 but the change to the code wasn’t as straight forward as it looks). A new update is underway. Hopefully I didn’t introduce new bugs…
BTW, it would increase the speed of the rendering tremendously when Splitter could simply be ordered to output N files instead of providing a max-nodes parameter. This would eliminate potentially up to 23 split attempts on each initial tile (currently the initial split results in about 1900 tiles and the final result consists of about 2700 tiles).
I tried to download a map of BeNeLux, DE and part of France, from server osm2, which sends a mail fine that my request was queued but then nothing happens. It says I’m #0 in the queue but I get no confirmation that my map is complete. Then I changed the url to point to osm instead of osm2 and now I’m at #1 instead of #0 which looks more healthy, now waiting for a confirmation that it finished compiling my map.
When I change osm2 to osm in the request URL I get the same queue URL except on server 1
[UPDATE] Finally got a confirmation mail from osm(1), which pointed me to a download location on osm2, which works fine, so I guess there is something wrong with the queue/processing on osm2, although it provides the files just fine.
