Ok, this is because I added some console.log statements to the JavaScript code to help in debugging, but IE doesn’t declare a ‘console’ object when the ‘Developer Tools’ aren’t active and thus stops Javascript execution (one of those irritating things about IE), ofcourse Firefox and Chrome don’t have any problems with that…
Anyway, the statements are disabled so now you should see the email box or download link (tested in IE9 which is much quicker in Javascript, so you should consider upgrading IE8 to IE9).
The tile numbers and their locations are f*cked up at least for the two missing tiles in Paris. They are matched to a US and Peruvian tile. I don’t know why at the moment.
Edit: there are two tiles named 63242648, one in Peru and one in France. The Peruvian tile overwrote the France tile but the France tile got listed first, so the intermediate cause is known. However, why it is possible to have two tiles with the same number is still a mystery to me.
I have been changing FIDs for some time to install several map sets. However, today JaVaWa GMTK messed up my registry in a minor way: I now have an extra entry called ‘Generic Routable’, not visible in GMTK, but it shows in MapsetToolkit with errors. When I went to install the next map set I was told that ‘Generic’ was already installed and I had to uninstall it. This I did, but it did nothing (the error entry remained).
It all works anyway and I removed the extra entry with MSTK, but it’s a little worrying…
For what it’s worth, I just downloaded Thailand + parts of Germany and it seems that all map tiles are there.
Lambertus,
The Mapnik typ file is still not included, is that correct?
I also noticed you switched the PID from 3 to 6 so bear in mind you have to change this in the typ file.
Or you can use .txt typ files instead of .typ then mkgmap will compile a matching typ file from it.
Please use http://mijndev.openstreetmap.nl/~ligfietser/diverse/mapnik.typ(r2160).zip for an updated typ file.
I also noticed that it is still an old map update, none of my recent edits are in there…
Thanks, I still have to look into the stylesheet thing.
Your missing edis are strange, because I’m nearly 100% certain that this update used the updated planet, but I did a lot of things manually for this update so it is remotely possible I somehow used the old planet. Otherwise my updated planet isn’t updated at all…
Seems the same for me as well, the latest update’s data appears to be the same as the update from a few days back, for southeastern Arizona at least. Trails I added/edited May 17 are there, but not ones added May 19 and beyond.
This is double strange. The source planet is May 8th, is updated to June 16th in one run and it contains changes from the 17th but not from the 19th of May? That is sooo confusing. Bah. The planet should either update or not, not something in between
My changes are visible up to the evening of 19/5 NZT, that’s the morning of the 20th your time. However, even after clearing the cache (Ctrl-G twice) it took a lot of opening and closing of files for any changes to become visible. MS is weird.
Seems to be more widespread??? I recently downloaded a UAE / GCC image file from another site which was updated from June data which also is missing updates from arround the middle of May???
Edit: After running the update process a few times, the local planet copy now appears to be fully up to date. A new map update is started and will finish in about 1 to 2 days.
Csdf I used yours i downloaded your latest map. but noticed that some of my uae uploads are not in the map. as far a I can tell it looks like the map has my updates to about mid may but nothing later. for example I added te carpark area at dune morip in the first week of june but its not in the img file
Downloaded 17/18 Jun 2012 from http://garmin.openstreetmap.nl/index_new.php France with the hole in Paris area that appears to overlap several tiles and not just two. Also intriguingly France includes 63241924 Milwaukee and 63242648 Macas Ecuador / Chimbote Peru tiles.
I suppose this happened because of my multithreaded (or rather: parallel processing) rendering where both threads are ‘fighting’ for the next free tilenumber when the current tile needs subsplitting. Determining the next free tilenumber is supposed to be atomic using a lock file but I guess this is not entirely atomic.
The current PHP code is (unsafe locking):
while (file_exists("splitter.lock")) {
sleep(1);
}
// Create the split lock so we don't get inter-threading problems with double tile id's
touch("splitter.lock");
[[Do the subsplitting here]]
// Release the split lock
unlink("splitter.lock");
Instead of using file_exists/touch/unlink code, I think I need to use the PHP flock function which would translate into something like this (safe locking):
$fp = fopen("splitter.lock", "r+");
// Lock the file exclusively
flock($fp, LOCK_EX);
[[Do the subsplitting here]]
// Release the lock
flock($fp, LOCK_UN);
// Close the lock file
fclose($fp);
A US contact wrote that he was routed over this trail with a motorcycle.
the tags are:
foot = designated
highway = path
name = Jewell Trail
sac_scale = mountain_hiking
The problem is that the newer Garmin units with the latest firmware (and Basecamp v 3.3) don’t observe the access = no mkgmap settings anymore.
A workaround is to select the avoidance of carpool lanes, this will block all roads with access = no (but unfortunately, even if they have motorcycle=yes :/)
