I’ve also received several emails by different users about this problem and been looking at this problem for a while, but didn’t spot the cause earlier. Now I think I found it and implemented a fix.
When Splitter is called to subsplit a tile but cannot find a good solution it will produce only one result (instead of the two it is ordered to produce). This is spotted by the build-script which then simply re-renders the original tile without further subsplitting. However the sub-split attempt leaves two ‘orphaned’ files behind which aren’t cleaned-up though cause double use of a tile number later on, e.g. tile number 63242074 is defined twice as US-Long Beach and US-Los Angeles. The same happens with Istanbul and other places as described by DavidOb a few posts above. I thought that this problem had been fixed with an earlier update, but clearly it didn’t.
The problem should be fixed by removing the subsplit files which are not going to be rendered. When the Openfietsmap_lite render process is finished a new map update will be started. I hope that solves this issue.
Good to have a fall-back server then, even if it’s not the fastest
Anyway, I’m in the process of moving the render chain to the new server: It has much more ram, cpu-cores and disk space and so is able to do much more in parallel. That’ll free one harddisk in the osm server allowing me to use it for sharing country maps. This means there will be twice the I/O bandwidth available for country (and OFM) downloaders. But several other things need to be in place before this happens.
For those familiar with Linux, I’ve rarely seen a quad-core server having more then 100% I/O-wait, the last few hours it was at 400%. All four cores are 100% waiting for the disks to return the requested data that is needed to do any useful work. In other words: all cores were starved of data and could do nothing but wait almost 100% of the time.
A first attempt failed due to only one of the two orphaned files being cleaned-up. With a second attempt both files are cleaned-up and the problem is solved starting map version: 13-08-2014
I downloaded and installed an .img file of Canada on my Garmin. The map is present on the gps and I enabled it. When I zoom on an area, I only see some part of the map but not the full map. If I change the zoom level I will see more or less part with sometimes previously visible area which will disappear and others which will appear. The data seem to be present but not visible everywhere, since I can simulate a trip from one point to another even in invisible area. In the part where no information is displayed I can only see the path of the planned trip.
I checked the map using BaseCamp and I can see all the data without trouble.
I also tried to install an .img file from “www.osmmaps.com” and I have the same problem. I tried to reset the gps but it doesn’t change anything.
Do you have any idea of where the problem could come from?
Hard to say…Maybe you have duplicate maptiles installed try javawa device manager, www.javawa.nl/jdm_en.html to check for map errors. Or maybe your sd card can be faulty, did you try another sd card?
I tried javawa and there is no map error.
The map is saved directly on the internal gps memory and I tried an old map from US (bought from Garmin) and everything is fine. Only osm maps have the problem.
Can you give the location (permalink from osm.org) so I can check if I can reproduce it?
Which map did you exactly download (generic, generic new style?)
Do you see this happening everywhere in Canada, or at particular spots?
If it is everywhere, maybe your device cannot cope with mkgmap generated maps.
If you see this only at some places, maybe there is a feature on OSM that is messing up the rendering on other devices too.
So if you can send a link (something like http://www.openstreetmap.org/#map=14/49.2560/-123.1131)) of an area that disappears I can check this on my device.
Just “Canada” is way too big, sorry.
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.