Quantcast

WG: unicsv.cc - bug?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

WG: unicsv.cc - bug?

CapeCross

Hi,

I was trying to convert some CSV files to KML the last days and I noticed that the east/west information was not interpreted correctly, see attachment.

 

After trying to write a quick program in Python (taking of course longer than expected 😊), I went looking for an old version of Gpsbabel instead.

During this I stumbled on your Github depositry and had a look a the source code of unicsv.cc

 

I’m not sure, but I think there might be a cut’n’paste error in this code that causes the behaviour observed by me.

 

If you look at the code segment for ´case fld_ew´, it seems that the variable „ns“ is used in the definition (mistake?), but „ew“ is used in the calculation (correct, I guess).

 

Looking forward to your feedback.

 

 

--------------snippet---------------------

case fld_ns:

 

ns = s.startsWith('n', Qt::CaseInsensitive) ? 1 : -1;

 

wpt->latitude *= ns;

 

break;

 

 

case fld_ew:

 

ns = s.startsWith('e', Qt::CaseInsensitive) ? 1 : -1;

 

wpt->longitude *= ew;

break;

--------------------------------------

 

 

Best regards,

                CapeCross (fond user of Gpsbabel 😊)


unicsv - east/west not interpreted

Hi all,

I’m was using an old version Gpsbabel (unfortunately I don’t have it anymore) for many years very happily, but recently, after installing the most current version (1.5.4) on my new PC, I encountered some issues which I couldn’t resolve upto now. Maybe you can help? 😊

I use a Qstarz BT-Q1000 GPS logger and save my tracks as CSV file:

<<...>>

Then I use the following command to convert to KML (same command as with the old version of Gpsbabel)

gpsbabel.exe -w -r -t -i unicsv -f %input% -x discard,hdop=2 -o kml,lines,points,floating,trackdata,labels -F %output%

and later zip the file to KMZ

7z.exe a -tzip %compressed% %output%

<<...>>

When looking at track in Google Earth I noticed that the east/west information from the CSV file seems to be not interpreted when converting to KML (this track should actually be in New York…).

<<...>>

Many thanks in advance,

        Levin


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

test_route.csv (228 bytes) Download Attachment
test_route.kmz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WG: unicsv.cc - bug?

Robert Lipe-4
Hi, Levin.

Thanx for the good analysis. I broke this almost three years ago and nobody's noticed. Oops.

I applied the "obvious" fix at https://github.com/gpsbabel/gpsbabel/commit/43947c60a2e2e3c96610410182210566bffcce92

RJL


On Fri, Apr 28, 2017 at 3:49 AM, CapeCross <[hidden email]> wrote:

Hi,

I was trying to convert some CSV files to KML the last days and I noticed that the east/west information was not interpreted correctly, see attachment.

 

After trying to write a quick program in Python (taking of course longer than expected 😊), I went looking for an old version of Gpsbabel instead.

During this I stumbled on your Github depositry and had a look a the source code of unicsv.cc

 

I’m not sure, but I think there might be a cut’n’paste error in this code that causes the behaviour observed by me.

 

If you look at the code segment for ´case fld_ew´, it seems that the variable „ns“ is used in the definition (mistake?), but „ew“ is used in the calculation (correct, I guess).

 

Looking forward to your feedback.

 

 

--------------snippet---------------------

case fld_ns:

 

ns = s.startsWith('n', Qt::CaseInsensitive) ? 1 : -1;

 

wpt->latitude *= ns;

 

break;

 

 

case fld_ew:

 

ns = s.startsWith('e', Qt::CaseInsensitive) ? 1 : -1;

 

wpt->longitude *= ew;

break;

--------------------------------------

 

 

Best regards,

                CapeCross (fond user of Gpsbabel 😊)



---------- Forwarded message ----------
From: CapeCross <[hidden email]>
To: <[hidden email]>
Cc: 
Bcc: 
Date: Mon, 24 Apr 2017 19:25:00 +0200
Subject: unicsv - east/west not interpreted

Hi all,

I’m was using an old version Gpsbabel (unfortunately I don’t have it anymore) for many years very happily, but recently, after installing the most current version (1.5.4) on my new PC, I encountered some issues which I couldn’t resolve upto now. Maybe you can help? 😊

I use a Qstarz BT-Q1000 GPS logger and save my tracks as CSV file:

<<...>>

Then I use the following command to convert to KML (same command as with the old version of Gpsbabel)

gpsbabel.exe -w -r -t -i unicsv -f %input% -x discard,hdop=2 -o kml,lines,points,floating,trackdata,labels -F %output%

and later zip the file to KMZ

7z.exe a -tzip %compressed% %output%

<<...>>

When looking at track in Google Earth I noticed that the east/west information from the CSV file seems to be not interpreted when converting to KML (this track should actually be in New York…).

<<...>>

Many thanks in advance,

        Levin


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Loading...