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
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
Hi
That's done.
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?
Thanks
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Steve,
Thanks, I will take this as confirmation that the patch works.
One step further ...
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?
That's done.
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
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:
Hi
Sorry, the complete europe map still seems to trigger some limits.
It's again the mdr.img being240MB. 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
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
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
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
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.
..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
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.
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
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 ...
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.
Peter
___
mkgmap-dev mailing list
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
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
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
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
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
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
What version of MapSource are you using?
6.16.3 on Win7_x64
Peter
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
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
2011/4/20 Carlos Dávila cdavi...@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
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:
El 20/04/11 16:01, Andy Allan escribió:
2011/4/20 Carlos Dávilacdavi...@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
29 matches
Mail list logo
