Thread: [Gpsbabel-misc] NAD27 conversion error in unicsv module
Brought to you by:
robertl
From: Kryzzle <kr...@gm...> - 2008-02-28 06:24:08
|
Hi, I am struggling with a problem related to conversion of UTM NAD27 datum into WGS84. I would like to convert a list of waypoints, given in UTM NAD27, into a Google Earth .kml file, using unicsv as an import filter. My waypoint data file input.txt looks like this: name, utm zone, utm c, utm east, utm north WP NAD27, 12, s, 457046, 4087631 WP WGS84, 12, s, 456983, 4087832 My conversion command line is as follows: gpsbabel -w -D 1 -i unicsv,datum="N. America 1927 mean" -f input.txt -o kml -F output.kml Now what I found out is that GPSbabel appears to recognize the datum="N. America 1927 mean" option, but keeps on interpreting the input data as WGS84. This is proven by the fact that the "WP WGS84" is the only waypoint at the right location, the "WP NAD27" is being placed far off. Looking at the source code, it appears as if there is a hard coded function call to parse_coordinates, fixing the input data format to WGS84: case fld_utm: parse_coordinates(s, DATUM_WGS84, grid_utm, &wpt->latitude, &wpt->longitude, MYNAME); break; Can anybody help fix this please, maybe there's an easy workaround? Best regards Kryzzle |
From: Olaf K. <o.b...@pr...> - 2008-02-28 08:42:15
|
Hi Kryzzle, > > I am struggling with a problem related to conversion of UTM NAD27 datum > into WGS84. > > I would like to convert a list of waypoints, given in UTM NAD27, into a > Google Earth .kml file, > using unicsv as an import filter. > My waypoint data file input.txt looks like this: > > name, utm zone, utm c, utm east, utm north > WP NAD27, 12, s, 457046, 4087631 > WP WGS84, 12, s, 456983, 4087832 > > My conversion command line is as follows: > > gpsbabel -w -D 1 -i unicsv,datum="N. America 1927 mean" -f input.txt -o > kml -F output.kml > > Now what I found out is that GPSbabel appears to recognize the datum="N. > America 1927 mean" option, > but keeps on interpreting the input data as WGS84. This is proven by the > fact that the "WP WGS84" > is the only waypoint at the right location, the "WP NAD27" is being > placed far off. > > Looking at the source code, it appears as if there is a hard coded > function call to parse_coordinates, > fixing the input data format to WGS84: > > case fld_utm: > parse_coordinates(s, DATUM_WGS84, grid_utm, > &wpt->latitude, &wpt->longitude, MYNAME); > break; > > Can anybody help fix this please, maybe there's an easy workaround? as I see, I've tested the datum calculation stuff only for the output-side of unicsv. But, I had a short look into the code and I'll commit the fix as soon as possible. O.K. |
From: Kryzzle <kr...@gm...> - 2008-03-01 11:20:06
|
Hi Olaf, I see from the CVS log that you already checked in the updated version. Many thanks! I do not have the tool chain installed to compile the executable from the latest source. Is there any chance I could download a build with the fixed unicsv module? Cheers Kryzzle Olaf Klein schrieb: > Hi Kryzzle, > >> I am struggling with a problem related to conversion of UTM NAD27 datum >> into WGS84. >> >> I would like to convert a list of waypoints, given in UTM NAD27, into a >> Google Earth .kml file, >> using unicsv as an import filter. >> My waypoint data file input.txt looks like this: >> >> name, utm zone, utm c, utm east, utm north >> WP NAD27, 12, s, 457046, 4087631 >> WP WGS84, 12, s, 456983, 4087832 >> >> My conversion command line is as follows: >> >> gpsbabel -w -D 1 -i unicsv,datum="N. America 1927 mean" -f input.txt -o >> kml -F output.kml >> >> Now what I found out is that GPSbabel appears to recognize the datum="N. >> America 1927 mean" option, >> but keeps on interpreting the input data as WGS84. This is proven by the >> fact that the "WP WGS84" >> is the only waypoint at the right location, the "WP NAD27" is being >> placed far off. >> >> Looking at the source code, it appears as if there is a hard coded >> function call to parse_coordinates, >> fixing the input data format to WGS84: >> >> case fld_utm: >> parse_coordinates(s, DATUM_WGS84, grid_utm, >> &wpt->latitude, &wpt->longitude, MYNAME); >> break; >> >> Can anybody help fix this please, maybe there's an easy workaround? >> > > as I see, I've tested the datum calculation stuff only for the output-side of > unicsv. But, I had a short look into the code and I'll commit the fix as soon > as possible. > > O.K. > > > |