Waarom wordt het Call model gebruikt?

[skinkie]

Het call Model komt alleen terug in SIRI, maar in geen van de andere profielen in Europa.

Waarom is er gekozen om Calls te gebruiken ipv timetabled passing time, of timedemandtype?

[GeertThijs]

Beide zijn aan,wezig momenteel: TimeTabledPassingTime & Call. Oorspronkelijk zat Call er niet in maar wel iets dat er op leek (we noemden het een ServiceJourneyLink). De TimeTabledPassingTime geeft de reiziger een idee wanneer hij welke Lijn naar waar kan nemen, de ServiceJourneyLink was bedoeld voor navigatietools die in een bepaald ScheduledStopPoint gewoon willen weten welke andere StoPoints je kan bereiken en in hoeveel tijd dat mogelijk is (kwestie van een kortste pad te kunnen berekenen). Equivalent met die ServiceJourneyLinks zijn de LinkedConnections van @pietercolpaert. Ik zocht iets gelijkaardig in NETEX en kwam uit bij Call (dat zegt welke Lijn wanneer langskomt in een StopPoint, erg vergelijkbaar met een TimeTabledPassingTime inderdaad). Sowieso kreek ik van Pieter daarop al de kritiek dat dit niet echt een link is, hoewel je via de followedBy-associatie wel naar het volgende ScheduledStopPoint kan en dan daarvan de Call kan opvragen. Kortom: ik denk dat we Call beter terug uit het model halen en er de ServiceJourneyLink/linkedConnection opnieuw voor in de plaats zetten. Enig probleem daarmee is dat iets als ServiceJourneyLink/LinkedConnection dus niet in NETEX voorkomt of is dat wel het geval?

[skinkie]

@GeertThijs ik denk dat @pietercolpaert bij Kasia van de week eens zou moeten vragen of die LinkedConnection uberhaupt in Transmodel zit.

[GeertThijs]

Vraag is dus of in Transmodel iets als dit aanwezig is:

Bedoeld om routeplanners te ondersteunen.

[skinkie]

@GeertThijs Dit lijkt heel erg op een Call. Dat is de structuur die weer heel erg lijkt op TimetabledPassingTime.

[GeertThijs]

ServiceJourneyLink brengt info samen uit ScheduledStopPoint, de bijbehorende TimeTabledPassingTime en de ServiceLink:

• ServiceJourneyLink.departureStop = ServiceLink.from (ScheduledStopPoint)
• ServiceJourneyLink.arrivalStop = ServiceLink.to (ScheduledStopPoint)
• ServiceJourneyLink.departureTime = ServiceLink.from>ScheduledStopPoint.viewedAs>PointInJourneyPattern.at>TimeTabledPassingTime.departureTime
• ServiceJourneyLink.arrivalTime = ServiceLink.to>ScheduledStopPoint.viewedAs>PointInJourneyPattern.at>TimeTabledPassingTime.departureTime
• ServiceJourneyLink.line = ScheduledStopPoint.viewedAs>PointInJourneyPattern.journyPattern.route>Route.line

Beetje ingewikkelde query, maar in essentie is alles al aanwezig in het model, het is een klasse for convenience, met afgeleide informatie.
Lijkt inderdaad op een Call, die ik oorspronkelijk als volgt had gemodelleerd:

maar het perspectief van een Call is niet dat van een Routeplanner die onmiddellijk wil weten waar naartoe om een kortste pad te bepalen maar dat van een Reiziger die aan een halte staat en wil weten wanneer de bus komt (en slechts optioneel waar die naartoe gaat, ttz de volgende Call).

[GeertThijs]

Dus ik denk dat die ServiceJourneyLink wel nuttig is, tenzij er dus een equivalent is in Transmodel/NETEX dat ik over het hoofd heb gezien. In EPIP zit het in elk geval niet (Call overigens ook niet).

[skinkie]

@GeertThijs dan was je vraag was me niet helemaal duidelijk. Als je daadwerkelijk een model zoekt dat over resultaten gaat, dan zou 'legs' meer passen. In de repo staat ook al een mapping document naar Transmodel klaar. https://github.com/vdvde/ojp/tree/changes_for_v1.1

[GeertThijs]

Nee, Legs zijn het ook niet. Een Leg is een deel van een Trip, bvb om van A naar B te gaan doe ik eerst een stuk met de Fiets (Leg 1), daarna neem ik de trein (Leg 2) en na aankomst ga ik nog effe te voet (Leg 3). We modelleerden dit in OSLO Trips & Aanbod als RouteSegment, helaas toen niet afgestemd op Transmodel deel 6.