NeTEx-CEN/NeTEx

ServiceLink not possible for Garage Points / Garage RunIn / Garage RunOut

duexw opened this issue · 8 comments

duexw commented

In the German VDV 462 we use ServiceJourneyPattern to describe the sequence of stop points, the sequence of links and the run times between stops. A ServiceJourneyPattern for a regular passenger journey looks like this:
image
The same service link may be shared by many service patterns for efficiency.

For a ServiceJourneyPattern starting at a garage, it looks very much the same, only the type is "garageRunOut" and the first point in sequence is a garage point instead of a scheduled stop point:
image

However, we cannot reference a ServiceLink going from the garage from the first stop of the subsequent journey.
Theoretically we could, but service link does not allow GaragePoint as start or end point.
image

This leaves us with the only option to put the distance and the coordinate sequence into the timing link - which is kind of awkward, as these values are in ServiceLink for all other links.

We therefore propose to allow GaragePoint as start and end of ServiceLink. Alternatively, we propose the introduction of a DeadrunLink, which can be referenced from ServiceJourneyPattern/linksInSequence

For the GaragePoint towards the first ScheduledStopPoint you would use TimingLink with a TimingLinkinSequence. It is not awkward, it is awkward that unlike The Netherlands you have prefered ServiceLink while TimingLink would have been the more generic option.

duexw commented

I proposed using timinglink in this situation, but the VDV workgroup was not happy with the solution. Some have already implemented interfaces and they do not want to change them much.

Again a typical "German AVL company" answer. But certainly not a reason to change a European standard. Especially since this change will change the XSD, which the "German AVL company" will then also not use to implement their exports ;)

duexw commented

Stefan,
OK you may jeer at German AVL companies, but you have to admit that the VDV standards did succeed at providing a certain interoperability between systems. Also they put quite a bit of work into the German NeTEx profile.
The point is:

  • You can use ServiceJourneyPattern for garage trips and dead runs
  • You could also use DeadrunJourneyPattern to be more explicit
  • But even if you use DeadrunJourneyPattern, there is no such thing as a DeadrunLink to transfer the distance between Garage and first stop of regular service.
    Let us discuss this in the goup and see what solution we find.

Stefan, OK you may jeer at German AVL companies, but you have to admit that the VDV standards did succeed at providing a certain interoperability between systems.

Can you give a single example of a system of IVU of Init that can actually import NeTEx? Or a system of Mentz handling multiple ServiceCalendars? There is actually zero interopability if the only thing that happens is only capable of throwing an export over the fence.

Credits where credits are due. In my perspective VDV462 is the best documented standard in the NeTEx ecosystem.

Also they put quite a bit of work into the German NeTEx profile. The point is:

  • You can use ServiceJourneyPattern for garage trips and dead runs
  • You could also use DeadrunJourneyPattern to be more explicit

The problem is there is a mix beween the service and non-service parts. If it was modelled properly at the source it would be a Block with a DeadRun, ServiceJourney, etc. DeadRun. But it goes beyond the discussion. In The Netherlands we are using TimingPoint for locations where we want to have a PassingTime (like a bridge) but there is no opportunity to board or alight. It is something different than actually starting the trip somewhere else.

  • But even if you use DeadrunJourneyPattern, there is no such thing as a DeadrunLink to transfer the distance between Garage and first stop of regular service.
    Let us discuss this in the goup and see what solution we find.

If you have a DeadRun and a DeadRunPattern, it consists of TimingLinksInJourneyPattern. The ToPointRef of that TimingLink would be the first ScheduledStopPoint of the service journey. I think nameOfRefClass would be nice to have on it.

            <TimingLink id="ARR:TimingLink:53519011-53517002-">
              <Distance>0</Distance>
              <FromPointRef ref="ARR:TimingPoint:53519011"/>
              <ToPointRef ref="ARR:ScheduledStopPoint:53517002"/>
            </TimingLink>

            <DeadRunJourneyPattern id="ARR:DeadRunJourneyPattern:1:90">
              <Name>90</Name>
              <pointsInSequence>
                <TimingPointInJourneyPattern id="ARR:TimingPointInJourneyPattern:523606:1:90-1" order="1">
                  <TimingPointRef ref="ARR:TimingPoint:53519011"/>
                  <OnwardTimingLinkRef ref="ARR:TimingLink:53519011-53517002-"/>
                </TimingPointInJourneyPattern>
                <StopPointInJourneyPattern id="ARR:StopPointInJourneyPattern:523606:1:90:2" order="2">
                  <ScheduledStopPointRef ref="ARR:ScheduledStopPoint:53517002"/>
                </StopPointInJourneyPattern>
              </pointsInSequence>
            </DeadRunJourneyPattern>

            <TimeDemandType id="ARR:TimeDemandType:1:90">
              <runTimes>
                <JourneyRunTime id="ARR:JourneyRunTime:1:90:1">
                  <TimingLinkRef ref="ARR:TimingLink:53519011-53517002-"/>
                  <RunTime>PT120S</RunTime>
                </JourneyRunTime>
              </runTimes>
            </TimeDemandType>

            <DeadRun id="ARR:DeadRun:523602:1:8057">
              <validityConditions>
                <AvailabilityConditionRef ref="ARR:AvailabilityCondition:523602"/>
              </validityConditions>
              <PrivateCode type="JourneyNumber">8057</PrivateCode>
              <DepartureTime>09:47:00</DepartureTime>
              <DepartureDayOffset>0</DepartureDayOffset>
              <dayTypes>
                <DayTypeRef ref="ARR:DayType:7"/>
              </dayTypes>
              <DeadRunJourneyPatternRef ref="ARR:DeadRunJourneyPattern:1:90"/>
              <TimeDemandTypeRef ref="ARR:TimeDemandType:1:90"/>
              <DeadRunType>garageRunOut</DeadRunType>
            </DeadRun>
duexw commented

To save the honour of IVU - There is a customer project where we (MENTZ) export NeTEx and they import it. As it is a running project, I cannot disclose details about it.

So to summarize: You recommend to put the distance and coordinate sequence between garage and first stop into TimingLink for the above mentioned use case.

To save the honour of IVU - There is a customer project where we (MENTZ) export NeTEx and they import it. As it is a running project, I cannot disclose details about it.

I guess you mean IVU.cloud. https://www.ivu.com/all-references/references/delfi-migrates-to-ivucloud

It is being sold to a client of mine IVU.pool has no NeTEx import what so ever and would require a custom implementation.

So to summarize: You recommend to put the distance and coordinate sequence between garage and first stop into TimingLink for the above mentioned use case.

There are two suggestions:

  1. Split the garage run into a DeadRun
  2. Use a TimingLink for the GaragePoint <-> First ScheduledStopPoint

If I recall correctly VDV462 does not use RouteLink to use the geographical routes, so the coordinate can then be placed on the LineString of the TimingLink.

duexw commented

Discussed with VDV workgroup at meeting on 10.07.2023. We will accept Suggestion 2 and put the distance and coordinates into the timing link for all deadrun segments of the pattern (garrage run in / out, connecting trip)