Canalplan Bug Tracker



Anonymous Login
2019-06-26 23:26 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000599Canalplan Route Planningpublic2019-06-22 08:30
ReporterLen 
Assigned ToNick Atty 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionunable to reproduce 
PlatformOSWindows 10OS Version
Product VersionProduct Build 
Target VersionFixed in Version 
Summary0000599: Time calculation seems delayed by one place
DescriptionEither I'm reading it wrong (help, please) or the calculation of time to travel after a stop (e.g., of 1 hour) is not registered until a stop later (too late).
So - time to travel to Lock 35 Pesau is 42 minutes. I stop at Pesau for 1 hour. Time to travel to the next lock, 34 Bannay, is 42 minutes. (!) Time to travel to the next place (St Satur) is 1 hour, 58 minutes, with the note, "Timing includes previous stop of 1 hour." The stop was not previous, but _two_ previous. See the screen shot.
Shouldn't the stopping time be calculated travelling time to Lock 34 Bannay and added on there, not at St Satur?
Steps To ReproduceCalculate itinerary.
Additional InformationThis has been going on for a while, but I think I might be misinterpreting the output.
Tagsroute planning, timing
Attach Tags (Separate by ",")
Attached Files

-Relationships
+Relationships

-Notes

~0002467

Nick Atty (administrator)

Firstly,. thank you very much for the clear explanation and the screenshot - it really helps.

Secondly, it does look to be exactly as you say - that extra hour only makes it into all three sets of timing a place later. That's rather odd, as it sounds harder to do than what should be happening.

Will look into it.

~0002473

Nick Atty (administrator)

That said, I'm struggling to reproduce it - see my screen shot where everything seems to be working perfectly!

~0002476

Egbert (reporter)

It's been going on for a while with me. I've tried signing off, clearing all my cookies -- things like that. I've delayed reporting it, because everything works out in the end. Eventually the timing is OK. Another workaround I have been doing is to calculate day-by-day trips and the calculation is good there. Perhaps that is what you have done - a one-day trip? But still ...
I will provide you with any other info for troubleshooting you request.
Is there a way I could export and then re-import the data? I hesitate to offer to start again.
You can have access to my account if that helps (maybe you already have). All my trips are shared and I don't mind making them public.

~0002477

Nick Atty (administrator)

If you have a saved public route that does it, just publish the link to it here and I'll play with it.

~0002482

Len (reporter)

OK. So . . .
In order to send you a link to a public version of my trip, I loaded it and then saved it as a "new" journey (by ticking the little box) and gave it a slightly different name.
This new journey _does not have_ a calculation error!
The link is: https://canalplan.org.uk/journey/11564_cp
Also see the new screen shot. The screen shot comes from "Ninth full day of trip" in the Itinerary view. There were other occurrences of this sort of error as well; I have not checked them out.
It doesn't matter to me why -- if you ever care to find out, I probably wouldn't understand the explanation. I'm just very happy it doesn't do it any more and I'll keep using this new public version.
I don't know whether to be embarrassed or not.
Thanks so much.
P.S. Can anyone edit this public version, or just the "author"?

~0002492

Nick Atty (administrator)

It's clearly nothing for you to be embarrassed about, as it was clearly wrong (nobody faked that first screen shot!).

How long ago did you save the original? I wonder if it was some strange side effect of any changes I made to the code meaning it misread the stopping info in some way.

Anyway, it's all very odd and without an instance causing the problem I'm going to leave it to rest - but please keep a look out and let me know if it does it again (not many people report bugs, it's very likely that things could keep going wrong and not get reported).

Thanks - a clear report, and a good response to my questions: that's all any programmer asks of his users!

On the PS, only the author can save over a route, so anyone could edit it, but they could only save it as their own.

~0002493

Nick Atty (administrator)

It's clearly nothing for you to be embarrassed about, as it was clearly wrong (nobody faked that first screen shot!).

How long ago did you save the original? I wonder if it was some strange side effect of any changes I made to the code meaning it misread the stopping info in some way.

Anyway, it's all very odd and without an instance causing the problem I'm going to leave it to rest - but please keep a look out and let me know if it does it again (not many people report bugs, it's very likely that things could keep going wrong and not get reported).

Thanks - a clear report, and a good response to my questions: that's all any programmer asks of his users!

On the PS, only the author can save over a route, so anyone could edit it, but they could only save it as their own.

~0002583

Autoclose (administrator)

Closing automatically, stayed too long in feedback state. Feel free to re-open with additional information if you think the issue is not resolved.
+Notes

-Issue History
Date Modified Username Field Change
2019-05-18 21:11 Len New Issue
2019-05-18 21:11 Len File Added: time calculation.jpg
2019-05-18 21:11 Len Tag Attached: route planning
2019-05-18 21:11 Len Tag Attached: timing
2019-05-18 21:47 Stephen Atty Assigned To => Nick Atty
2019-05-18 21:47 Stephen Atty Status new => assigned
2019-05-19 08:57 Nick Atty Note Added: 0002467
2019-05-19 10:31 Nick Atty File Added: cp-pause.png
2019-05-19 10:31 Nick Atty Note Added: 0002473
2019-05-19 15:12 Egbert Note Added: 0002476
2019-05-19 15:53 Nick Atty Note Added: 0002477
2019-05-20 00:56 Len File Added: time calculation errorfree.jpg
2019-05-20 00:56 Len Note Added: 0002482
2019-05-23 07:51 Nick Atty Note Added: 0002492
2019-05-23 07:51 Nick Atty Note Added: 0002493
2019-05-23 07:51 Nick Atty Status assigned => resolved
2019-05-23 07:51 Nick Atty Resolution open => unable to reproduce
2019-06-22 08:30 Autoclose Note Added: 0002583
2019-06-22 08:30 Autoclose Status resolved => closed
+Issue History