Adding Speed to a GPX file

[RsH]

I observed that if I had a file open in RouteConverter and then opened the SAME file in RouteConverterPrerelease and, in the second file, asked that the program inject the speed into all 44,736 positions, the file scrolled from the beginning to the end as the speed was added to all of the positions rather quickly, with NOTHING visible on the left side of the screen due to the use of that same data using the jar in the regular RouteConverter. However when only ONE version of RouteConverter is open, and as a result the full display is visible on the left, the speeds are added far more slowly [instead of 4 or 5 minutes it takes MANY minutes, and the scoll in the right side down as the speeds are added does NOT work. I therefore have to assume that the java jar [javaw.exe and java.exe] and their grab of memory and cpu cycles when the map or a satellite view are displayed makes the big difference in the speed with which the speed is added to the file. Is there any way to add the speed quickly by telling the program NOT to display the map view until the speed has been added to all the records? I am working with a file that is over 14 megs in size before the speed is added, and over 15 megs in size after the speed is added, with 44,736 positions covering 142.6 km and 6h 26m 48s [and the AM showing after the time shown that follows Duration is not needed <grin> - that is a bug - duration is in hours, minutes, seconds without an AM or PM.]

What is the problem that causes the speed to be added so slowly when the map is displayed and very quickly when the map is not displayed?

[I've also observed that I cannot get any email while the program [javaw.exe] is hogging my link to the Internet, and that it is using over 300,000 Mb of RAM and running at almost the full capacity of one of the processors in my computer, with no sign that it is near completion of adding the speed to those records... and no way to tell the program that it cannot hog the resources this way.]

Added... The number of decimal places in the added Speed line in the resulting GPX file needs to be limited to 5 decimal places. There are a number of resulting records with a lot more places added that amount to nothing... 999999999999 or 00000000001 sort of extra digits beyond the first 5. Round to 5 digits behind the decimal place in ALL instances where something other than 0.0 is used and save me some file space as those extra digits of no value add nothing but waste space.

[kumo]

I observed that if I had a file open in RouteConverter and then opened the SAME file in RouteConverterPrerelease and, in the second file, asked that the program inject the speed into all 44,736 positions, the file scrolled from the beginning to the end as the speed was added to all of the positions rather quickly, with NOTHING visible on the left side of the screen due to the use of that same data using the jar in the regular RouteConverter.

So you had two instances of RC active, at the same time? Although they are different releases, they use the same resources. This may be the reason for a slow-motion. RC is designed to run in one instance, only.

Is there any way to add the speed quickly by telling the program NOT to display the map view until the speed has been added to all the records?

You can hide the map with the black triangle at the vertical separation bar between position list and map. If the map is fully closed, you can do all converter functions, off-line. This may speed up the required calculations.

What is the problem that causes the speed to be added so slowly when the map is displayed and very quickly when the map is not displayed?

A steady stream of requests to Google Maps?

[I've also observed that I cannot get any email while the program [javaw.exe] is hogging my link to the Internet, and that it is using over 300,000 Mb of RAM and running at almost the full capacity of one of the processors in my computer, with no sign that it is near completion of adding the speed to those records... and no way to tell the program that it cannot hog the resources this way.]

With the 14 megs .gpx and the map in view and two instances of RC?

Added... The number of decimal places in the added Speed line in the resulting GPX file needs to be limited to 5 decimal places. There are a number of resulting records with a lot more places added that amount to nothing... 999999999999 or 00000000001 sort of extra digits beyond the first 5. Round to 5 digits behind the decimal place in ALL instances where something other than 0.0 is used and save me some file space as those extra digits of no value add nothing but waste space.

Please be patient for an answer to this inquiry and to the "duration is in hours, minutes, seconds without an AM or PM" bug. Christian is on vacation, for one week.

Regards,
kumo

[RsH]

I observed that if I had a file open in RouteConverter and then opened the SAME file in RouteConverterPrerelease and, in the second file, asked that the program inject the speed into all 44,736 positions, the file scrolled from the beginning to the end as the speed was added to all of the positions rather quickly, with NOTHING visible on the left side of the screen due to the use of that same data using the jar in the regular RouteConverter.

So you had two instances of RC active, at the same time? Although they are different releases, they use the same resources. This may be the reason for a slow-motion. RC is designed to run in one instance, only.

Actually, when I had the two open, the second, not using javaw.exe, flew through adding the speed to the 44000+ positions, so I do NOT believe that having two open is the reason the first was so slow, since it was the only version using javaw.exe... and now, using the black diamond to close the left side window has NOT impacted the speed since the Windows Task Manager shows that javaw.exe is still open and using over 300,000 KB of ram.

Is there any way to add the speed quickly by telling the program NOT to display the map view until the speed has been added to all the records?

You can hide the map with the black triangle at the vertical separation bar between position list and map. If the map is fully closed, you can do all converter functions, off-line. This may speed up the required calculations.

It doesn't as the speed seems to be 1.25 minutes per 1000 positions, when adding speed... both with and without that window being open, as long as javaw.exe is open and running.

What is the problem that causes the speed to be added so slowly when the map is displayed and very quickly when the map is not displayed?

A steady stream of requests to Google Maps?

It looks like it does a request to redisplay the map [even though it is fixed in place while the speed is being added] every 3 seconds whether or not the window is open, and this indeed may be part of the problem with connecting to my email while RouteConverter is open and running doing the speed add.

[I've also observed that I cannot get any email while the program [javaw.exe] is hogging my link to the Internet, and that it is using over 300,000 Mb of RAM and running at almost the full capacity of one of the processors in my computer, with no sign that it is near completion of adding the speed to those records... and no way to tell the program that it cannot hog the resources this way.]

With the 14 megs .gpx and the map in view and two instances of RC?

No, with the 14 meg .gpx and the map in view and only one instance of RC open.

Added... The number of decimal places in the added Speed line in the resulting GPX file needs to be limited to 5 decimal places. There are a number of resulting records with a lot more places added that amount to nothing... 999999999999 or 00000000001 sort of extra digits beyond the first 5. Round to 5 digits behind the decimal place in ALL instances where something other than 0.0 is used and save me some file space as those extra digits of no value add nothing but waste space.

Please be patient for an answer to this inquiry and to the "duration is in hours, minutes, seconds without an AM or PM" bug. Christian is on vacation, for one week.

Regards,
kumo

Okay... I don't mind waiting...
RsH

[RsH]

I believe I found the problem... and sorting the file to ensure that all of the individual positions were in correct time sequence seems to be the solution. There were a few records OUT of time sequence, and one or two which had the same exact time on them. When I went through the file and found those that were out of place, and those that were identical in time, even if different in position [I looked at every 30 and where they were not 30 seconds apart I looked more closely and moved or removed the incorrect entries, or inserted missing entries to ensure one entry per second] and fixed the whole file, and THEN added the speed, it loads just fine. So the key likely is the need to be certain that there is no time that should be earlier in the file but is later than other later times. That is a guess, but it makes the ability to sort the individual positions based on date and time even more important, when merging files, etc., if that is what was causing the 'infinity' symbol error. Anyway I am adding a route to the Browse tab called Panama Canal with the full track through the canal, with all of the errors that are in that file due to loss and connection to different satellites, and so forth, over the almost 12.5 hours covered by the track.

[kumo]

Anyway I am adding a route to the Browse tab called Panama Canal with the full track through the canal, with all of the errors that are in that file due to loss and connection to different satellites, and so forth, over the almost 12.5 hours covered by the track.

I've tried to load it, but without success. My PC had a slow-motion for a minute, track not loaded.

Sorry - I will move this file to the housekeeping-drawer. I won't delete it, now: Christian may wish to evaluate it, when he is back.

*.gpx files are very large, compared with other formats. I.e Google Earth *.kml formats are very smaller, containing the same infomation.

You might try to save this large file in *.kml to reduce the file length.

You also might try the functions in the "Select duplicate positions" button to reduce the total number of points in your file. The lowest of this functions, "Select redundant positions" may be useful: This selects points, that can be deleted without changing the shape of your track within a given threshold.

[routeconverter]

I observed that if I had a file open in RouteConverter and then opened the SAME file in RouteConverterPrerelease and, in the second file, asked that the program inject the speed into all 44,736 positions, the file scrolled from the beginning to the end as the speed was added to all of the positions rather quickly, with NOTHING visible on the left side of the screen due to the use of that same data using the jar in the regular RouteConverter.

RouteConverter can only be started once with a map displayed on the left. That's a limitation of the underlyinging JDIC library and caused by a lock on the IeEmbed.exe binary used to embed the Internet Explorer.

Is there any way to add the speed quickly by telling the program NOT to display the map view until the speed has been added to all the records?

No. But if you reduce the size of the map by clicking on the arrow to the left, I think no updates on positions hit the map component and force it to update.

What is the problem that causes the speed to be added so slowly when the map is displayed and very quickly when the map is not displayed?

You're updating every single position of the track, forcing the map component to update the map view each time since it cannot determine (Java ListModel stuff #§$%!&"!) that there is no need to update as only the speed has changed which is not displayed anyway.

[I've also observed that I cannot get any email while the program [javaw.exe] is hogging my link to the Internet, and that it is using over 300,000 Mb of RAM and running at almost the full capacity of one of the processors in my computer, with no sign that it is near completion of adding the speed to those records... and no way to tell the program that it cannot hog the resources this way.]

You're performing resource extensive stuff on your machine

Added... The number of decimal places in the added Speed line in the resulting GPX file needs to be limited to 5 decimal places.

I do not find anything about a limitation of the number of digits in http://www.topografix.com/gpx/1/1/gpx.xsd - where is your information from?

[routeconverter]

Anyway I am adding a route to the Browse tab called Panama Canal with the full track through the canal, with all of the errors that are in that file due to loss and connection to different satellites, and so forth, over the almost 12.5 hours covered by the track.

I've tried to load it, but without success. My PC had a slow-motion for a minute, track not loaded.

Sorry - I will move this file to the housekeeping-drawer. I won't delete it, now: Christian may wish to evaluate it, when he is back.

It's a good test file I cannot load it either as the transfer of the file seems to lock up the tiny, tiny, tiny server. As long as I don't update the server, that file should better be kept somewhere else and put into the RouteCatalog via "Add as URL".

[RsH]

It's a good test file I cannot load it either as the transfer of the file seems to lock up the tiny, tiny, tiny server. As long as I don't update the server, that file should better be kept somewhere else and put into the RouteCatalog via "Add as URL".

RAR it and it shrinks by 90% <grin> --- that might be better on a tiny server... Do you want me to do that to it?

[routeconverter]

RAR it and it shrinks by 90% <grin> --- that might be better on a tiny server... Do you want me to do that to it?

It won't help since RouteConverter cannot gzip it. But if you saved it as .kmz that would be an option since it's kml which takes less space and it's compressed with GZIP afterwards. How about that?