I've tweaked the whitespace (I don't know what you're using that converted all the tabs to spaces, but please
turn it off) in this, added the doc you provided this afternoon, and committed this.

Can you please submit another patch that adds these to the write side of the equation into xcsv_waypt_pr()?

The purist in me would point you to the lovely 'dec_to_human' example which looks in the format string for
print specifiers, honoring the format string *and* substituting the hemisphere character for %c.

The "but you let him get away with it" guy discloses that we have LAT_DECIMALDIR and LAT_DIRDECIMAL
which each hardcode the location of the hemisphere character on opposite ends of the strings.

Given the relative obscurity of this format, I wouldn't resist a change int he form of the latter. 


On Wed, Jun 18, 2008 at 8:42 AM, A C Hurst <A.Hurst@sheffield.ac.uk> wrote:
This fixes a bug which I attempted to write to the list about earlier this week, but got bounced due
to domain name aliases.

.cup files have lat/lon as ddmm.mm token with a direction char on the end.
This char was being ignored, and the csv input code was not set up to handle it.
The style tried to use XT_LAT_NMEA/XT_LON_NMEA which handles the ddmm.mm but not the <DIR>, hence
ignoring negativity of lat/long.

I attach a proposed fix.

New case pair in the big input parsing switch, called XT_LAT_DDMMDIR/XT_LON_DDMMDIR, and a new util
function ddmmdir_to_degrees.
(Plus modifying xcsv_tokens.in and style/cup.stlye accordingly)

Please let me know what you think.


Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Gpsbabel-code mailing list  http://www.gpsbabel.org