Error on MapSource with r1919
MapSource crashes if I try to activate Spain map generated with r1919 throwing a message mentioning DSK_FIRSTIMAGESECTOR.CPP. The same input files compiled with r1916 work fine. Other maps like Morocco, Portugal, Canary Islands, all of them quite smaller, work fine with r1919.
El 20/04/11 11:28, Carlos Dávila escribió:
MapSource crashes if I try to activate Spain map generated with r1919 throwing a message mentioning DSK_FIRSTIMAGESECTOR.CPP. The same input files compiled with r1916 work fine. Other maps like Morocco, Portugal, Canary Islands, all of them quite smaller, work fine with r1919. map compiled with: java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --area-name=España --family-name="OpenStreetMap España" --family-id=14 --product-id=1 --series-name="OSM-España" --overview-mapname=55140000 --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --merge-lines --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio --delete-tags-file=quitar_is_in -c spain.args
2011/4/20 Carlos Dávila <cdavilam@orangecorreo.es>:
El 20/04/11 11:28, Carlos Dávila escribió:
MapSource crashes if I try to activate Spain map generated with r1919 throwing a message mentioning DSK_FIRSTIMAGESECTOR.CPP. The same input files compiled with r1916 work fine. Other maps like Morocco, Portugal, Canary Islands, all of them quite smaller, work fine with r1919. map compiled with: java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --area-name=España --family-name="OpenStreetMap España" --family-id=14 --product-id=1 --series-name="OSM-España" --overview-mapname=55140000 --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --merge-lines --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio --delete-tags-file=quitar_is_in -c spain.args
Can you give the filesize of the problem file and the largest good file? I tested the patch up with up to ~1.3G gmapsupp.img files. Also, I only tested these files with my eTrex and with basecamp, which can read gmapsupp.img files from SD cards. How are you using the gmapsupp.img file with MapSource? I'm just curious and still learning about MapSource :-) Cheers, Andy
El 20/04/11 16:01, Andy Allan escribió:
2011/4/20 Carlos Dávila<cdavilam@orangecorreo.es>:
El 20/04/11 11:28, Carlos Dávila escribió:
MapSource crashes if I try to activate Spain map generated with r1919 throwing a message mentioning DSK_FIRSTIMAGESECTOR.CPP. The same input files compiled with r1916 work fine. Other maps like Morocco, Portugal, Canary Islands, all of them quite smaller, work fine with r1919. map compiled with: java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --area-name=España --family-name="OpenStreetMap España" --family-id=14 --product-id=1 --series-name="OSM-España" --overview-mapname=55140000 --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --merge-lines --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio --delete-tags-file=quitar_is_in -c spain.args Can you give the filesize of the problem file and the largest good file? I tested the patch up with up to ~1.3G gmapsupp.img files. Failing input osm.pbf 181 MB split into 12 tiles. Resulting gmapsupp.img ~150 MB Working input osm.pbf 17 MB split into 2 tiles. Also, I only tested these files with my eTrex and with basecamp, which can read gmapsupp.img files from SD cards. How are you using the gmapsupp.img file with MapSource? I'm just curious and still learning about MapSource :-) I don't use gmapsupp.img files in MapSource but individual tiles imgs + overview, tdb, etc.
On Wed, Apr 20, 2011 at 11:28:31AM +0200, Carlos Dávila wrote:
MapSource crashes if I try to activate Spain map generated with r1919 throwing a message mentioning DSK_FIRSTIMAGESECTOR.CPP.
This is the likely culprit: ------------------------------------------------------------------------ r1919 | steve | 2011-04-19 22:58:31 +0300 (Tue, 19 Apr 2011) | 3 lines Changed paths: M /trunk/src/uk/me/parabola/imgfmt/sys/ImgHeader.java Re-write "partition" size to follow the standard CHS algorithm as opposed to my previous complete guess as to how it worked. ------------------------------------------------------------------------ Other changes since r1916 were my addition of some --style=route-* files in r1917 and r1918. Marko
El 20/04/11 12:00, Marko Mäkelä escribió:
On Wed, Apr 20, 2011 at 11:28:31AM +0200, Carlos Dávila wrote:
MapSource crashes if I try to activate Spain map generated with r1919 throwing a message mentioning DSK_FIRSTIMAGESECTOR.CPP. This is the likely culprit:
------------------------------------------------------------------------ r1919 | steve | 2011-04-19 22:58:31 +0300 (Tue, 19 Apr 2011) | 3 lines Changed paths: M /trunk/src/uk/me/parabola/imgfmt/sys/ImgHeader.java
Re-write "partition" size to follow the standard CHS algorithm as opposed to my previous complete guess as to how it worked. ------------------------------------------------------------------------
Other changes since r1916 were my addition of some --style=route-* files in r1917 and r1918. I know you are innocent Marko ;-) , but my script updates mkgmap daily and so today it jumped from 1916 to 1919.
I have the same problem with Mapsource here. Since r1919 Mapsource crashes again with OSM Europe, when you try to select tiles to be uploaded to the GPS. You can view the tiles, zoom in and out. All fine, but as soon as you select one tile Mapsosurce crashes. Yet the error is different than the last time. It's not DSK_PRIVPARTITION.CPP-312-6.16.3.0 anymore but the following: Problemsignatur: Problemereignisname: BEX Anwendungsname: MapSource.exe Anwendungsversion: 6.16.3.0 Anwendungszeitstempel: 4cb7231f Fehlermodulname: MapSource.exe Fehlermodulversion: 6.16.3.0 Fehlermodulzeitstempel: 4cb7231f Ausnahmeoffset: 00850a8b Ausnahmecode: c0000417 Ausnahmedaten: 00000000 Betriebsystemversion: 6.1.7601.2.1.0.256.1 Gebietsschema-ID: 1031 Zusatzinformation 1: 9738 Zusatzinformation 2: 9738xxxd30ecxxxc669fe3exxxf68aad Zusatzinformation 3: a536 Zusatzinformation 4: a536xxxa446cxxxf34b149dxxx3c718f The last change to the ImgHeader.java seemed to cause the problem. No single tile is >50 MB, osmmap_mdr.img ca. 251 MB. So the absolute file size shouldn't be the problem. Just another thought ... could it be that C/H/S information should be calculated dynamically based on the actual size of a .img-file? Maybe this could save memory on a GPS when the tiles are loaded ... this is speculation since I don't know exactly how this is implemented. Peter Am 20.04.2011 21:38, schrieb Carlos Dávila:
El 20/04/11 12:00, Marko Mäkelä escribió:
On Wed, Apr 20, 2011 at 11:28:31AM +0200, Carlos Dávila wrote:
MapSource crashes if I try to activate Spain map generated with r1919 throwing a message mentioning DSK_FIRSTIMAGESECTOR.CPP. This is the likely culprit:
------------------------------------------------------------------------ r1919 | steve | 2011-04-19 22:58:31 +0300 (Tue, 19 Apr 2011) | 3 lines Changed paths: M /trunk/src/uk/me/parabola/imgfmt/sys/ImgHeader.java
Re-write "partition" size to follow the standard CHS algorithm as opposed to my previous complete guess as to how it worked. ------------------------------------------------------------------------
Other changes since r1916 were my addition of some --style=route-* files in r1917 and r1918. I know you are innocent Marko ;-) , but my script updates mkgmap daily and so today it jumped from 1916 to 1919.
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hello
and out. All fine, but as soon as you select one tile Mapsosurce crashes.
Ahh, that is a useful observation, thanks.
Just another thought ... could it be that C/H/S information should be calculated dynamically based on the actual size of a .img-file? Maybe this could save memory on a GPS when the tiles are loaded ... this is speculation since I don't know exactly how this is implemented.
Yes it should be. I just hoped that it would not be required, as it always worked when the max size was smaller. ;) I'll see what it would take to get the size into the header. ..Steve
El 27/04/11 20:33, Steve Ratcliffe escribió:
Hello
and out. All fine, but as soon as you select one tile Mapsosurce crashes. Ahh, that is a useful observation, thanks.
Just another thought ... could it be that C/H/S information should be calculated dynamically based on the actual size of a .img-file? Maybe this could save memory on a GPS when the tiles are loaded ... this is speculation since I don't know exactly how this is implemented. Yes it should be. I just hoped that it would not be required, as it always worked when the max size was smaller. ;)
I'll see what it would take to get the size into the header. After merging changes from trunk to locator branch I have the same problem with the mkgmap-locator. Is there any other information I can supply or any test to run to help debugging this issue?
Hi
I'll see what it would take to get the size into the header. After merging changes from trunk to locator branch I have the same problem with the mkgmap-locator. Is there any other information I can supply or any test to run to help debugging this issue?
The puzzle is why no one else sees this (or do they?!). What version of MapSource are you using? Currently the header information is written before the size is known, so I might have to make a temporary fix, that allows the gmapsupp and similar files to be larger while reducing the max size of tiles. ..Steve
El 03/05/11 17:56, Steve Ratcliffe escribió:
Hi
I'll see what it would take to get the size into the header. After merging changes from trunk to locator branch I have the same problem with the mkgmap-locator. Is there any other information I can supply or any test to run to help debugging this issue? The puzzle is why no one else sees this (or do they?!).
What version of MapSource are you using? 6.13.7 on debian under wine Currently the header information is written before the size is known, so I might have to make a temporary fix, that allows the gmapsupp and similar files to be larger while reducing the max size of tiles. As I only have this problem with Spain map, which I compile from tiles obtained with a high maxnodes, I tried reducing it in splitter and now I can open the map in MapSource, so the problem seems to be in the size of the input data.
El 03/05/11 18:56, Carlos Dávila escribió:
El 03/05/11 17:56, Steve Ratcliffe escribió:
Hi
I'll see what it would take to get the size into the header. After merging changes from trunk to locator branch I have the same problem with the mkgmap-locator. Is there any other information I can supply or any test to run to help debugging this issue? The puzzle is why no one else sees this (or do they?!).
What version of MapSource are you using? 6.13.7 on debian under wine Currently the header information is written before the size is known, so I might have to make a temporary fix, that allows the gmapsupp and similar files to be larger while reducing the max size of tiles. As I only have this problem with Spain map, which I compile from tiles obtained with a high maxnodes, I tried reducing it in splitter and now I can open the map in MapSource, so the problem seems to be in the size of the input data.
Forget it, I used the wrong jar file. The problem persists. Sorry for the false information.
Hi
Just another thought ... could it be that C/H/S information should be calculated dynamically based on the actual size of a .img-file? Maybe this could save memory on a GPS when the tiles are loaded ... this is speculation since I don't know exactly how this is implemented. Yes it should be. I just hoped that it would not be required, as it always worked when the max size was smaller. ;)
I'll see what it would take to get the size into the header. After merging changes from trunk to locator branch I have the same problem with the mkgmap-locator. Is there any other information I can supply or any test to run to help debugging this issue?
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
OK the attached patch should now take into account the exact size of the file when setting the 'partition size' in the header. There is a minimum size of 2048 512 byte sectors, anything larger than that is calculated just a little larger, so any mistake will cause a problem. Works for me so far. ..Steve
El 04/05/11 15:18, Steve Ratcliffe escribió:
Hi
Just another thought ... could it be that C/H/S information should be calculated dynamically based on the actual size of a .img-file? Maybe this could save memory on a GPS when the tiles are loaded ... this is speculation since I don't know exactly how this is implemented. Yes it should be. I just hoped that it would not be required, as it always worked when the max size was smaller. ;)
I'll see what it would take to get the size into the header. After merging changes from trunk to locator branch I have the same problem with the mkgmap-locator. Is there any other information I can supply or any test to run to help debugging this issue?
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
OK the attached patch should now take into account the exact size of the file when setting the 'partition size' in the header.
There is a minimum size of 2048 512 byte sectors, anything larger than that is calculated just a little larger, so any mistake will cause a problem. Works for me so far. Using your patch I get the messages below and the map can't still be loaded in MapSource file size 0 file size 0 max block 42204 endSector=42204, from 42204 try 65472, for mb=42204 max block 50217 endSector=50217, from 50217 try 65472, for mb=50217 file size 0 max block 12004 endSector=12004, from 12004 try 65472, for mb=12004 file size 0 max block 21899 endSector=21899, from 21899 try 65472, for mb=21899 file size 0 max block 21345 endSector=21345, from 21345 try 65472, for mb=21345 file size 0 max block 38482 endSector=38482, from 38482 try 65472, for mb=38482 file size 0 max block 15235 endSector=15235, from 15235 try 65472, for mb=15235 file size 0 max block 20773 endSector=20773, from 20773 try 65472, for mb=20773 file size 0 max block 22445 endSector=22445, from 22445 try 65472, for mb=22445 file size 0 max block 17141 endSector=17141, from 17141 try 65472, for mb=17141 file size 0 max block 20432 endSector=20432, from 20432 try 65472, for mb=20432 file size 0 max block 28355 endSector=28355, from 28355 try 65472, for mb=28355 file size 0 file size 0 max block 11 endSector=2047, from 11 try 65472, for mb=2047 file size 0 max block 38682 endSector=309463, from 38682 try 65472, for mb=309463 try 130944, for mb=309463 try 261888, for mb=309463 try 523776, for mb=309463 max block 4871 endSector=38975, from 4871 try 65472, for mb=38975
El 04/05/11 16:57, Carlos Dávila escribió:
El 04/05/11 15:18, Steve Ratcliffe escribió:
Hi
Just another thought ... could it be that C/H/S information should be calculated dynamically based on the actual size of a .img-file? Maybe this could save memory on a GPS when the tiles are loaded ... this is speculation since I don't know exactly how this is implemented. Yes it should be. I just hoped that it would not be required, as it always worked when the max size was smaller. ;)
I'll see what it would take to get the size into the header. After merging changes from trunk to locator branch I have the same problem with the mkgmap-locator. Is there any other information I can supply or any test to run to help debugging this issue?
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev OK the attached patch should now take into account the exact size of the file when setting the 'partition size' in the header.
There is a minimum size of 2048 512 byte sectors, anything larger than that is calculated just a little larger, so any mistake will cause a problem. Works for me so far. Using your patch I get the messages below and the map can't still be loaded in MapSource file size 0 file size 0 max block 42204 endSector=42204, from 42204 try 65472, for mb=42204 max block 50217 endSector=50217, from 50217 try 65472, for mb=50217 file size 0 max block 12004 endSector=12004, from 12004 try 65472, for mb=12004 file size 0 max block 21899 endSector=21899, from 21899 try 65472, for mb=21899 file size 0 max block 21345 endSector=21345, from 21345 try 65472, for mb=21345 file size 0 max block 38482 endSector=38482, from 38482 try 65472, for mb=38482 file size 0 max block 15235 endSector=15235, from 15235 try 65472, for mb=15235 file size 0 max block 20773 endSector=20773, from 20773 try 65472, for mb=20773 file size 0 max block 22445 endSector=22445, from 22445 try 65472, for mb=22445 file size 0 max block 17141 endSector=17141, from 17141 try 65472, for mb=17141 file size 0 max block 20432 endSector=20432, from 20432 try 65472, for mb=20432 file size 0 max block 28355 endSector=28355, from 28355 try 65472, for mb=28355 file size 0 file size 0 max block 11 endSector=2047, from 11 try 65472, for mb=2047 file size 0 max block 38682 endSector=309463, from 38682 try 65472, for mb=309463 try 130944, for mb=309463 try 261888, for mb=309463 try 523776, for mb=309463 max block 4871 endSector=38975, from 4871 try 65472, for mb=38975 I realized MapSource error is different with the patched version, but don't know if this info is useful App: MapSource OS: Windows XP Service Pack 2 (actually debian+wine) Processor: x86, Processor Level: 16, Processors:2, Model: 6 Stepping: 2, RAM: 2097151 DSK_PRIVPARTITION.CPP-314-6.13.7.0 Language ID: 1034 Part Number: 006-A0041-00 Build Type: Release Extra: Opening map at (lat,lon): 40.0342, -2.41699 Resolution: 16
Stack Trace: 2072270818 9448702 8340466
El 04/05/11 21:42, Peter Lerner escribió:
DSK_PRIVPARTITION.CPP-314-6.13.7.0 This is the same error I had when the mdr-file exceded the former fixed limit of 256 MB.
Maybe one file is larger than the adjusted C/H/S values now specify. I don't think so. All my other maps, even the smallest ones are broken with the patched mkgmap. Did it fix the problem for you?
Maybe one file is larger than the adjusted C/H/S values now specify. I don't think so. All my other maps, even the smallest ones are broken with the patched mkgmap. Did it fix the problem for you?
Can you get me a compiled jar including the fix? I'm not a dev guy ... Peter
Hi
Can you get me a compiled jar including the fix? I'm not a dev guy ...
I can reproduce the new problem and so far I've discovered another constraint on the allowed values in the header, I will post a new patch and build when I've got to the bottom of it.
New patch attached. A jar is uploaded at: URL: http://files.mkgmap.org.uk/download/12/mkgmap.jar File: mkgmap.jar created on 05 may 2011 Description: version of mkgmap with patch for header size values. ..Steve
New patch attached. Description: version of mkgmap with patch for header size values.
The whole Europe map still seems to blow some limits. The osmmap_mdr.img >240 MB seems to be the problem. "NOT OK" try 491520, for mb=493761 try 507904, for mb=493761 "OK!!!" try 491520, for mb=493113 try 507904, for mb=493113 (= 252.469.248 Bytes file size, approx. 240,8 MB) Somewhere in between is the size mapsource accepts currently for the mdr.img. The good news is, I had only to leave out 3-4 tiles from the Europe map. I.e. we extended the limit a good step! ;-) I should also mention that the tiles seem to load faster when mapsource displays the whole map on startup! I didn't benchmark .. just a feeling. Peter
Hi Not sure what is going on here. Could you try with the attached patch and (if it is still NOT OK) please send me the whole output and the exact size of the mdr file. Pre-built at: URL: http://files.mkgmap.org.uk/download/13/mkgmap.jar Description: mkgmap with img_accurate_size2.patch I should point out that there is a hard limit of 255M on the mdr file by default as you are getting pretty close to that. To work around that you can give --block-size=8192 *after* all other options and files, ie. right at the very end of the command line. Thanks ..Steve
El 06/05/11 12:17, Steve Ratcliffe escribió:
Hi
Not sure what is going on here.
Could you try with the attached patch and (if it is still NOT OK) please send me the whole output and the exact size of the mdr file.
Pre-built at: URL: http://files.mkgmap.org.uk/download/13/mkgmap.jar Description: mkgmap with img_accurate_size2.patch
I should point out that there is a hard limit of 255M on the mdr file by default as you are getting pretty close to that. To work around that you can give --block-size=8192 *after* all other options and files, ie. right at the very end of the command line. Patch 2 fixed the problem for me: I can load the map on MapSource, pan and select tiles. Great work!!!
Could you try with the attached patch and (if it is still NOT OK) please send me the whole output and the exact size of the mdr file.
Sorry, the complete europe map still seems to trigger some limits. It's again the mdr.img being >240MB. I uploaded the faulty file to the mkgmap website. Here is the debug output ... C:\Users\peter\Desktop\aio\europa-tiles>java -enableassertions -Xmx4000M -jar "C:\Program Files\openstreetmap.org\mkgmap\mkgmap-fix2.jar" --verbose --max-jobs --latin1 --code-page=1252 --description=" OSM AiO Europe 20110407" --country-name="Europe-country"' --country-abbr="EU-c" --region-name="Europe-region" --region-abbr="EU-r" --area-name=EU --series-name="OSM AiO Europe" --family-name=OSM --fam ily-id=6324 --product-id=1 --draw-priority=10 --nsis --tdbfile --index --route --net 70014*.img file size 0 file size 0 write size values block size=512 shc=4,16,32, end=67 file size 0 write size values block size=512 shc=4,16,32, end=67 write size values block size=4096 shc=4,16,32, end=499360 shc=4,16,64, end=499360 shc=4,16,128, end=499360 shc=4,16,256, end=499360 shc=4,16,512, end=499360 shc=4,16,1024, end=499360 shc=8,16,32, end=499360 shc=8,16,64, end=499360 shc=8,16,128, end=499360 shc=8,16,256, end=499360 shc=8,16,512, end=499360 shc=8,16,1024, end=499360 shc=16,16,32, end=499360 shc=16,16,64, end=499360 shc=16,16,128, end=499360 shc=16,16,256, end=499360 shc=16,16,512, end=499360 shc=16,16,1024, end=499360 shc=32,16,32, end=499360 shc=32,16,64, end=499360 shc=32,16,128, end=499360 shc=32,16,256, end=499360 shc=32,16,512, end=499360 shc=32,16,1024, end=499360 One more thought: the limit of 240 MB looks like the least siginifcant 4 bits of some limiting variable are masked out somehow, 256 - 16 = 240!? Another thoght: Before r1919 the Europe map was working for me. What did change with r1919 or later? Is there a tool for download to analyse the imgfmt-structure? Peter
Hi
Sorry, the complete europe map still seems to trigger some limits.
It's again the mdr.img being>240MB. I uploaded the faulty file to the mkgmap website. Here is the debug output ...
OK, thanks for that.
One more thought: the limit of 240 MB looks like the least siginifcant 4 bits of some limiting variable are masked out somehow, 256 - 16 = 240!?
Interesting...
Another thoght: Before r1919 the Europe map was working for me. What did change with r1919 or later?
I started using the formula in: http://en.wikipedia.org/wiki/Logical_Block_Addressing#CHS_conversion instead of just guessing how it works. Also there were attempts to increase the max size, followed by setting the max size based on the actual size. Most of these changes have mostly worked, but not for someone.
Is there a tool for download to analyse the imgfmt-structure?
For the disk header I use: http://sourceforge.net/projects/garmin-img/ The header is the first thing written so there is no need to let it run to completion on a large file, nor worry if it crashes after writing the *DSKIMG* file out. I use a patched version (patch attached against 1.1). For almost everything else there is a program in http://svn.mkgmap.org.uk/display/trunk/ that will print the sections. ..Steve
Sorry, the complete europe map still seems to trigger some limits.
I did some more testing. With the option --block-size=8192 I got the whole europe map as far so that I could select tiles. But now the gmapsupp index creation fails. - pan and zoom: OK - select tiles: OK now - idx creation: CRASH at ca. 14% The error triggered is: MDR_TRIM_ADDR.CXX-440-6.16.3.0 With maps being small enough (whatever that is exactly?) there is no problem at all. Peter
Hello
Sorry, the complete europe map still seems to trigger some limits.
I did some more testing.
With the option --block-size=8192 I got the whole europe map as far so that I could select tiles. But now the gmapsupp index creation fails.
Thanks, I will take this as confirmation that the patch works. I also think that the limit of 4096 block size may be lower than I previously said, so 240M may well be too large. I shall probably just increase the default block size to 8k for the mdr.img as there no disadvantage in wasted space for that file.
- pan and zoom: OK - select tiles: OK now - idx creation: CRASH at ca. 14%
The error triggered is: MDR_TRIM_ADDR.CXX-440-6.16.3.0
This is a completely different problem. Would it be possible to upload this broken file too? Thanks ..Steve
Steve,
Thanks, that's great. It may take a while to work out what the problems is. Do you have an mdr file that a bit smaller that still works completely?
I'm still on the follwing Mapsource upload problem. - pan and zoom: OK - select tiles: OK - idx creation: CRASH at ca. 14% After some extended testing I could narrow down the problem to only *two* tiles causing the problem and make it reproducable! I'm using mkgmap r1949 meanwhile. 70014464.img -- XK-Pristina (according to cities15000-file) 70014652.img -- BG-Sofice The picture is the following: a) I can upload both tiles each individually to my GPS without problems. b) Both tiles in combination cause the problem. That means to me that I need to do some further investigation: i) The problem could be caused by splitter doing some nasty things on both tiles in combination that makes idx creation fail. ii) The problem could be with .img tile creation. Some idx related data is incompatible across the two tiles (duplicated ids, inconsistent ids, etc ...). iii) The problem could be with the original OSM data that contains a situation that mkgmap can not handle. Anybody else experienced Mapsource problems in the Macedonia / Greece (Skopje / Thessaloniki) area? I need some hints on what and how I could proceed with my testing. What is your opinion / your experience? I'm sure the problem exists also with some other tile pairs. Because i tried to exempt the above mentioned two problematic tiles from idx creation and select the rest (while respecting the current 4 GB restrivtion in Mapsource). The upload also failed. So this means to me that the problem is not a singular one restricted to only the above mentioned tile combination. Peter
I forgot to mention that I already uploaded the problematic tiles and idx files to http://files.mkgmap.org.uk/download/ ... Peter Am 27.05.2011 00:01, schrieb Peter Lerner:
Steve,
Thanks, that's great. It may take a while to work out what the problems is. Do you have an mdr file that a bit smaller that still works completely?
I'm still on the follwing Mapsource upload problem.
- pan and zoom: OK - select tiles: OK - idx creation: CRASH at ca. 14%
After some extended testing I could narrow down the problem to only *two* tiles causing the problem and make it reproducable! I'm using mkgmap r1949 meanwhile.
70014464.img -- XK-Pristina (according to cities15000-file) 70014652.img -- BG-Sofice
The picture is the following:
a) I can upload both tiles each individually to my GPS without problems. b) Both tiles in combination cause the problem.
That means to me that I need to do some further investigation:
i) The problem could be caused by splitter doing some nasty things on both tiles in combination that makes idx creation fail.
ii) The problem could be with .img tile creation. Some idx related data is incompatible across the two tiles (duplicated ids, inconsistent ids, etc ...).
iii) The problem could be with the original OSM data that contains a situation that mkgmap can not handle. Anybody else experienced Mapsource problems in the Macedonia / Greece (Skopje / Thessaloniki) area?
I need some hints on what and how I could proceed with my testing. What is your opinion / your experience?
I'm sure the problem exists also with some other tile pairs. Because i tried to exempt the above mentioned two problematic tiles from idx creation and select the rest (while respecting the current 4 GB restrivtion in Mapsource). The upload also failed. So this means to me that the problem is not a singular one restricted to only the above mentioned tile combination.
Peter _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 27/05/11 22:33, Peter Lerner wrote:
I forgot to mention that I already uploaded the problematic tiles and idx files to http://files.mkgmap.org.uk/download/ ...
Thanks. The index is actually built with 70014466.img and not 70014464.img in the FAIL directory. Could you supply 70014466.img please (or an index you built with 70014464.img if it really should be that tile). There were earlier bugs that had the same kind of symptoms (only happened for particular selections of tiles). One thing I did notice with the files is that some of the labels have lower case letters in them after being transliterated (probably). That may cause a problem, because in the index the labels are all strictly upper case and this may affect the sort order. I doubt the problem is with splitter. ..Steve
Peter
Am 27.05.2011 00:01, schrieb Peter Lerner:
Steve,
Thanks, that's great. It may take a while to work out what the problems is. Do you have an mdr file that a bit smaller that still works completely?
I'm still on the follwing Mapsource upload problem.
- pan and zoom: OK - select tiles: OK - idx creation: CRASH at ca. 14%
After some extended testing I could narrow down the problem to only *two* tiles causing the problem and make it reproducable! I'm using mkgmap r1949 meanwhile.
70014464.img -- XK-Pristina (according to cities15000-file) 70014652.img -- BG-Sofice
The picture is the following:
a) I can upload both tiles each individually to my GPS without problems. b) Both tiles in combination cause the problem.
That means to me that I need to do some further investigation:
i) The problem could be caused by splitter doing some nasty things on both tiles in combination that makes idx creation fail.
ii) The problem could be with .img tile creation. Some idx related data is incompatible across the two tiles (duplicated ids, inconsistent ids, etc ...).
iii) The problem could be with the original OSM data that contains a situation that mkgmap can not handle. Anybody else experienced Mapsource problems in the Macedonia / Greece (Skopje / Thessaloniki) area?
I need some hints on what and how I could proceed with my testing. What is your opinion / your experience?
I'm sure the problem exists also with some other tile pairs. Because i tried to exempt the above mentioned two problematic tiles from idx creation and select the rest (while respecting the current 4 GB restrivtion in Mapsource). The upload also failed. So this means to me that the problem is not a singular one restricted to only the above mentioned tile combination.
Peter _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Steve,
The index is actually built with 70014466.img and not 70014464.img in the FAIL directory.
Sorry, that was my fault. The new upload should now contain the two problematic tiles.
There were earlier bugs that had the same kind of symptoms (only happened for particular selections of tiles).
One thing I did notice with the files is that some of the labels have lower case letters in them after being transliterated (probably). That may cause a problem, because in the index the labels are all strictly upper case and this may affect the sort order.
The search citry dialog gives some weired letters .... like e.g. "B?Lgariâ" for the country. Also some POIs display only "???" letters. There seem to be Cyrillic characters (ISO-8859-5). Another problem that I spot while inspecting the tile border common to both problematic tiles is that some parts of a complex multipolygon are missing. I don't know if that is related to the Mapsource error ... see picture attached and compare with the map-link. http://www.openstreetmap.org/?lat=42.7038&lon=22.082&zoom=13&layers=M http://www.openstreetmap.org/browse/relation/1330640/ I'm using splitter 171 / mkgmap-r1955 meanwhile. So WanMils latest MP patches should be active. Peter
Hi Peter It does appear to be something to do with the lowercase characters in the labels after transliteration. The attached patch fixes the problem for your example files. I think there is more to do since we shouldn't be putting lowercase letters into the img files in the first place. There is another very big problem with those tiles as I get a lot of streets that cannot be found. This is because the sorted road index in NET is very badly sorted for some reason. ..Steve
El 07/05/11 15:57, Steve Ratcliffe escribió:
Is there a tool for download to analyse the imgfmt-structure?
For the disk header I use: http://sourceforge.net/projects/garmin-img/ The header is the first thing written so there is no need to let it run to completion on a large file, nor worry if it crashes after writing the *DSKIMG* file out. I use a patched version (patch attached against 1.1).
I tried to compile the source code from that link + your patch but get the following error: make g++ -c main.cc -g g++ -c garminimg.cc -g g++ -c imgfile.cc -g g++ -c subfile.cc -g g++ -c tre.cc -g g++ -c lbl.cc -g g++ -c rgn.cc -g g++ -c net.cc -g g++ -c nod.cc -g make: *** No hay ninguna regla para construir el objetivo `gmp.o', necesario para `imgdecode'. Alto. (There's no rule to build target `gmp.o' necessary for `imgdecode'. Halt.
For almost everything else there is a program in http://svn.mkgmap.org.uk/display/trunk/ that will print the sections.
Hi
I tried to compile the source code from that link + your patch but get the following error: make ... make: *** No hay ninguna regla para construir el objetivo `gmp.o', necesario para `imgdecode'. Alto. (There's no rule to build target `gmp.o' necessary for `imgdecode'. Halt.
Ah, I guess the patch was really against the cvs version which has a few extra files. Anyway, I've packaged my latest version of it up and you can get it here: URL: http://files.mkgmap.org.uk/download/17/imgdecode-sr-r10.zip Description: A modified version of the imgdecode program (http://sourceforge.net/projects/garmin-img/) that fixes bugs and works with a wider variety of files. The usual ./configure; make; sequence should build it. Thanks ..Steve
participants (5)
-
Andy Allan -
Carlos Dávila -
Marko Mäkelä -
Peter Lerner -
Steve Ratcliffe