Proposal for a Transmodel-aligned alternative to DatedServiceJourney

[Ulf9]

DATED VEHICLE JOURNEYs can be added and altered in real time and are thus mainly in scope of SIRI. There is however one related concept that is relevant both to SIRI and NeTEx , it is the NORMAL DATED VEHICLE JOURNEY that represents an exact image of the theoretical plan , applied to a specific OPERATING DAY, as constructed during the scheduling process.

So I suggest that the DatedServiceJourney is deprecated, as it does not really match any existing Transmodel concept, nor fully fulfil the needs to link a cancelled long term planned NORMAL DATED VEHICLE JOURNEY with one or more planned replacement NORMAL DATED VEHICLE JOURNEYs.

Instead I propose that we add the possibillity to include NORMAL DATED VEHICLE JOURNEY information in ServiceJourney, DeadRun and VehicleJourney.

Below a series of images detailing the proposed change. I will also shortly add a Pull request for this issue.

ExampleOfDatedServiceJourneyReplacement_01_XML.zip

[Aurige]

don't we have this now (does not provide anything about the replacement of dated journey, but it looks that we have 2 # versions ... it's like this in both master and new mode braches) ?

[Ulf9]

Yes, good observation, you are right. I should have mentioned and suggested the removal of the recently added DatedVehicleJourney and NormalDatedVehicleJourney in the Master as well. Analogue to the DatedServiceJourney a deeper analysis shows that both of those are also in an inappropriate place in the schema. They are not specializations of VEHICLE JOURNEYs as is apparent when you compare with Transmodel:

I think my proposal is better aligned with Transmodel, helps enforce the division between SIRI and NeTEx better and still allows the needed identifiers for NormalDatedVehicleJourney to be provided as well as allowing that replacement relations can be described in a clear way. At the same time simplifying the schema and reducing the divergence in how to describe the validity of a ServiceJourney.

[Aurige]

We need to be careful when removing: I just checked and the DatedServiceJourney is quite heavily used in the mapping done by ERA (Stefan Jugelt), meaning that it may have been used by some systems, and we don't want to break compatibility. Also such change will require an update of this mapping. Shouldn't we rather see this as an extension at first ?

[Ulf9]

I agree that DatedServiceJourney has existed for a long time and can simply not be removed from one day to another, that is why I suggest only denoting it as deprecated, but leave it as is in the schema. Regarding the addition of DatedVehicleJourney and NormalDatedVehicleJourney there is a different situation, they were just added to the master last summer, I would rather remove them if possible, but if you think it is a good idea, we could leave them but mark them as deprecated as well? I fear that leaving NormalDatedVehicleJourney may lead to unneccessary confusion where people believe that they must expand every instance, date by date, of every ServiceJourney for complete operating periods, this would not be efficient... Do you still recommend I should reinstate DatedVehicleJourney and NormalDatedVehicleJourney in the schema?

[Aurige]

This addition was requested by Entur... @syversenkr, is it something that you are already using ?

[syversenkr]

Yes, this is something we are going to use extensively in Norway/Nordics e.g. for modelling of individual Train and bus services requiring explicit references for example when being ticketed/validated with seating allocation. Dated journeys are also used for backwards/historical referencing of journey "state" when mere versioning is insufficient/cumbersome/incorrect to maintain this in the dataset, but the latter is something this remodeling seeks to address.

Though, self contained (normal) dated service journey views for maintaining the OperationDay (and to model replaced journeys, which in them selves are references to "external" dated journeys) seems quite cumbersome given that (at least my understanding of) a view should contain a subset of an object (in this case an existing NormalDatedVehicleJourney)? Or perhaps not, as this View actually "duplicated" the ServiceJourney object which it is already contained within?

That I will leave up to you masters of Transmodel to concider.

On the more technical/pragmatical side, besides Transmodel compliance (meaning unless there are really good reasons, that I am unaware of, for dated journeys this being modeled as separate entities per Transmodel snippet above, should we not rather prefer the conceptual model to be aligned with the implemented models - i.e. being a key concept in SIRI as well as already implemented journey subtypes in NeTEx?), is there really much benefit in introducing this quite extensive tree-structured containment to facilitate referencing/dependencies already (almost fully) in place in current NeTEx?

[Aurige]

I must admit that I'm getting a bit lost... can we try to summarise a bit and see what we want to achieve in the most possible concise way ?

My current understating is that:

• there is a need to track/describe the changes in dated vehicle journeys (from one scheduled dataset to another .. so from one version of a frame to another)
• there is also a need to track/describe the changes in train (vehicle) composition (...)
• these needs are linked to fare/ticket-sales in order to be able to inform the passenger about any change regarding the dated vehicle journey they booked (intend to use) with their ticket
• up to now, we already had in NeTEx all wee needed to fully describe vehicle journeys and train composition, but without the ability to track their evolution (including replacements) from one dataset/frame-version to another (only through the versioning mechanism). This new need for tracking changes/evolution is directly linked to the previous point (inform about change concerning specific reservations/tickets).

Am I right or is there anything else ?

[Ulf9]

I have added an example file and changed the Github-proposal on Ulf9/NeTEx so that it does not use views. Instead it allows that normalDatedVehicleJourneys can be specified within a ServiceJourney ( as well as within a VehicleJourney). Observe that the NormalDatedVehicleJourney is in this case not a duplication of everything already specified in the ServiceJourney but only contains the identifier, the OperatingDayRef and optionally a Status describing if it is planned, cancelled, cancelledAndReplaced, cancelledAndHasAlternative or is a plannedReplacement. Optionally it is possible to define backwards/historical referencing. I think the proposal is well inline with what Mike Stallybrass is asking for also concerning:

1. a more universal usage, where the DatedVehicleJourney can be seen as enhancing the VehicleJourney data, it would be better if the DatedVehicleJourney construct can also be nested within a VehicleJourney.
2. date-specific journey ids

[ue71603]

@Aurige I think we need to discuss tomorrow, what to do here.

[Aurige]

Isn't this answered by https://github.com/NeTEx-CEN/NeTEx/pull/520 ?

[ue71603]

I guess this must be answered by @Ulf9

[Aurige]

See https://github.com/NeTEx-CEN/NeTEx/pull/520 and discussed in meeting # 13 and # 14 ... Part 2 updated