No timestamps in KML file?

[hiviking]

Sorry, I don't know GE that good. RouteConverter offers a hidden option to clean timestamp and elevation on moves, but GE?

Hi Christian,

The issue here is whether the RouteConverter can preserve the timestamp in the conversion. All the information is in the opened KML file, it is just in two different sections. The timestamps are in the "when" tags and the modified coordinates are in the Linestring.

I tried editing a track in RouteConverter, but it was very difficult to get it right due to the lack of 3D. This is much easier in GE (I can send you images if you like). Is there any chance you could include the GE plugin as a maptype? This is done in the "3D Route Builder", but its editing features are very clumsy. RouteConverter is much better, it just needs the 3D. If I could do all the editing in RouteConverter the conversion issue would be moot.

[hiviking]

I just decided to write an awk script that does the conversion. Without missing any timestamps, that is, so it definitely can be done. It took me about an hour to get it right. While I was at it I wrote another script to get the Google elevations via their Elevation Service, so I am now independent of "3D Route Builder".

I am curious whether you will consider to include 3D (Google Earth API) in RouteConverter. That would be a major improvement which would put RouteConverter ahead of the competition.

[routeconverter]

I just decided to write an awk script that does the conversion. Without missing any timestamps, that is, so it definitely can be done.

I'd definitely want to integrate that knowledge into RouteConverter. I simply don't understand what you did and what I have to change. Please describe what your awk-script does: what it reads from KML and what it writes to GPX.

It took me about an hour to get it right. While I was at it I wrote another script to get the Google elevations via their Elevation Service, so I am now independent of "3D Route Builder".

I was considering that but the current implementation works fine. It downloads SRTM files from the NASA servers and falls back to geonames.org and earthtools.org if that fails.

I am curious whether you will consider to include 3D (Google Earth API) in RouteConverter. That would be a major improvement which would put RouteConverter ahead of the competition.

You know thats a lot of work? I means throwing away most of the code for the UI, losing routing, adding positions to convert routes to tracks, adding postal addresses and I guess some more features.

[routeconverter]

I just decided to write an awk script that does the conversion. Without missing any timestamps, that is, so it definitely can be done. It took me about an hour to get it right.

Can you provide two example files to me: the original KML file and the GPX file your awk script generates? I think RouteConverter converts elevation information from KML files but I cannot extract from your awk script what is different there.

While I was at it I wrote another script to get the Google elevations via their Elevation Service, so I am now independent of "3D Route Builder".

I've double checked RouteConverters code to extract the elevation from the downloaded SRTM 3 data. It does an interpolation as you can see here in the code:

double dDeltaLat; // The delta between top lat value and wanted lat (delta within a sub tile)
double dDeltaLon; // The delta between left lon value and wanted lon (delta within a sub tile)

dDeltaLon = dOffLon - (double) nLonIndex * (1.0 / (double) nAS); // The delta (offset) from left point to wanted point
dDeltaLat = dOffLat - (double) nLatIndex * (1.0 / (double) nAS); // The delta (offset) from bottom point to wanted point

double dLonHeightLeft; // The interpolated elevation calculated from left top to left bottom
double dLonHeightRight; // The interpolated elevation calculated from right top to right bottom

dLonHeightLeft = dLeftBottom - calculateElevation(dLeftBottom - dLeftTop, 1.0 / (double) nAS, dDeltaLat);
dLonHeightRight = dRightBottom - calculateElevation(dRightBottom - dRightTop, 1.0 / (double) nAS, dDeltaLat);

// Interpolate between the interpolated left elevation and interpolated right elevation
dElevation = dLonHeightLeft - calculateElevation(dLonHeightLeft - dLonHeightRight, 1.0 / (double) nAS, dDeltaLon);

return (int) (dElevation + 0.5); // Do a rounding of the calculated elevation

You can think of a different more precise interpolation algorithm or has Google simply more or more accurate data?