Feature/nav 64 enrich raptor results inside of raptor to include trips ids etc #51
Conversation
- Only for legs with ArrivalType.ROUTE. - For other types (INITIAL and TRANSFER) the value is NO_INDEX (=-1).
- RouteBuilder sorts trips according their departure times. - The order of the trip ids is ensured by the RouteContainer and its LinkedHashMap. Note: Normal hash maps are not guaranteeing any order.
- Lookup trip id using trip offset in the reconstruction.
… naming in project - LegType.FOOTPATH is renamed to LegType.WALK_TRANSFER. - Rename method accessing walk transfer.
…ad of size. - This seems to be a more useful method on the connection class, to get the number of transfers, we then call size() on the returned list. - Renamed Num to NumberOf.
…service leg implementation
- Make trip on stop time transient and exclude from to string. - Adjust to string of coordinate to match lombok default.
…lic transit leg Use visitor in connection to get connection departure and arrival time instead as this method seems to be more convenient / user-friendly.
- Set distance as beeline distance between locations. - Move leg type to first in object, since this important information gets lost otherwise in the full DTO.
| } | ||
|
|
||
| @Override | ||
| public Leg visit(Walk walk) { | ||
| return new Leg(walk.getSourceLocation(), walk.getTargetLocation(), null, null, LegType.WALK, | ||
| return new Leg(LegType.WALK, walk.getSourceLocation(), walk.getTargetLocation(), null, null, |
There was a problem hiding this comment.
Although not implemented so far, but why not add source or target stop. We have the stop object in our Walk implementation, and can figure out if it it's the source or target by checking the Walk Type First Mile or Last Mile
There was a problem hiding this comment.
Good point, I overlooked that. Implemented in: beec21f
| @@ -16,4 +16,43 @@ public class ConnectionImpl implements Connection { | |||
|
|
|||
| private final List<Leg> legs; | |||
|
|
|||
| @Override | |||
| public LocalDateTime getDepartureTime() { | |||
There was a problem hiding this comment.
Still not convinced that the visitor is the better solution, than just having the implementation of PublicTransit back referencing the stop time. But I know I'm the minority disagreeing with design patterns, so I can live with it.
There was a problem hiding this comment.
What bothers you about the visitor? we have no casts and no null values... so it is completely safe ;)
But I know, you really enjoy passing around null values, haha sorry 😄
| ch.naviqore.gtfs.schedule.model.Trip gtfsTrip = schedule.getTrips().get(leg.tripId()); | ||
| Trip trip = map(gtfsTrip, date); | ||
|
|
||
| assert gtfsTrip.getStopTimes().size() == trip.getStopTimes() |
There was a problem hiding this comment.
When or how could this be the case?
There was a problem hiding this comment.
I think this should never be the case... but since we compare datasets from two different sources (GTFS and Raptor) it could be that we somehow insert inconsistencies. Therefore I added the assert. In production asserts are not executed, so it is really just for us developer to ensure this consistency. Since I guess it could lead to an index out of bounds exception in the best case, in the worst case, the resulting leg is just incorrect without an error.
clukas1
deleted the
feature/NAV-64-enrich-raptor-results-inside-of-raptor-to-include-trips-ids-etc
branch
Add trip information to Raptor Route and store the trip offset in the Raptor legs to be able to reconstruct the connection. Pass trip information on to the Connection of the service and finally map to connection DTO.
Further adds: