TrainElementType vs TrainElement
Opened this issue · 10 comments
for accessibility we need the concrete elements as well.
Are there three separate questions here?
(a) How should we handle renaming of TrainElement to TrainElementType ? (As an additional deprecated element?).
(b) Do we need to implement train composition elements as below so can distinguish between types and instances. This has been added to Transmodel and NEtex UML but tot to XML yet as wasnt sure if specific train was really netex or / SIRI content
c) Should the carriages and wagons just go in Resource frame as additional "Vehicles" or should
@nick-knowles I thought mostly about b). c) is not a complete sentence. So I am not sure, if it is affected. a) is not that important to me...
Other problem: the new TrainElementType would contain the TrainElementGroup which contains an element TrainElementType which is an enumeration. Sorry, not thought trough.
I think also, that was decided in Transmodel is in direct conflict with the new SIRI European profile.
I would like to see from you a picture of a Train with two TrainCompounds with 3 carriages each and then label, how this would need to be done with Type and concrete TrainElements (with EVN numbers). Currently I think it is overengineered and the CompoundTrain TrainComponent etc is misleading at best.
And for demonstration the problem with TrainElementType within TrainElementType:
Carriage E
5th Carriage
carriage
standardClass
If anything I would have prefered:
for type based data:
<TrainComponent ...
<TrainElementType ....
for real vehicles
<TrainComponent ...
<TrainElement .....
Strangly enough TrainElementTypeGroup contains "equipments". Which can't be on a Type.
The renaming just doesn't work.
I guess we need really:
TrainElement (abstract)
TrainElementType inherits from TrainElement
ConcreteTrainElement inherits from TrainElement
We have TrainElementTypeGroup
(which contains TrainElementTypeGroup and no equipments)
and we have ConcreteTrainElementGroup
(which contains TrainElementTypeGroup and the equipments and the EVN number or at least a note, where to store it, if it exists)
Also: currently DECK PLAN only associates with the TrainElementType. I hope this is working for the use cases.
It's a pretty long and complex discussion with a lot of inputs coming from rail people, and requires a synchronisation with TM, and SIRI ...
My main question is "can we stay with what we have ?" ... I'm not sure that we really have a instance related use case for NeTEx (probably more in the SIRI side).
If so, the fact that currently DECK PLAN only associates with the TrainElementTypeRef, need to be documented (or renamed to TrainElementRef) since our current TrainElementType is an enum (TrainElementTypeTypeEnumeration) which cannot be refered.
What should the current situation be? TrainComposition is not implemented yet (and I oppose it). Other stuff from DeckPlan is already integrated. And I think that TrainElement -> TrainElementType is in principle also be implemented already.
The TRAIN COMPOSITION is "A specific instance of a TRAIN composed of TRAIN COMPOSITION COMPONENTs in a certain order.", that's the " instance related use case" I'm mentioning. DeckPlan is Ok and independent (currently possibly assigned to VehicleType and specialisations, TrainComponent, TrainElement(Type) Journey or journeyPart).
Isn't it enough for now ?
My problem is, that this is exactly what TrainElement did (and does in Siri) before some people thought they needed a TrainElementType and then tried to rename TrainElement. This results in Siri/OJP being no longer aligned with Transmodel. I
So you are against the renaming in Transmodel, right ?