Producing a pure CSV file - converting back

[RsH]

I need a CHANGE to be able to produce a more pure CVS file, as the format for Columbus V900 uses a text format for the latitude and longitude. 9.123456N and -79.123456W are what are in the Columbus format. I need a pure Number in each of these, as the N and W are actually redundant, and because of them I cannot do -.0006 to the longitude in the Panama Canal track, since the W at the end makes the track a text position and not a purely numerical position.

Then I need to be able to take that modified CVS file and bring it back into RouteConverter so I can save it as a GPX file for use with the GPicSync program as I geocode my photos.

---

I would also be able to sort on the date and time columns to catch sequencing errors. I would be able to delete a range where the movement is incorrectly recorded, and let Excel or QuatroPro fill in the values for the correct increments in latitude and longitude when that is appropriate, instead of having to insert one at a time, and keep moving the position I am injecting at to cover all of the missing points that I deleted and need to replace. I could even merge several files that way while I fill in the missing 'seconds'... so I can see lots of uses for that pure CSV format.

[routeconverter]

Hi Robert,

it's actually very easy for me to modify the Columbus V900 Format - if it wouldn't render it useless. There are devices and software that use exactly that format.

Of course I could try to define a generic .csv format, but how would that look like? Something like this:

INDEX,DATE,TIME,LATITUDE,LONGITUDE,HEIGHT,SPEED,COMMENT,
1,210409,061051,47.797120,13.049595,524.33,33.44,Somewhere above the sea,
2,210409,061051,47.897120,13.059595,525.33,34.34,For GER/FRA/DK/NW/SW umlauts like äöüß,

Date + Time in GMT
Date in ddmmyy, Time in hhmmss
Latitude, Longitude in WGS84
Height in Meter above sealevel
Speed in Km/h

Whole file is UTF-8 encoded
Spaces ignored

Something like that?

Alternatively: How about splitting the NSWE into separate columns in Excel, doing the subtraction and then joining them again?

[RsH]

Of course I could try to define a generic .csv format, but how would that look like? Something like this:

INDEX,DATE,TIME,LATITUDE,LONGITUDE,HEIGHT,SPEED,COMMENT,
1,210409,061051,47.797120,13.049595,524.33,33.44,Somewhere above the sea,
2,210409,061051,47.897120,13.059595,525.33,34.34,For GER/FRA/DK/NW/SW umlauts like äöüß,

Date + Time in GMT
Date in ddmmyy, Time in hhmmss
Latitude, Longitude in WGS84
Height in Meter above sealevel
Speed in Km/h

Whole file is UTF-8 encoded
Spaces ignored

Something like that?

Alternatively: How about splitting the NSWE into separate columns in Excel, doing the subtraction and then joining them again?

1. I would not split the NSEW into separate columns, since the use of '-' for west and south is a well known standard, and therefore the latitude has to be north if positive and south if negative, and longitude has to be west if negative and east if positive.

2. The math used to adjust a track if it is off, as mine is via the Panama Canal, by about .0006° longitude is, in this instance to use -.0006 on the longitude column. Even if it crossed the 0° longitude marker, that same adjustment would be continued, correctly, on all of the longitude cells in the CVS file. It you split the columns based on West or East, I would simply need to do that same math on the two columns instead of on the one column should it cross the 0° point.

3. As long as you cover all of the columns available in RouteConverter, including the Description column, which I suspect you are calling the Comment column, and Elevation is the same what you are calling Height above, I am quite happy as even if I had added a postal address before I started working on the file in QuatroPro or Excel, I would be fine as I wouldn't lose anything from the before file I had converted.

4. Index is fine, but when I re-order lines that index value will suddenly be out of order as well. I would expect all of my 'files' would be in date and time sequence [and I would check via a sort] anyway, so I am uncertain what, if anything, the index column adds. It cannot hurt if when, after adjusting the file, it is not used to order the positions when I convert back from CVS to GPX, which is what I would be doing... In fact I would expect that the index column would simply be dropped if I were converting back to GPX, since it is not in the GPX file at the start, nor in the RouteConverter's screen display of a GPX file as imported, where the Description column starts off as with position values.

