Home » railML newsgroups » railml.timetable » infrastructure train path: where to put path parameters
infrastructure train path: where to put path parameters [message #915] Fri, 25 January 2013 15:52 Go to next message
Andreas Tanner is currently offline  Andreas Tanner
Messages: 52
Registered: March 2012
Member
Dear all,

where is the right place to put the properties of a (ordered or
confirmed) train path? Could we enrich trainPartSequence with an
attribute pathFormationRef with a reference to a formation?

Best, Andreas.
Re: infrastructure train path: where to put path parameters [message #936 is a reply to message #915] Tue, 12 March 2013 19:38 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Andreas,

what do you mean with "path properties"?

For the state of a train (whether it is ordered, published, invoiced...)
currently there is <trainPart>."processStatus". We did not find its
pre-defined values very helpful, so we use a lot of "other:..." values
with it.

I also would have preferred it at <trainPartSequence> rather than at
<trainPart>. But the original intention was to consequently put everything
into <trainParts> as the real "atoms" of trains. And since I am also a
friend of consequence, I did not invent. I think it is not redundancy:
Sometimes we have different operators for two train parts at the same
<trainPartSequence>, e. g. EB and STB run coupled between Erfurt and
Plaue. One could imagine that there are different states of the
<trainParts> even at the same section: One has already payed its invoice
(processStatus="payed"), the other not (processStatus="invoiced,
reminded...") ;-)

A formationRef is already there at <trainPart>. It is a reference to a
vehicle formation.

Best regards,
Dirk.
Re: infrastructure train path: where to put path parameters [message #937 is a reply to message #936] Wed, 13 March 2013 09:00 Go to previous message
Andreas Tanner is currently offline  Andreas Tanner
Messages: 52
Registered: March 2012
Member
My question regards the properties of the slot (Trasse). They can be
expressed as properties of a formation. Of course, that formation is
different from the ones referred to in the <trainPart>s.

Best, Andreas.

Am 12.03.2013 19:38, schrieb Dirk Bräuer:
> Dear Andreas,
>
> what do you mean with "path properties"?
>
> For the state of a train (whether it is ordered, published, invoiced...)
> currently there is <trainPart>."processStatus". We did not find its
> pre-defined values very helpful, so we use a lot of "other:..." values
> with it.
>
> I also would have preferred it at <trainPartSequence> rather than at
> <trainPart>. But the original intention was to consequently put
> everything into <trainParts> as the real "atoms" of trains. And since I
> am also a friend of consequence, I did not invent. I think it is not
> redundancy: Sometimes we have different operators for two train parts at
> the same <trainPartSequence>, e. g. EB and STB run coupled between
> Erfurt and Plaue. One could imagine that there are different states of
> the <trainParts> even at the same section: One has already payed its
> invoice (processStatus="payed"), the other not (processStatus="invoiced,
> reminded...") ;-)
>
> A formationRef is already there at <trainPart>. It is a reference to a
> vehicle formation.
>
> Best regards,
> Dirk.
Previous Topic: circulations should be optional
Next Topic: problems with <train>s: uniqueness constraints, scope
Goto Forum:
  


Current Time: Fri Mar 29 06:16:24 CET 2024