TrainpartRefs [message #745] |
Fri, 02 September 2011 11:01 |
Andreas Tanner
Messages: 52 Registered: March 2012
|
Member |
|
|
Hallo RailML-group,
is the <trainPart> element intended for "multiple use"? The example file
TT_ICN.xml has
<train id="o2109" name="ICN 2109" type="operational" trainNumber="2109"
description="betrieblicher Zug 2109 mit 2 Kompositionen">
<trainPartSequence sequence="1" pathStatus="confirmed">
<trainPartRef position="1" ref="tp2109" />
<trainPartRef position="2" ref="tp2109" />
Now if this is legal, there is a problem with the rostering. A
<blockPart> can reference a <trainPart> - but which reference to it is
meant if the <trainPart> is used more than once?
What one really would need is a "<trainPartRefRef" and the
<trainPartRef> children of the <trainPartSequence> would need there own
ID...
I think that we /should/ allow for multiple use of trainparts. If you
have different views on the same train (eg, commercial and operational),
you would build those views from the same trainPart elements.
Regards
--Andreas Tanner.
|
|
|
|
Re: TrainpartRefs [message #748 is a reply to message #746] |
Wed, 07 September 2011 15:55 |
Susanne Wunsch railML
Messages: 0 Registered: January 2020
|
|
|
|
Hello,
christophjobmann(at)deutschebahncom (Christoph Jobmann) writes:
> from my point of view trainPart elements can no longer be used more than
> once within the same trainPartSequence if rostering is included. In this
> case you will need several almost identitical trainParts - the only
> difference will be the id-attribute.
I go with your statement. You can't deploy reservation info when using
the same train part several times in a commercial train. All the other
'formationTT' elements could also differ for train parts running in the
same train through the same 'ocpTT's.
> Furthermore I don't like the thought of multiply referring to the same
> trainPart when working with commercial and operational trains since you
> will not be able to distinguish which references to trainParts in the
> operational train are included in which commercial train.
That's a really good point. Thanks for mentioning.
> I do realize that this leads to many identical trainPart-Elements; yet I
> find it neccessary to transmit the needed information without extending
> the standard.
railML should stay as redundancy-free as possible in the context of the
current model.
If it would be appreciated, we could separate the "ocpsTT" element for
referencing it from each train part. But I think that there are some
cases where some deep attributes of ocpTT differ between the coupled
train parts. Yes, it's a very seldom use case that should be covered,
too.
railML 2.1 is even just released, so I'm not very happy in changing
some core syntax. On the other hand, if that change would bring even
more users to railML, it would be worth.
Let's go on with this topic in this thread. Maybe it's good for the
next major release.
Any ideas, comments, questions appreciated...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
Re: TrainpartRefs [message #749 is a reply to message #748] |
Thu, 08 September 2011 17:04 |
Andreas Tanner
Messages: 52 Registered: March 2012
|
Member |
|
|
I suggest that if two trainpartrefs refer to the same trainpart, it is
to be understood that they point to the same physical entity. So if you
have two views on the set of trains within one file (as commercial and
as operational trains), then they can "share" trainparts. But multiple
use in the sense of "another copy of that trainpart" is not allowed, in
particular not as different positions within one trainpart sequence.
About separation of ocpTT sequences: this resembles to what we do in
IVU.plan anyway, but we go even further by defining "route pattern" that
can be anchored per trip to a start / arrival / intermediate time.
--Andreas.
Am 07.09.2011 15:55, schrieb Susanne Wunsch:
> Hello,
>
> christophjobmann(at)deutschebahncom (Christoph Jobmann) writes:
>> from my point of view trainPart elements can no longer be used more than
>> once within the same trainPartSequence if rostering is included. In this
>> case you will need several almost identitical trainParts - the only
>> difference will be the id-attribute.
>
> I go with your statement. You can't deploy reservation info when using
> the same train part several times in a commercial train. All the other
> 'formationTT' elements could also differ for train parts running in the
> same train through the same 'ocpTT's.
>
>> Furthermore I don't like the thought of multiply referring to the same
>> trainPart when working with commercial and operational trains since you
>> will not be able to distinguish which references to trainParts in the
>> operational train are included in which commercial train.
>
> That's a really good point. Thanks for mentioning.
>
>> I do realize that this leads to many identical trainPart-Elements; yet I
>> find it neccessary to transmit the needed information without extending
>> the standard.
>
> railML should stay as redundancy-free as possible in the context of the
> current model.
>
> If it would be appreciated, we could separate the "ocpsTT" element for
> referencing it from each train part. But I think that there are some
> cases where some deep attributes of ocpTT differ between the coupled
> train parts. Yes, it's a very seldom use case that should be covered,
> too.
>
> railML 2.1 is even just released, so I'm not very happy in changing
> some core syntax. On the other hand, if that change would bring even
> more users to railML, it would be worth.
>
> Let's go on with this topic in this thread. Maybe it's good for the
> next major release.
>
> Any ideas, comments, questions appreciated...
> Susanne
>
|
|
|
|
|
Re: TrainpartRefs [message #753 is a reply to message #750] |
Mon, 03 October 2011 11:58 |
Joachim Rubröder railML
Messages: 0 Registered: November 2019
|
|
|
|
Hi,
you are totally right.
The multiple use of the same trainPart in different trainPartSequences
provides problems together with the use of rosterings or resevations.
I therefore corrected the exaple to:
<trainPartRef position="1" ref="tp2109a" />
<trainPartRef position="2" ref="tp2109b" />
Best regards,
Joachim Rubröder
Carsten Weber wrote:
>
> Dear RailML-Users,
>
> "Andreas Tanner" <ata(at)ivude> schrieb im Newsbeitrag
> news:j3q8j2$386$1(at)sifaivifhgde...
>> Hallo RailML-group,
>>
>> is the <trainPart> element intended for "multiple use"? The example file
>> TT_ICN.xml has
>>
>> <train id="o2109" name="ICN 2109" type="operational" trainNumber="2109"
>> description="betrieblicher Zug 2109 mit 2 Kompositionen">
>> <trainPartSequence sequence="1" pathStatus="confirmed">
>> <trainPartRef position="1" ref="tp2109" />
>> <trainPartRef position="2" ref="tp2109" />
>>
> For me it looks like a mistake in the example.
> The example should look like this:
>
>> <trainPartRef position="1" ref="tp2109a" />
>> <trainPartRef position="2" ref="tp2109b" />
>
> Maybe tp2190a includes the same vehicle(s!) as tp2109b but maybe not.
> This way you can differ between the train parts in the rostering process.
>
> If it is necessary there should be an extension inside of the train parts if
> for example several coaches are combined in a train part and you want to
> create a roster for every single coach. But up to now no one has been
> interested in.
>
> Best regards.
>
> Carsten Weber
>
>
>
>
--
----== posted via PHP Headliner ==----
|
|
|
Re: TrainpartRefs [message #848 is a reply to message #753] |
Tue, 06 November 2012 14:00 |
Susanne Wunsch railML
Messages: 0 Registered: January 2020
|
|
|
|
Hi Joachim, Carsten, Andreas and others,
Sorry for the late re-activating of this "quite closed thread".
coord(at)timetablerailmlorg (Joachim Rubröder) writes:
> you are totally right.
>
> The multiple use of the same trainPart in different trainPartSequences
> provides problems together with the use of rosterings or resevations.
>
> I therefore corrected the exaple to:
> <trainPartRef position="1" ref="tp2109a" />
> <trainPartRef position="2" ref="tp2109b" />
If found some more occurences in another example. :-(
"TT_Rostering.xml"
<trainPartRef position="1" ref="tp_651_RB_36301_4" />
<trainPartRef position="2" ref="tp_651_RB_36301_4" />
<trainPartRef position="1" ref="tp_651_RB_36301_5a" />
<trainPartRef position="2" ref="tp_651_RB_36301_5a" />
The possible double reference of one trainPart in either a "commercial"
train and/or a "operational" train for enabling both views should be
documented at the wiki-Documentation-Page. [1]
Kind regards...
Susanne
[1] http://www.wiki.railml.org/index.php?title=TT:trainPartRef
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|