Serious Bug - Mkgmap creating map that puts news GPS (confirmed etrex 30, Oregon 550) into bootloop
Well two days ago someone told me, that if he puts my map onto his GPS it's not booting anymore (or bootlooping after trying to load maps). The really strange thing is, I cannot find out at all why this happens. If I only transfer half of the map, it is not bootlooping, if I transfer the other half, not bootlooping. If I transfer both halves as separate gmapsupp.img files, still okay. However if I transfer the map as one full gmapsupp.img - then neither Oregon 550 (newest beta firmware) nor etrex 30 (several firmwares tried) doesn't start anymore. It does not matter if I create the gmapsupp.img with Mapsource, Mapinstall/Basecamp or mkgmap. It does not matter if I create --index with mkgmap on sending it. And it's not about the integrated contourlines (7*.img) -- exclude them, same problem. So here is the file for testing (do not install it on internal memory, else your GPS device may be ready for sending it in to Garmin). _*/ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/mtbfrance_broke.exe/*_ (note simply unpack this installer with 7zip-full on Linux - its lzma packed). Note, old GPS devices like Vista HCx cope fine with this map. I more or less give up trying to find the fault. However as this is the first time since a very long time, mkgmap created maps can potentially break a Garmin GPS - I post it to the list without knowing a way to figure the problem out. It has nothing to do with my style either I would suppose, only map for me where this happens.
Hi
So here is the file for testing (do not install it on internal memory, else your GPS device may be ready for sending it in to Garmin). _*/ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/mtbfrance_broke.exe/*_ (note simply unpack this installer with 7zip-full on Linux - its lzma packed).
Well I've downloaded it, although I don't know if I will be able to do anything with it since I don't have an Oregon or new Etrex, so may not be able to reproduce. In fact I don't even have a large enough microSD card... Just to be clear if I do: mkgmap --latin1 --gmapsupp 6391*.img then that will produce a map that doesn't work? ..Steve
well I used: mkgmap.jar --family-id=6391 --description="some_name" --series-name="some_name" --family-name="some_name" --product-id=1 --gmapsupp 6391*.img clas*.TYP and that puts the GPS into bootloop. (Oregon and etrex 30...). (I don't think the .TYP-file can be in any way responsible, as it works on all other maps without probs, and also small extracts.. - nor the other options). As told, my old Vista HCx copes fine with the map. On 23.02.2012 15:40, Steve Ratcliffe wrote:
Hi
So here is the file for testing (do not install it on internal memory, else your GPS device may be ready for sending it in to Garmin). _*/ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/mtbfrance_broke.exe/*_ (note simply unpack this installer with 7zip-full on Linux - its lzma packed). Well I've downloaded it, although I don't know if I will be able to do anything with it since I don't have an Oregon or new Etrex, so may not be able to reproduce. In fact I don't even have a large enough microSD card...
Just to be clear if I do:
mkgmap --latin1 --gmapsupp 6391*.img
then that will produce a map that doesn't work?
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix, Someone on the Dutch forum.gps.nl reported that this is caused by a corrupt tile (either Corsica or the Bay of Biscay) in your Velomap/Openmtbmap. When he left it out there were no problems anymore on his Etrex 30.
That's not possible because also with new map data it's still broken and if I use halve of the tiles it's okay and also other halve is okay -- there must be some structrural problem - though maybe some tile together with a second is responsible - can you provide a link to the topic? On Feb 23, 2012 7:13 PM, "Minko" <ligfietser@online.nl> wrote:
Felix, Someone on the Dutch forum.gps.nl reported that this is caused by a corrupt tile (either Corsica or the Bay of Biscay) in your Velomap/Openmtbmap. When he left it out there were no problems anymore on his Etrex 30.
On 23/02/12 19:23, Felix Hartmann wrote:
That's not possible because also with new map data it's still broken and if I use halve of the tiles it's okay and also other halve is okay -- there must be some structrural problem - though maybe some tile
It might be that removing any tile allows it to work. I guess that the thread is: http://forum.gps.nl/viewtopic.php?f=75&t=36983 ..Steve
Yes, that's the thread, Jaap van Maanen wrote he has got no problem anymore if he deselected the Bay of Biscay tile. Steve wrote: It might be that removing any tile allows it to work. I guess that the thread is: http://forum.gps.nl/viewtopic.php?f=75&t=36983
On 23/02/12 20:32, Minko wrote:
Yes, that's the thread, Jaap van Maanen wrote he has got no problem anymore if he deselected the Bay of Biscay tile.
It wasn't clear which tile he meant as there are two that it could be. Or if he meant both as the last message seems to suggest it is both as it uses the word deselects in the plural (via google translate). There is mention of an attachment, but I don't see anything. ..Steve
Thats google's awful translation by Google ;-) He wrote that he had deselected the Bay of Biskay when sending the tiles with Mapsource.
On 23/02/12 20:54, Minko wrote:
Thats google's awful translation by Google ;-)
He wrote that he had deselected the Bay of Biskay when sending the tiles with Mapsource.
OK, but there are two tiles 63910019 63910035 both of which are almost empty and are both located in the bay of biscay. ..Steve
On a Dakota 20 I can confirm this behaviour. If I leave only tile 63910019 out of it, it still won't boot up. I did not try it without tile 63910035. With a smaller mapset with 63910019 and 63910035 and a few others, no problems. Also tried to leave out two other tiles in the north, but then it still won't boot.
I just tried - I left out the two main tiles of the Bay of Biscay, and it booted (and to confirm I created the gmapsupp.img with both mkgmap with and without address search, and also Mapsource). Leaving out either of the two tiles, So leaves us to wonder, why is it not booting with them. The main thing inside those two tiles, is the ferry line, go straight across. Is it possible, that we have to use shorter staight lines? Where could I patch mkgmap to split up straight lines say 5x as often? The other thing could be - that there must be at least one city POI in each tile (or at least any?? POI in each tile) - as both tiles don't have any city. And only one of the two tiles has a POI at all. I'll also try what happens if I create the map with default style-file. But I think it will crash the gps device too. BTW -- I split france from geofabrik with max-nodes=1200000 and maxnodes=1300000 and both results in the same problem. Or do we have to make sure, that mkgmap never creates such empty tiles? On 23.02.2012 23:44, Minko wrote:
On a Dakota 20 I can confirm this behaviour. If I leave only tile 63910019 out of it, it still won't boot up. I did not try it without tile 63910035. With a smaller mapset with 63910019 and 63910035 and a few others, no problems. Also tried to leave out two other tiles in the north, but then it still won't boot. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Bang, I think that's it. I now managed to sent a map including the bay of biscay (one tile), and looked if the other really small tiles included cities/islands. Found one that didn't, left it out and the GPS booted. IMHO (I'll try to simply include a city POI into the tiles of biscay) - we would need to make sure, that each tile has a city or island (0x650c)! Maybe that could be related to how the search function is organised? Loading maps the GPS usually tries to set up the POI index internally. Maybe that's why it crashes. Too few/no cities or no POI at all, and bang. My next try will be to simply include city POIs with gpsmapedit into each tile of the gulf of biscay, and recompile... On 24.02.2012 10:04, Felix Hartmann wrote:
I just tried - I left out the two main tiles of the Bay of Biscay, and it booted (and to confirm I created the gmapsupp.img with both mkgmap with and without address search, and also Mapsource). Leaving out either of the two tiles, So leaves us to wonder, why is it not booting with them.
The main thing inside those two tiles, is the ferry line, go straight across. Is it possible, that we have to use shorter staight lines? Where could I patch mkgmap to split up straight lines say 5x as often? The other thing could be - that there must be at least one city POI in each tile (or at least any?? POI in each tile) - as both tiles don't have any city. And only one of the two tiles has a POI at all.
I'll also try what happens if I create the map with default style-file. But I think it will crash the gps device too. BTW -- I split france from geofabrik with max-nodes=1200000 and maxnodes=1300000 and both results in the same problem.
Or do we have to make sure, that mkgmap never creates such empty tiles?
On 23.02.2012 23:44, Minko wrote:
On a Dakota 20 I can confirm this behaviour. If I leave only tile 63910019 out of it, it still won't boot up. I did not try it without tile 63910035. With a smaller mapset with 63910019 and 63910035 and a few others, no problems. Also tried to leave out two other tiles in the north, but then it still won't boot. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
But if you send just the two of those Bay of Biscay tiles or a bigger mapset with those two included, everything seems normal. It only happens with the big France mapset including those tiles.
Oh well, I can also send all of France, as long as I take out the 3rd tile, that contains not cities.... Maybe there are even more such tiles, however for all of them that I could identify, one thing was common -- and that is no city inside the whole tile. Maybe the free cgpsmapper version, is including the cgpsmapper text on 0xb00 for some reason, not only advertisement..... On 24.02.2012 11:20, Minko wrote:
But if you send just the two of those Bay of Biscay tiles or a bigger mapset with those two included, everything seems normal. It only happens with the big France mapset including those tiles. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Well I increased the maxnodes for the splitter, and even though the two tiles in the bay of Biscay, remained unchanged, it works without problems on my GPS now. The big problem remains, that for some countries with maxnodes 800000 I run into too large files, while for France (opposite side of the coin -- have a look into your maps of Europe - the smallest tiles will all be in France) with maxnodes 2400000 it compiles fine. I tried before with default style-file, and the map also crashed the GPS. So there is indeed the main problem, that the tiles become too small, and miss some information that they should include. Maybe somehow related to the POI index stuff?? I think the only real way out of it, would be to somehow merge mkgmap and mgkmap splitter functionality (e.g. somehow take into account the style-file for the splitters maxnode calculation). Or change mkgmap in such a way, that if a tile cannot be compiled because it is too big, it would automatically be split, and recompiled (but using a mapname that doesn't conflict...). On 24.02.2012 10:24, Felix Hartmann wrote:
Bang, I think that's it. I now managed to sent a map including the bay of biscay (one tile), and looked if the other really small tiles included cities/islands. Found one that didn't, left it out and the GPS booted.
IMHO (I'll try to simply include a city POI into the tiles of biscay) - we would need to make sure, that each tile has a city or island (0x650c)! Maybe that could be related to how the search function is organised? Loading maps the GPS usually tries to set up the POI index internally. Maybe that's why it crashes. Too few/no cities or no POI at all, and bang.
My next try will be to simply include city POIs with gpsmapedit into each tile of the gulf of biscay, and recompile...
On 24.02.2012 10:04, Felix Hartmann wrote:
I just tried - I left out the two main tiles of the Bay of Biscay, and it booted (and to confirm I created the gmapsupp.img with both mkgmap with and without address search, and also Mapsource). Leaving out either of the two tiles, So leaves us to wonder, why is it not booting with them.
The main thing inside those two tiles, is the ferry line, go straight across. Is it possible, that we have to use shorter staight lines? Where could I patch mkgmap to split up straight lines say 5x as often? The other thing could be - that there must be at least one city POI in each tile (or at least any?? POI in each tile) - as both tiles don't have any city. And only one of the two tiles has a POI at all.
I'll also try what happens if I create the map with default style-file. But I think it will crash the gps device too. BTW -- I split france from geofabrik with max-nodes=1200000 and maxnodes=1300000 and both results in the same problem.
Or do we have to make sure, that mkgmap never creates such empty tiles?
On 23.02.2012 23:44, Minko wrote:
On a Dakota 20 I can confirm this behaviour. If I leave only tile 63910019 out of it, it still won't boot up. I did not try it without tile 63910035. With a smaller mapset with 63910019 and 63910035 and a few others, no problems. Also tried to leave out two other tiles in the north, but then it still won't boot. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
If your observation of missing place nodes is right,maybe you can try to render place=bay or place=sea? http://www.openstreetmap.org/browse/node/1195287137 I will try to render those next time with my maps, was missing the sea/bay names anyway and maybe this will prevent those booting problems too.
On 24.02.2012 13:25, Minko wrote:
If your observation of missing place nodes is right,maybe you can try to render place=bay or place=sea?
http://www.openstreetmap.org/browse/node/1195287137
I will try to render those next time with my maps, was missing the sea/bay names anyway and maybe this will prevent those booting problems too.
Well I'll include them, but I also had too small tiles inside the mountains at the boarder (one of the 3 main offending tiles was inside the mountains). I think there is some problem with indexed pois/adresses without the city that belongs to them inside the same or neighbouring tile?? Fact is, those nearly empty tiles are the main problem - and somewhere mkgmap has a big bug related to it.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 24/02/12 12:31, Felix Hartmann wrote:
On 24.02.2012 13:25, Minko wrote:
If your observation of missing place nodes is right,maybe you can try to render place=bay or place=sea?
http://www.openstreetmap.org/browse/node/1195287137
I will try to render those next time with my maps, was missing the sea/bay names anyway and maybe this will prevent those booting problems too.
Well I'll include them, but I also had too small tiles inside the mountains at the boarder (one of the 3 main offending tiles was inside the mountains). I think there is some problem with indexed pois/adresses without the city that belongs to them inside the same or neighbouring tile?? Fact is, those nearly empty tiles are the main problem - and somewhere mkgmap has a big bug related to it.
You are making progress! Unfortunately the map works fine on my nuvi and legend (unsurprising) so I can't join in the investigation. So far we know that if you omit certain files then it works. But if you send those files by themselves it also works. This is no use; we need to know the smallest list of tiles that does *not* work. What I would do is: Start with a all the tiles from ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/mtbfrance_broke.exe Remove some tiles from the list. Send that list to the SD card, if it now works, put the removed tiles back on the list and remove fewer tiles, or some different ones. If the map doesn't work, them remove more tiles from the list. Keep a record of what works and what doesn't using the list of tiles that were sent and if the map worked or not. Since it appears to be related to small tiles, then try to see how many large files you can remove and have the map still fail. It will be a pain to do, but the work can be shared as long as you are all working from the same set of tiles. Every time you find a list of tiles that is shorter and does not work, then let everyone else that is working on it know, so they can start from that list. So far all I have gathered from the discussion is the following tile lists and their results: FAIL: 63910000.img 63910036.img 63910072.img 63910108.img 63910144.img 63910180.img 63910216.img 63910001.img 63910037.img 63910073.img 63910109.img 63910145.img 63910181.img 63910217.img 63910002.img 63910038.img 63910074.img 63910110.img 63910146.img 63910182.img 63910218.img 63910003.img 63910039.img 63910075.img 63910111.img 63910147.img 63910183.img 63910219.img 63910004.img 63910040.img 63910076.img 63910112.img 63910148.img 63910184.img 63910220.img 63910005.img 63910041.img 63910077.img 63910113.img 63910149.img 63910185.img 63910221.img 63910006.img 63910042.img 63910078.img 63910114.img 63910150.img 63910186.img 63910222.img 63910007.img 63910043.img 63910079.img 63910115.img 63910151.img 63910187.img 63910223.img 63910008.img 63910044.img 63910080.img 63910116.img 63910152.img 63910188.img 63910224.img 63910009.img 63910045.img 63910081.img 63910117.img 63910153.img 63910189.img 63910225.img 63910010.img 63910046.img 63910082.img 63910118.img 63910154.img 63910190.img 63910226.img 63910011.img 63910047.img 63910083.img 63910119.img 63910155.img 63910191.img 63910227.img 63910012.img 63910048.img 63910084.img 63910120.img 63910156.img 63910192.img 63910228.img 63910013.img 63910049.img 63910085.img 63910121.img 63910157.img 63910193.img 63910229.img 63910014.img 63910050.img 63910086.img 63910122.img 63910158.img 63910194.img 63910230.img 63910015.img 63910051.img 63910087.img 63910123.img 63910159.img 63910195.img 63910231.img 63910016.img 63910052.img 63910088.img 63910124.img 63910160.img 63910196.img 63910232.img 63910017.img 63910053.img 63910089.img 63910125.img 63910161.img 63910197.img 63910233.img 63910018.img 63910054.img 63910090.img 63910126.img 63910162.img 63910198.img 63910234.img 63910019.img 63910055.img 63910091.img 63910127.img 63910163.img 63910199.img 63910235.img 63910020.img 63910056.img 63910092.img 63910128.img 63910164.img 63910200.img 63910236.img 63910021.img 63910057.img 63910093.img 63910129.img 63910165.img 63910201.img 63910237.img 63910022.img 63910058.img 63910094.img 63910130.img 63910166.img 63910202.img 63910238.img 63910023.img 63910059.img 63910095.img 63910131.img 63910167.img 63910203.img 63910239.img 63910024.img 63910060.img 63910096.img 63910132.img 63910168.img 63910204.img 63910240.img 63910025.img 63910061.img 63910097.img 63910133.img 63910169.img 63910205.img 63910241.img 63910026.img 63910062.img 63910098.img 63910134.img 63910170.img 63910206.img 63910242.img 63910027.img 63910063.img 63910099.img 63910135.img 63910171.img 63910207.img 63910243.img 63910028.img 63910064.img 63910100.img 63910136.img 63910172.img 63910208.img 63910244.img 63910029.img 63910065.img 63910101.img 63910137.img 63910173.img 63910209.img 63910245.img 63910030.img 63910066.img 63910102.img 63910138.img 63910174.img 63910210.img 63910246.img 63910031.img 63910067.img 63910103.img 63910139.img 63910175.img 63910211.img 63910247.img 63910032.img 63910068.img 63910104.img 63910140.img 63910176.img 63910212.img 63910248.img 63910033.img 63910069.img 63910105.img 63910141.img 63910177.img 63910213.img 63910249.img 63910034.img 63910070.img 63910106.img 63910142.img 63910178.img 63910214.img 63910250.img 63910035.img 63910071.img 63910107.img 63910143.img 63910179.img 63910215.img 63910251.img WORK: 63910000.img 63910036.img 63910072.img 63910108.img 63910144.img 63910180.img 63910216.img 63910001.img 63910037.img 63910073.img 63910109.img 63910145.img 63910181.img 63910217.img 63910002.img 63910038.img 63910074.img 63910110.img 63910146.img 63910182.img 63910218.img 63910003.img 63910039.img 63910075.img 63910111.img 63910147.img 63910183.img 63910219.img 63910004.img 63910040.img 63910076.img 63910112.img 63910148.img 63910184.img 63910220.img 63910005.img 63910041.img 63910077.img 63910113.img 63910149.img 63910185.img 63910221.img 63910006.img 63910042.img 63910078.img 63910114.img 63910150.img 63910186.img 63910222.img 63910007.img 63910043.img 63910079.img 63910115.img 63910151.img 63910187.img 63910223.img 63910008.img 63910044.img 63910080.img 63910116.img 63910152.img 63910188.img 63910224.img 63910009.img 63910045.img 63910081.img 63910117.img 63910153.img 63910189.img 63910225.img 63910010.img 63910046.img 63910082.img 63910118.img 63910154.img 63910190.img 63910226.img 63910011.img 63910047.img 63910083.img 63910119.img 63910155.img 63910191.img 63910227.img 63910012.img 63910048.img 63910084.img 63910120.img 63910156.img 63910192.img 63910228.img 63910013.img 63910049.img 63910085.img 63910121.img 63910157.img 63910193.img 63910229.img 63910014.img 63910050.img 63910086.img 63910122.img 63910158.img 63910194.img 63910230.img 63910015.img 63910051.img 63910087.img 63910123.img 63910159.img 63910195.img 63910231.img 63910016.img 63910052.img 63910088.img 63910124.img 63910160.img 63910196.img 63910232.img 63910017.img 63910053.img 63910089.img 63910125.img 63910161.img 63910197.img 63910233.img 63910018.img 63910054.img 63910090.img 63910126.img 63910162.img 63910198.img 63910234.img 63910055.img 63910091.img 63910127.img 63910163.img 63910199.img 63910235.img 63910020.img 63910056.img 63910092.img 63910128.img 63910164.img 63910200.img 63910236.img 63910021.img 63910057.img 63910093.img 63910129.img 63910165.img 63910201.img 63910237.img 63910022.img 63910058.img 63910094.img 63910130.img 63910166.img 63910202.img 63910238.img 63910023.img 63910059.img 63910095.img 63910131.img 63910167.img 63910203.img 63910239.img 63910024.img 63910060.img 63910096.img 63910132.img 63910168.img 63910204.img 63910240.img 63910025.img 63910061.img 63910097.img 63910133.img 63910169.img 63910205.img 63910241.img 63910026.img 63910062.img 63910098.img 63910134.img 63910170.img 63910206.img 63910242.img 63910027.img 63910063.img 63910099.img 63910135.img 63910171.img 63910207.img 63910243.img 63910028.img 63910064.img 63910100.img 63910136.img 63910172.img 63910208.img 63910244.img 63910029.img 63910065.img 63910101.img 63910137.img 63910173.img 63910209.img 63910245.img 63910030.img 63910066.img 63910102.img 63910138.img 63910174.img 63910210.img 63910246.img 63910031.img 63910067.img 63910103.img 63910139.img 63910175.img 63910211.img 63910247.img 63910032.img 63910068.img 63910104.img 63910140.img 63910176.img 63910212.img 63910248.img 63910033.img 63910069.img 63910105.img 63910141.img 63910177.img 63910213.img 63910249.img 63910034.img 63910070.img 63910106.img 63910142.img 63910178.img 63910214.img 63910250.img 63910071.img 63910107.img 63910143.img 63910179.img 63910215.img 63910251.img WORK: 63910019.img 63910035.img ..Steve
This is what I have tested: Fail: Whole France minus 63910019.img Fail: Whole France minus 63910035.img Fail: Whole France minus GB-Brighton (63910189) / FR-Caen (63910093) Work: france (63910019)/IT-Milano (63910066) / ES-Gijon (63910035) Work: 63910019 + 63910035 + a few other tiles along the west coast
Ups, I don't know what I was doing before, but now if I didn't somehow seriously harm my GPS -- it ain't booting at all if the only tile is: 63910066.img !!!! This tile contains only POI of type 0x11710 in resolution 24 Maybe if we have "3byte" POI, there must be place, or "2byte" -- 0x000?? -- POI? However if I add some other tiles to 0066 it will start. But this is the only tile if alone inside a gmapsupp.img, it will stop the device from booting. The big problem on that maptile is of course bad data -- but still it shouldn't crash the GPS device (and doesn't do if in the right combination with other maps..).
Great! Does france - 0066 work? Minko reported that 0066 plus the two Biscay files that have no cities works, so that suggests it does not need cities to make it work again. Felix Hartmann <extremecarver@gmail.com> wrote:
Ups, I don't know what I was doing before, but now if I didn't somehow seriously harm my GPS -- it ain't booting at all if the only tile is: 63910066.img !!!!
This tile contains only POI of type 0x11710 in resolution 24 Maybe if we have "3byte" POI, there must be place, or "2byte" -- 0x000?? -- POI?
However if I add some other tiles to 0066 it will start. But this is the only tile if alone inside a gmapsupp.img, it will stop the device from booting. The big problem on that maptile is of course bad data -- but still it shouldn't crash the GPS device (and doesn't do if in the right combination with other maps..). _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Oh damn, I tried again, and now the exact maps that didn't work before, worked... Might be also somehow related to last startup before... So the only thing I have found out so far, that is really problematic are really small tiles. So I think we should simply try to setup some mechanism that such small tiles can be avoided (by somehow integrating splitter into mkgmap so one can choose higher maxnodes, without running the risk of loosing tiles alltogether... - becauser higher maxnodes with everything else equal, solves the problem). Also now due to inserting/taking out the micro-sd all the time it broke now.. So I give up... On 24.02.2012 17:42, Steve Ratcliffe wrote:
Great! Does france - 0066 work?
Minko reported that 0066 plus the two Biscay files that have no cities works, so that suggests it does not need cities to make it work again.
Felix Hartmann<extremecarver@gmail.com> wrote:
Ups, I don't know what I was doing before, but now if I didn't somehow seriously harm my GPS -- it ain't booting at all if the only tile is: 63910066.img !!!!
This tile contains only POI of type 0x11710 in resolution 24 Maybe if we have "3byte" POI, there must be place, or "2byte" -- 0x000?? -- POI?
However if I add some other tiles to 0066 it will start. But this is the only tile if alone inside a gmapsupp.img, it will stop the device from booting. The big problem on that maptile is of course bad data -- but still it shouldn't crash the GPS device (and doesn't do if in the right combination with other maps..). _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix, Do you use no-trim in your splitter parameters and how does your generate-sea parameters looks like? Maybe a European coastline file will help? Your sea and coastline will definitely look better with it (it now shows land in the Bay of Biscay) and maybe these bugs will be solved too.
No I used neither. and my generate-sea parameters are: --generate-sea=extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=50,fbthres=50,fbratio=0.5 I don't mind that much when sea is empty. Sea has not much real use anyhow except looking nice. As for the tiles being too small - yeah it's right. But I still think it has something to do with it. I now rerun France with max-nodes twice as high - to see if problems are gone then (I would assume so)... I'm still very positive that is has something to do with the POI index being empty or nonexistent in those tiles. The thing is, if you split the map in two halves - and send them in separate gmapsupp.img files, but at the same time, then there is no crash. So it seems at some point the GPS devices crash down after X errors, but the errors are counted per gmapsupp or mapset (I could try what happens if I merge the two gmapsupp.img into 1 gmapsupp.img but with then of course different FID. On 24.02.2012 11:39, Minko wrote:
Felix, Do you use no-trim in your splitter parameters and how does your generate-sea parameters looks like? Maybe a European coastline file will help? Your sea and coastline will definitely look better with it (it now shows land in the Bay of Biscay) and maybe these bugs will be solved too.
Well I found another strange thing inside that tile. I'm not sure if the automatic splitting of lines is working correctly. In order to map ferries - I use two different line types. a) 0x13 routable b) 0x10606 non routable However the 10606 is split twice as often as 0x13. How comes that the routable line gets split less often than a non routable line. In the end all this splitting is acutally done by mkgmap - the ferry line inside osm is not split at all.
participants (3)
-
Felix Hartmann -
Minko -
Steve Ratcliffe