Thread: [Gpsbabel-code] Memory-Map reference file
Brought to you by:
robertl
From: Alex Y. <ale...@ho...> - 2010-08-14 12:13:16
|
Hi, Thank you for your previous help. I've now succeeded in compiling GPSBabel with MinGW but have come across another problem. I assume that the idea of the files in the 'reference' sub-directory is that a command like gpsbabel -i mmo -o gpx reference/memory-map.mmo check_me.gpx should create a file called check_me.gpx which is identical to reference/memory-map~mmo.gpx . However, when I run the command gpsbabel exits with an error: mmo: Unregistered object id 0x96FF! I tried opening reference/memory-map.mmo with the latest free version of Memory-Map (Memory-Map European Edition Version 5.4.2 Build 1089) which failed with the error: reference\memory-map.mmo has a bad format. I guess that the reference file is corrupted. Does anyone know which version of Memory-Map the reference file was created with and if so whether that version will still open it? Does anyone know of any documentation available for the internal file structure of Memory-Map Navigator overlay files? Thank you for your help Alex |
From: Robert L. <rob...@gp...> - 2010-08-14 16:00:17
|
On Sat, Aug 14, 2010 at 7:13 AM, Alex York <ale...@ho...> wrote: > Hi, > > Thank you for your previous help. I've now succeeded in compiling GPSBabel > with MinGW but have come across another problem. > > I assume that the idea of the files in the 'reference' sub-directory is > that a command like > gpsbabel -i mmo -o gpx reference/memory-map.mmo check_me.gpx > should create a file called check_me.gpx which is identical to > reference/memory-map~mmo.gpx . However, when I run the command gpsbabel > exits with an error: > mmo: Unregistered object id 0x96FF! > More specifically, it's for our test suite. That's the shell script 'testo' in the top level directory. It tends to run a bunch of commands much as you describe. I just successfully ran that command. Something is wrong with your build and you should debug it. > I guess that the reference file is corrupted. > $ sum memory-map.mmo ; md5 memory-map.mmo 21710 22 memory-map.mmo MD5 (memory-map.mmo) = 70fb4ddd97c7ae572a93a9548b1a1f05 > Does anyone know which version of Memory-Map the reference file was created > with and if so whether that version will still open it? > > Does anyone know of any documentation available for the internal file > structure of Memory-Map Navigator overlay files? > mmo.c |
From: Alex Y. <ale...@ho...> - 2010-08-14 22:32:31
|
Hi, I checked the MD5 checksum and it was incorrect. It seems that the file has been checked in to the repository marked as an ASCII file instead of binary. I checked out a new copy as a binary file. The checksum is now correct and the output from gpsbabel -i mmo -o gpx reference/memory-map.mmo check_me.gpx is nearly identical to reference/memory-map~mmo.gpx (the last digit varies by one for some co-ordinates). Alex Date: Sat, 14 Aug 2010 11:00:08 -0500 Subject: Re: [Gpsbabel-code] Memory-Map reference file From: rob...@gp... To: ale...@ho... CC: gps...@li... I guess that the reference file is corrupted. $ sum memory-map.mmo ; md5 memory-map.mmo21710 22 memory-map.mmoMD5 (memory-map.mmo) = 70fb4ddd97c7ae572a93a9548b1a1f05 |
From: Alex Y. <ale...@ho...> - 2010-08-21 18:04:17
|
Hi, Was I mistaken about reference/memory-map.mmo being marked as an ASCII file in the repository? I've just checked now and it still appears to be marked as ASCII. If it is marked as ASCII is it possible for someone to correct this and mark it as binary (cvs admin -kb)? I appreciate that Unix users are unlikely to have issues checking out a binary file that is incorrectly marked since line ending conversion won't occur but any Windows users will receive a corrupted copy of the file. I tried running the testo script and it fails for a large number of formats so I suspect that this issue affects other reference files as well. I have been adding support for Memory Map files with an internal version number of 24 to mmo.c . I notice that the code currently supports reading internal versions 17, 18 and 22 but there is only a single test file, reference/memory-map.mmo , with an internal version of 22. Is the policy to only have a single reference file for a given format regardless of the number of variants read or would it be reasonable to add another file named reference/memory-map-v24.mmo and add appropriate additonal tests to testo.d/classic-4.test ? Alex |
From: Robert L. <rob...@gp...> - 2010-08-22 19:05:41
|
On Sat, Aug 21, 2010 at 1:04 PM, Alex York <ale...@ho...> wrote: > Hi, > > Was I mistaken about reference/memory-map.mmo being marked as an ASCII file > in the repository? > No. I just hadn't had time to address it until now. Done. I tried running the testo script and it fails for a large number of formats > so I suspect that this issue affects other reference files as well. > If you could provide a list, I'll tweak them in the repository. I have been adding support for Memory Map files with an internal version > number of 24 to mmo.c . I notice that the code currently supports reading > internal versions 17, 18 and 22 but there is only a single test file, > reference/memory-map.mmo , with an internal version of 22. Is the policy to > only have a single reference file for a given format regardless of the > number of variants read or would it be reasonable to add another file named > reference/memory-map-v24.mmo > In fantasy land, we'd have 100% code coverage for every version of all these files. It's been our experience that most of them differ so trivially that's it's not historically been worth it, but it's good practice. So if you have test files for more versions that trigger different code paths, please feel free to submit those with your patch. > and add appropriate additonal tests to testo.d/classic-4.test ? > As I've touched classic-*.test, I've been busting them into standalone files. That allows you to run the tests individually, e.g. 'testo kml'. RJL |
From: Alex Y. <ale...@ho...> - 2010-08-28 17:44:43
|
Hi, Sorry for being impatient about the ASCII/binary problem. I wasn't certain I was correct. The following files need marking as binary to get classic-4.test to run. I'll work through the other tests when I get a chance and check which other files are incorrectly marked. garmin_gpi.gpi gpi_ext-sample.gpi umsonstdraussen.gpi navilink_waypoints.wpt navilink_tracks.trk track/datalog.sbp track/mtk_logger.bin track/mtk_logger_m241.bin track/mtk_logger_gp245.bin IMG_2065.JPG track/vidaone.gpb humminbird.hwr route/humminbird.hwr track/humminbird.ht track/gnav_trl.trl igo2008_poi.upoi track/mapasia-tr7.tr7 track/navitel_trk.bin itracku.dat pocketfms_bc pocketfms_bc.babel v900_basic_mode.csv v900_advanced_mode.csv route/naviguide-route.twl I was surprised to find that the two Columbus/Visiontac V900 CSV files were actually binary. I'm also having problems with rounding errors when running the tests, e.g. --- ./reference/memory-map~mmo.gpx Wed Feb 11 12:54:00 2009 +++ /tmp/gpsbabel.4008/memory-map~mmo.gpx Sat Aug 28 18:31:07 2010 @@ -168,7 +168,7 @@ <name>ACTIVE LOG 001</name> <trkseg> <trkpt lat="51.311770314" lon="12.413178999"> - <ele>146.257812</ele> + <ele>146.257813</ele> <time>2005-05-01T10:12:47Z</time> </trkpt> <trkpt lat="51.311807279" lon="12.412898038"> Does anybody know off-hand of any compiler options for MinGW's GCC that might fix the rounding problems? Thank you Alex |
From: Robert L. <rob...@gp...> - 2010-08-29 08:30:31
|
On Sat, Aug 28, 2010 at 12:44 PM, Alex York <ale...@ho...> wrote: > Hi, > > Sorry for being impatient about the ASCII/binary problem. I wasn't certain > I was correct. > > The following files need marking as binary to get classic-4.test to run. > I'll work through the other tests when I get a chance and check which other > files are incorrectly marked. > Thanx. Fixed. > Does anybody know off-hand of any compiler options for MinGW's GCC that > might fix the rounding problems? > GCC reserves the right to do weird things with those bottom bits when optimizing. Is it the with -O2 and -O2? RJL |