5. If you do have an index column, and if I am bringing two GPX files, individually saved as CVS files via RouteConverter, into the same 'spreadsheet' so as to merge them, both would have the same INDEX values in them for the first x positions, and I would likely be injecting Y blank lines so as to fill in the gap between file one and file two.

6. In the case of my Panama Canal files [five in total] there are gaps of several seconds between the various files, and I would import each into the one CVS file, insert the missing seconds at the gap I would deliberately leave, using a simple equation to move the ship from the last position in file one to the first position in file two, for example, and then re-index the file so as to get rid of the duplicate index numbers, yet sorting simply on the time column [or date and time if midnight gets in the way] puts them in absolutely the correct order in any event [except where two entries have the same precise time in seconds, which does indeed happen on occasion]. So I am uncertain what the index column adds, if anything... but as long as it is ignored when the file is loaded into RouteConverter AFTER the corrections and adjustments are made, I really do not care if it is there or not <grin>...

Hope that helps you decide which way to go with it... and it is fairly simple to add that index column down the road, or remove it down the road, so go either way, as long as saving as a pure CVS file, and loading a pure CVS file both follow the same rules.

Incidentally, one other use I have for this sort of file is to create from scratch a CVS file for old slides I am now scanning using my Nikon Coolscan III and Vuescan, which injects a basic EXIF file. I can easily create a record that uses the date in the scanned result and the latitude and longitude where the image was taken [for example Monte Alban, in Mexico, during our Honeymoon] and then use GPicSync to inject that geo-position information into those scanned slides so that the digitized images have better data in them. The other way I can do this is to use Wordpad, and that is a bit more cumbersome so I prefer using a delimited file and QuatroPro. In those instances speed and altitude/elevation would be blank, and I would let RouteConverter fill in those fields after importing the CVS file into RouteConverter, and before injecting into the scanned images.

[routeconverter]

Hi Robert,

I think you have convinced me ;-)

[mrQQ]

Talking about CSV format: I would +1 for adding support of it. And I would suggest gpsbabel way of doing it: it reads first line, and judges which column contains what from it. It's detailed in gpsbabel documentation

[routeconverter]

That's what I was thinking about ;-)

[RsH]

That's what I was thinking about ;-)

Universal csv with field structure in first line (unicsv) in GPSBabel seems to work with both the files out of the ASUS R300 and the I-gotU GT-120. The latter has elevation and speed in it as well as date, time, lat and long. Now if I change the , field separator to the | I have the start of my ASUS R300 POI file once I move the columns around a bit :-) so use that and it should work for almost everyone who wants a CSV file..

[Skater]

Ich greife das Thema auf.
Die Haicom-Logger (csv) ist praktisch als eine Standard-Variante für csv zu verwenden.
Allerdings wird die Beschreibung des Punktes nicht berücksichtigt:
INDEX,RCR,DATE,TIME,LATITUDE,N/S,LONGITUDE,E/W,ALTITUDE,COURSE,SPEED,
Bitte als COMMENT anhängen.
Falls es Probleme mit der Kompatibilität gibt, dann einen neuen Namen erfinden.
Hauptsachen die Struktur bleibt erhalten.
Gruß Skater

I take up the subject.
The Haicom logger (csv) is to be used as a standard variation for csv.
Indeed, the description of the points is not taken into consideration:
INDEX, RCR, DATE, TIME, LATITUDE, N/S, LONGITUDE, E/W, ALTITUDE, COURSE, SPEED,
Please supplement COMMENT:
INDEX, RCR, DATE, TIME, LATITUDE, N/S, LONGITUDE, E/W, ALTITUDE, COURSE, SPEED, COMMENT

If there are problems with the compatibility, then invent a new name.
Central issues the structure is preserved.
Greeting skater