Home » railML newsgroups » railml.timetable » TrainpartRefs
TrainpartRefs [message #745] Fri, 02 September 2011 11:01 Go to next message
Andreas Tanner is currently offline  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 #746 is a reply to message #745] Wed, 07 September 2011 14:48 Go to previous messageGo to next message
Christoph.Jobmann is currently offline  Christoph.Jobmann
Messages: 12
Registered: October 2010
Junior Member
Greetings,

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.
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.
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.

Best regards
Christoph Jobmann

Andreas Tanner wrote:
>
> 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.
>
>



--
----== posted via PHP Headliner ==----
Re: TrainpartRefs [message #748 is a reply to message #746] Wed, 07 September 2011 15:55 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  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 Go to previous messageGo to next message
Andreas Tanner is currently offline  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 #750 is a reply to message #745] Fri, 09 September 2011 10:23 Go to previous messageGo to next message
Carsten Weber is currently offline  Carsten Weber
Messages: 27
Registered: November 2011
Junior Member
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
Re: TrainpartRefs [message #751 is a reply to message #748] Fri, 09 September 2011 10:32 Go to previous messageGo to next message
Carsten Weber is currently offline  Carsten Weber
Messages: 27
Registered: November 2011
Junior Member
"Susanne Wunsch" <coord(at)commonrailmlde> schrieb im Newsbeitrag
news:bb262l4ihinfsf(at)remiheepsaxde...
> Hello,
>
> 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.
>
In my view maybe we can reduce the contents of ocpsTT (I'm not sure) but we
can not remove it.
For example by running night trains there are train parts which are combined
in an operational train but you are not allowed to board or leave one of the
train parts at each stop. You might look at train D 61458 and CNL 458 at the
current timetable period. Both train parts run from Praha to Erfurt. But you
are not allowed to leave CNL 458 between Praha and Erfurt in opposition to D
61458.
So there will be (up to now) no other chance to bring this information into
RailML as to write some information about ocpTT to the train parts.

> 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.

Life means change. ;) But we should make sure that these changes are really
needed.

Best regards.

Carsten Weber
Re: TrainpartRefs [message #753 is a reply to message #750] Mon, 03 October 2011 11:58 Go to previous messageGo to next message
Joachim Rubröder railML is currently offline  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 Go to previous message
Susanne Wunsch railML is currently offline  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
Previous Topic: Frage zu TT:category
Next Topic: deprecated attribute "trainLine" for element "trainPart"
Goto Forum:
  


Current Time: Fri Mar 29 16:40:51 CET 2024