Date and time for a new LAST position

[RsH]

Last three positions in a file I just 'edited' to add the correct start and end and some intermediate positions. Note the date and time of the LAST new position, which was inserted today AFTER the last recorded position to take the ending point of the track to the location of my building's garage ramp. While the first of the three is also an added position, it kept the correct date, and calculated a time. The LAST new position, however, used the time I added the position, instead of keeping the correct date. I know it had nothing after that position to use to calculate the correct time but better than what has happened would be to use the prior two date and time values to calculate the date and time based on keeping the same speed as an assumption of the speed of travel in calculating the correct date and approximate time to use for this new position.

<trkpt lon="-79.41656649112701" lat="43.769184054991285">
<ele>179.0</ele>
<time>2010-10-07T00:41:59.875Z</time>
<name>New position {0}</name>
</trkpt>
<trkpt lon="-79.41643238067627" lat="43.768723068636">
<ele>179.0</ele>
<time>2010-10-07T00:42:05.000Z</time>
<name>Position 95</name>
<extensions>
<nmea:speed>34.79410536585366</nmea:speed>
</extensions>
</trkpt>
<trkpt lon="-79.4136106967926" lat="43.76209454430009">
<ele>185.0</ele>
<time>2010-11-14T07:38:21.671Z</time>
<name>New position {0}</name>
</trkpt>

[routeconverter]

The LAST new position, however, used the time I added the position, instead of keeping the correct date. I know it had nothing after that position to use to calculate the correct time

That is the reason why "keeping the correct date" is impossible. No date is another alternative.

but better than what has happened would be to use the prior two date and time values to calculate the date and time based on keeping the same speed as an assumption of the speed of travel in calculating the correct date and approximate time to use for this new position.

Let me see how complex this might become...

[RsH]

but better than what has happened would be to use the prior two date and time values to calculate the date and time based on keeping the same speed as an assumption of the speed of travel in calculating the correct date and approximate time to use for this new position.

Let me see how complex this might become...

Obviously I can do this manually. I would start out with the date and time of the last position that had a date and time and add some time to the last time, then compute the speed, and if it was too fast add seconds to the time or if too slow, remove seconds from the time to get to a reasonable speed and thus time, since the date would not be changing 99.99% of the occasions when this is done. It's just easier if the program does it .

[routeconverter]

the last position that had a date and time and add some time to the last time, then compute the speed, and if it was too fast add seconds to the time or if too slow, remove seconds from the time to get to a reasonable speed and thus time, since the date would not be changing 99.99% of the occasions when this is done. It's just easier if the program does it .

Yes, but it took me 12 conditions and 30 lines of logic to implement it safely. Please try the latest prerelease if it works as expected.

[RsH]

Yes, but it took me 12 conditions and 30 lines of logic to implement it safely. Please try the latest prerelease if it works as expected.
[/quote]

No, it doesn't. If I insert a new point, it is now providing a location name instead of 'new position' and it is not permitting me to move that new point [or even an existing point] to where I want it. I tried it with the beginning of the list, the end of the list and in between and in all cases it provides a name based on the location, such as the Joseph Shepard Federal Building instead of 'new location' and I cannot drag and drop the point to the correct location. I'll revert to .94 from .98 for now, as I still need to be able to move the points around slightly, and the names are not necessarily correct. I live a block south of the Joseph Shepard Federal Building, for example, yet that is the name given the final added point.

[{Joseph Sheppard Federal Buiding, Toronto, ON M2N 6A4, Canada} is the description given, and that has two errors in it... Shepard is the way the building's name is spelled, not Sheppard, and buiding is also incorrect, as you can see. The STREET two blocks south IS spelled Sheppard, but not the building <grin> since Joseph only used one 'p' in his surname.]

[routeconverter]

Yes, but it took me 12 conditions and 30 lines of logic to implement it safely. Please try the latest prerelease if it works as expected.

No, it doesn't.

What about the time logic you've proposed to implement? Does that work?
I haven't read a word about it.

If I insert a new point, it is now providing a location name instead of 'new position' and it is not permitting me to move that new point [or even an existing point] to where I want it.

That's not a bug, it's a feature: new locations are automatically reverse geocoded.

As I can move positions on the map here, I need more information about what's going wrong on your side. Please clear the log file, do the steps that lead to the bug and send me the log file and a detailed description how to reproduce it.

[RsH]

As I can move positions on the map here, I need more information about what's going wrong on your side. Please clear the log file, do the steps that lead to the bug and send me the log file and a detailed description how to reproduce it.
[/quote]

The log file was cleared and a complete one which covered inserting a new starting point via an insert between point 1 and point 2 and moving that point to being point 0 with a change in the time to make it earlier than the point 1, then trying to move that new point 0, and also going to the end of the file, deleting a few points where there was no movement, and then adding a new final point and trying to move it, then saving that file and exiting RouteConverter, was sent to you. I await news on why, on my computer, I cannot move these, or any other points. The orange pointer moves, but the lat and long do not change on my computer. Running an up to date XP operating system, the latest update to Java, etc. An older version of the prerelease [.94] still permits me to move these points around while .98 does not.

[RsH]

Update message at Midnight, Eastern Standard Time, November 16th... I just downloaded the latest pre-release version, 2.1-SNAPSHOT 103 2010-11-15 10:59:54 and tried the same changes, moving the new first point and the new last point. Same exact thing happens... no change in the lat or long and therefore I cannot use this to do what I need to do. I have to use 2.1-SNAPSHOT 94, as 2.1-SNAPSHOT 98 also has the problem.

[routeconverter]

Hi Robert,

thank you for testing. There were exceptions in the log

Nov 15, 2010 3:01:53 PM
SEVERE: Exception in thread "MapViewCallbackListener"
Nov 15, 2010 3:01:53 PM
SEVERE: java.lang.IndexOutOfBoundsException: No group 2
Nov 15, 2010 3:01:53 PM
SEVERE: at java.util.regex.Matcher.group(Unknown Source)
Nov 15, 2010 3:01:53 PM
SEVERE: at slash.navigation.converter.gui.mapview.BaseMapView.processCallback(BaseMapView.java:1251)
Nov 15, 2010 3:01:53 PM
SEVERE: at slash.navigation.converter.gui.mapview.BaseMapView.processLines(BaseMapView.java:1175)
Nov 15, 2010 3:01:53 PM
SEVERE: at slash.navigation.converter.gui.mapview.BaseMapView.processStream(BaseMapView.java:1132)
Nov 15, 2010 3:01:53 PM
SEVERE: at slash.navigation.converter.gui.mapview.BaseMapView.access$2500(BaseMapView.java:80)
Nov 15, 2010 3:01:53 PM
SEVERE: at slash.navigation.converter.gui.mapview.BaseMapView$6.run(BaseMapView.java:398)
Nov 15, 2010 3:01:53 PM
SEVERE: at java.lang.Thread.run(Unknown Source)

That's a bug in the code handling the change of the map type (something I never do, so this slipped through my tests). After that, no more events from the map were processed. Please try the latest prerelease I've just uploaded.

[RsH]

Version 105 has the bug fixed and inserting positions works correctly once more... Thank you.