mkgmap and "memory-full-error"

Hi! I've downgraded my Oregon 450 from firmware 6.xx to 5.50, because this was the last firmware without the activity routing. With the activity routing the routing of my maps was broken (car routing over steps and ignoring of "access=no"). With the firmware 5.50 the routing was correct again. But after a few weeks I get the famous memory-full-error. Now I read that in the past several people reported this error with maps made with mkgmap. The only advice I found, was to use an recent firmware. Is there a known bug in mkgmap? How can I avoid the error? Christian

Hi, sounds like you copy the img file to the internal memory of the device and your device records tracks. The easiest solution is to use an SD card for the img file. Alternative: Remove saved tracks to free memory. Gerd Christian H. Bruhn wrote
Hi!
I've downgraded my Oregon 450 from firmware 6.xx to 5.50, because this was the last firmware without the activity routing. With the activity routing the routing of my maps was broken (car routing over steps and ignoring of "access=no").
With the firmware 5.50 the routing was correct again. But after a few weeks I get the famous memory-full-error. Now I read that in the past several people reported this error with maps made with mkgmap.
The only advice I found, was to use an recent firmware.
Is there a known bug in mkgmap? How can I avoid the error?
Christian
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/mkgmap-and-memory-full-error-tp5763280p576328... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Am 29.05.2013 23:41, schrieb GerdP: Hello no, Gerd, this is a problem with some maps build with mkgmap, but it is not seen on every Oregon. It also happened, if the maps are installed on the SD-card. I have never seen this with my Oregon. On the Garmin-Forum there are a lot of threads with this topic. @Christian: activities are another problem, IMHO it is something changed in the original Garmin-Maps, to prefer some ways for different use. Maybe a special tag or similar Bernd
Hi,
sounds like you copy the img file to the internal memory of the device and your device records tracks. The easiest solution is to use an SD card for the img file. Alternative: Remove saved tracks to free memory.
Gerd
Christian H. Bruhn wrote
Hi!
I've downgraded my Oregon 450 from firmware 6.xx to 5.50, because this was the last firmware without the activity routing. With the activity routing the routing of my maps was broken (car routing over steps and ignoring of "access=no").
With the firmware 5.50 the routing was correct again. But after a few weeks I get the famous memory-full-error. Now I read that in the past several people reported this error with maps made with mkgmap.
The only advice I found, was to use an recent firmware.
Is there a known bug in mkgmap? How can I avoid the error?
Christian
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/mkgmap-and-memory-full-error-tp5763280p576328... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On Thu, May 30, Bernd Weigelt wrote:
Am 29.05.2013 23:41, schrieb GerdP:
Hello
no, Gerd, this is a problem with some maps build with mkgmap, but it is not seen on every Oregon. It also happened, if the maps are installed on the SD-card.
Wild guess by me: Oregons like the 62 have, beside the internal, accessible memory, another, hidden internal memory, where it seems they store index and other informations about the installed maps and gpx files. Garmin maps seems to have a version number, which you can set with mkgmap, too, but most map developer don't do and increase this. So the firmware sometimes get confused if you update the map, but the version number stays identical. The 62 has the same problem with gpx files, too, if the content changes, but not the name: for some people the devices crashes regular in this case, while other have no problem. Every time I have the feeling with my 62, that the internal cache is out of sync (for the maps I see this if POI searches suddenly take much longer then before), I save my profile, do a hard reset, restore the profile. And everything is back to normal. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

Hi
Wild guess by me: Oregons like the 62 have, beside the internal, accessible memory, another, hidden internal memory, where it seems they store index and other informations about the installed maps and gpx files.
I would agree that the new units seem to store or cache some details of the map. The thing that I've noticed is this. I will be trying to track down a bug in the index and so have the same map compiled with two different versions of mkgmap, one which has the bug and one with a possible fix. - Try the original map and see the bug - Try the new map and see the bug has gone - Go back to the orignal map - bug is still gone!! - Recompile the original map and load it again - bug is back. The only difference that re-compiling should make is that the timestamps within the gmapsupp.img are different. The timestamp of the gmapsupp.img itself will always be greater because I always copy over the previous one. So these things may or may not be related, but if anyone does see something wierd and inconsistant on one of the newer devices, then it is worth trying to re-compile the map and re-load to see if that helps. ..Steve

Hi Thorsten, if you say, that changing the version which every update prevents the problem, then maybe --product-version should be set by default to yyyymmdd (date of generation) and not to 1. Henning Am 30.05.2013 12:59, schrieb Thorsten Kukuk:
On Thu, May 30, Bernd Weigelt wrote:
Am 29.05.2013 23:41, schrieb GerdP:
Hello
no, Gerd, this is a problem with some maps build with mkgmap, but it is not seen on every Oregon. It also happened, if the maps are installed on the SD-card. Wild guess by me: Oregons like the 62 have, beside the internal, accessible memory, another, hidden internal memory, where it seems they store index and other informations about the installed maps and gpx files. Garmin maps seems to have a version number, which you can set with mkgmap, too, but most map developer don't do and increase this. So the firmware sometimes get confused if you update the map, but the version number stays identical. The 62 has the same problem with gpx files, too, if the content changes, but not the name: for some people the devices crashes regular in this case, while other have no problem. Every time I have the feeling with my 62, that the internal cache is out of sync (for the maps I see this if POI searches suddenly take much longer then before), I save my profile, do a hard reset, restore the profile. And everything is back to normal.
Thorsten

There is a workaround for the activity routing, which means you have to use carpool avoidance in the car profile. This avoids all roads tagged with either access=no OR motorcar=no (dont know what happens with motorcar=yes & access=no). It really depends now how you use your map. Is it for car navgation or also for cycling? Garmin implemented this carpool avoidance by default in the bicycle profile. Which means that the default rules access=no & bicycle=yes do not longer work as expected in the latest Garmins / Basecamp when you select bicycle as activity (bicycle=yes is ignored).
I've downgraded my Oregon 450 from firmware 6.xx to 5.50, because this was the last firmware without the activity routing. With the activity routing the routing of my maps was broken (car routing over steps and ignoring of "access=no").
With the firmware 5.50 the routing was correct again. But after a few weeks I get the famous memory-full-error. Now I read that in the past several people reported this error with maps made with mkgmap.
The only advice I found, was to use an recent firmware.
Is there a known bug in mkgmap? How can I avoid the error?
Christian

Hi Christian, I experienced the memory full error on my Oregon 400t some time ago. It seems that it was caused by a broken map, since never did it occur again after replacing that one map with a newer version. Kind regards, Bernhard Am 29.05.2013 23:17, schrieb Christian H. Bruhn:
Hi!
I've downgraded my Oregon 450 from firmware 6.xx to 5.50, because this was the last firmware without the activity routing. With the activity routing the routing of my maps was broken (car routing over steps and ignoring of "access=").
With the firmware 5.50 the routing was correct again. But after a few weeks I get the famous memory-full-error. Now I read that in the past several people reported this error with maps made with mkgmap.
The only advice I found, was to use an recent firmware.
Is there a known bug in mkgmap? How can I avoid the error?
Christian
participants (8)
-
Bernd Weigelt
-
Bernhard Hiller
-
Christian H. Bruhn
-
GerdP
-
Henning Scholland
-
Minko
-
Steve Ratcliffe
-
Thorsten Kukuk