Pt interchange duration

[Theodore-Chatziioannou]

In a recent simulation, we noticed that the "pt interaction" activity can have duration > 0. The plan handlers are ignoring those activities (see here), and as a result the start times of the next leg end up wrong (since the activity end time does not get updated.

We are not sure that this "pt interaction" activity represents in these cases.

I am trying to fix the timestamp bug by checking for an "end_time" tag in the "pt interaction" activity. If there is one, then pt interaction is treated as a normal activity, separating legs/trips either side.

[fredshone]

This will create new trips where a pt interaction is encountered with an end_time. This seems wrong.

Instead i think we need to simply allow for the fact that a pt_interaction can have a duration?

ie:

if stage.tag == "activity":
    # update time
   if not act_type == 'pt interaction':
       # logic for new trip

[fredshone]

prior logic seems to assume duration of pt interactions is 0

[Theodore-Chatziioannou]

changed the sequence to :

if stage.tag == "activity":
   if not act_type == 'pt interaction':
       # logic for new trip
   elif stage.get('end_time'):
       # update time
   else:
      # zero pt-interaction duration

[andkay]

Agreed with @fredshone.

Also, if we are explicitly handling cases where pt-interaction does or does not include an end_time, we should include tests for both.

[Theodore-Chatziioannou]

you are right, the pt interaction activity should not separate leg of trips, and only update the timestamps. I have corrected for this, and added tests for both zero-duration pt interactions and non-zero ones.

[andkay]

Looks good to me @Theodore-Chatziioannou. I don't know how much capacity we have for this at the moment. Time permitting, a larger refactor on these handlers would be a good idea. Process plans is doing quite a lot of work and the control flow is pretty difficult to follow.

[Theodore-Chatziioannou]

I agree @akay-arup - added it as issue #221 .