Home » railML newsgroups » railml.timetable » stop probability
stop probability [message #735] Tue, 31 May 2011 11:31 Go to next message
Susanne Wunsch is currently offline  Susanne Wunsch
Messages: 180
Registered: March 2008
Senior Member
<text xml:lang="en">

Hi,

I search for a possibility to store a stop probability for "stops on
request" in <ocpTT> or better its <stopDescription>. It could be
determined in percentage (0 .. 100 %). It's not a result of an statistic
analyses but an expected value as rule of thumb or empirical value.

I would define my own anyAttribute, but that's not allowed for
<stopDescription>.

Would you allow anyAttribute in <stopDescription> or define such an
attribute or point me to a better solution?

Thanks in advance...
Susanne

</text>

<text xml:lang="de">

Hallo,

ich suche eine Möglichkeit, den Wert "Haltewahrscheinlichkeit" für
"Bedarfshalte" entweder in <ocpTT> oder besser noch <stopDescription> zu
definieren. Der Wert könnte in Prozent (0 .. 100 %) angegeben werden. Er
stellt kein Ergebnis einer statistischen Analyse dar, sondern eher einen
Erwartungswert auf Grundlage von Erfahrungswerten oder empirischen
Untersuchungen.

Ich würde dafür ein eigenes anyAttribute definieren, aber das ist im
Element <stopDescription> derzeit nicht valide.

Könnte anyAttribute in <stopDescription> erlaubt werden, oder solch ein
Attribut definiert werden oder würde mir jemand eine günstigere Lösung
aufzeigen?

Dankeschön im voraus...
Susanne

</text>
Re: stop probability [message #736 is a reply to message #735] Tue, 31 May 2011 14:31 Go to previous messageGo to next message
Joachim Rubröder is currently offline  Joachim Rubröder
Messages: 88
Registered: April 2007
Member
Hi,
I would suggest to use an "anyAttribute" within the <stopDescription>.
This is the right place, because "stopOnRequest" is already there.

If there is anyone else with the same request, we could prepare a new
field for a future version.

Kind regards,
Joachim


Susanne Wunsch wrote:
>
>
> <text xml:lang="en">
>
> Hi,
>
> I search for a possibility to store a stop probability for "stops on
> request" in <ocpTT> or better its <stopDescription>. It could be
> determined in percentage (0 .. 100 %). It's not a result of an statistic
> analyses but an expected value as rule of thumb or empirical value.
>
> I would define my own anyAttribute, but that's not allowed for
> <stopDescription>.
>
> Would you allow anyAttribute in <stopDescription> or define such an
> attribute or point me to a better solution?
>
> Thanks in advance...
> Susanne
>
> </text>
>
> <text xml:lang="de">
>
> Hallo,
>
> ich suche eine Möglichkeit, den Wert "Haltewahrscheinlichkeit" für
> "Bedarfshalte" entweder in <ocpTT> oder besser noch <stopDescription> zu
> definieren. Der Wert könnte in Prozent (0 .. 100 %) angegeben werden. Er
> stellt kein Ergebnis einer statistischen Analyse dar, sondern eher einen
> Erwartungswert auf Grundlage von Erfahrungswerten oder empirischen
> Untersuchungen.
>
> Ich würde dafür ein eigenes anyAttribute definieren, aber das ist im
> Element <stopDescription> derzeit nicht valide.
>
> Könnte anyAttribute in <stopDescription> erlaubt werden, oder solch ein
> Attribut definiert werden oder würde mir jemand eine günstigere Lösung
> aufzeigen?
>
> Dankeschön im voraus...
> Susanne
>
> </text>
>
>



--
----== posted via PHP Headliner ==----
Re: stop probability [message #737 is a reply to message #736] Tue, 31 May 2011 15:24 Go to previous messageGo to next message
Susanne Wunsch is currently offline  Susanne Wunsch
Messages: 180
Registered: March 2008
Senior Member
Hi Joachim,

coord(at)timetablerailmlorg (Joachim Rubröder) writes:

> I would suggest to use an "anyAttribute" within the <stopDescription>.
> This is the right place, because "stopOnRequest" is already there.
>
> If there is anyone else with the same request, we could prepare a new
> field for a future version.

Thanks for the quick response.

It would be nice to define the anyAttribute in <stopDescription>. That's
the best place for the needed attribute, I think.

There are further attributes which could be defined in
<stopDescription>:

* (serviceSectionRef) if platforms, ramps or other facilities are
defined as "serviceSection"s in IS [1]

* (stopPosition) if serviceSectionRef is used and the train is shorter
than the service section length

Kind regards...
Susanne

[1] http://trac2.assembla.com/railML/ticket/122
"stop post" / "platform edge" reference from ocpTT (was: stop probability) [message #845 is a reply to message #737] Tue, 06 November 2012 12:29 Go to previous messageGo to next message
Susanne Wunsch is currently offline  Susanne Wunsch
Messages: 180
Registered: March 2008
Senior Member
Hi Joachim and others,

Sorry for responding to my own posting. The time and implementation
changed. ;-)

Susanne Wunsch <coord(at)commonrailmlorg> writes:

> There are further attributes which could be defined in
> <stopDescription>:
>
> * (serviceSectionRef) if platforms, ramps or other facilities are
> defined as "serviceSection"s in IS [1]
>
> * (stopPosition) if serviceSectionRef is used and the train is shorter
> than the service section length
>
> [1] http://trac2.assembla.com/railML/ticket/122

Now the 'platformEdges' and 'stopPosts' are implemented in the
infrastructure sub-schema. Christian already opened a new Trac ticket
for not forgetting the reference from within a timetables <ocpTT> to the
appropriate <platformEdge> or <stopPost>. [1]

Is there the need for more than one reference to either a 'platformEdge'
or a 'stopPost'? I mean a 'trainPart' may only have one planned stop
position. No matter that it may change due to operational reasons.

* The <ocpTT> may already refer to the appropriate <track> where the
<platformEdges> and <stopPosts> may be defined.

* The <stopPost> itself may refer to a certain <platformEdge>.

* A reference from the <ocpTT> to either a certain <stopPost> or a
certain <platformEdge> is currently missing.

Both attributes ('stopPostRef' and 'platformEdgeRef') may be
introduced into the sub-element <stopDescription>.

If the 'stopPostRef' is used the 'platformEdgeRef' should be omitted,
it would be redundant to the infrastructure definition.

Both attributes are needed for different modeling levels. Some
software tool handles platforms without stop posts another tool
may only accept stop posts but no platforms.

* The current 'trackInfo' attribute in <ocpTT> would be marked
deprecated.

Any comments appreciated.

Kind regards...
Susanne

[1] http://trac.assembla.com/railML/ticket/171

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: "stop post" / "platform edge" reference from ocpTT (was: stop probability) [message #856 is a reply to message #845] Thu, 08 November 2012 21:31 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 187
Registered: August 2008
Senior Member
Dear Susanne and Joachim,

> * The <ocpTT> may already refer to the appropriate <track> where the
> <platformEdges> and <stopPosts> may be defined.

+1

> * The <stopPost> itself may refer to a certain <platformEdge>.

+1

> * A reference from the <ocpTT> to either a certain <stopPost> or a
> certain <platformEdge> is currently missing.

But they would be a kind of redundant to "the way via the track" which you
described above.

The 'platformEdgeRef' alone would not be redundant for the very special
case if there are two platform edges at the same track and the train is
scheduled to open the doors at one of them only...

I do not know this case from practice. So, I think we should wait until it
happens, if ever...

> Both attributes are needed for different modeling levels. Some
> software tool handles platforms without stop posts another tool
> may only accept stop posts but no platforms.

In other cases of that kind, RailML forces the user to use the one and
only way "in a wider sense". For instance, we force to create OCPs to
describe a timetable even for programmes which do not handle OCPs
(stations) themselves. We force to create <trainParts> to describe
arrival/departure times even for programmes which do not handle parts of
trains. I could name much more examples of that kind.

So why not "forcing" to use <ocpTT>.trackRef to come from a train to
platformEdges and stopPosts?

To reduce redundancy, I would prefer this way. I totally agree with
Andreas Tanners arguments on redundancy in an earlier. Andreas, now we can
avoid new redundancy here, I hope you also plead so.

> * The current 'trackInfo' attribute in <ocpTT> would be marked
> deprecated.

Generally: I understand and tend to agree. But: Do we possibly need the
"trackInfo" for additional (plain-text) info on the stop? Possibly remarks
for the passengers to be printed by a passenger information system?
Possibly for the difference between the railway-internal (IM's) track
number and a published platform number (think about Czech platforms -
there is a platform name additionally to the track number).

For the moment, I would leave the 'trackInfo' for individual plain-text
use like "remarks".

> Is there the need for more than one reference to either a 'platformEdge'
> or a 'stopPost'?

I don't think so. I would provide only one way and wait until somebody
claims and explains why there is a need for another one which is not
redundant.

Best regards,
Dirk.
Re: "stop post" / "platform edge" reference from ocpTT [message #858 is a reply to message #856] Thu, 08 November 2012 22:38 Go to previous messageGo to next message
Susanne Wunsch is currently offline  Susanne Wunsch
Messages: 180
Registered: March 2008
Senior Member
Dear Dirk, Joachim and others,

Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>> * A reference from the <ocpTT> to either a certain <stopPost> or a
>> certain <platformEdge> is currently missing.
>
> But they would be a kind of redundant to "the way via the track" which
> you described above.

There may be more than one stop post that refers to the same platform
edge.

I thought the train part should refer to its appropriate stop post if it
exists otherwise to the platform edge.

You may cut the platform edge ref from the ocpTT if you refer to the
stop post. There is a one-to-one reference from a stop post to a
platform edge. But nevertheless there is no need to define platform
edges at all. You may only define tracks and stop posts without platform
edges.

>> Both attributes are needed for different modeling levels. Some
>> software tool handles platforms without stop posts another tool
>> may only accept stop posts but no platforms.
>
> In other cases of that kind, RailML forces the user to use the one and
> only way "in a wider sense".

That would mean to keep the stop post ref and don't implement the
platform edge ref.

> So why not "forcing" to use <ocpTT>.trackRef to come from a train to
> platformEdges and stopPosts?

Sorry, I don't understand this suggestion.

>> * The current 'trackInfo' attribute in <ocpTT> would be marked
>> deprecated.
>
> Generally: I understand and tend to agree. But: Do we possibly need
> the "trackInfo" for additional (plain-text) info on the stop? Possibly
> remarks for the passengers to be printed by a passenger information
> system? Possibly for the difference between the railway-internal
> (IM's) track number and a published platform number (think about
> Czech platforms -
> there is a platform name additionally to the track number).
>
> For the moment, I would leave the 'trackInfo' for individual
> plain-text use like "remarks".

I'm totally with you. There are enough examples from the practice for
meaningful filling this attribute.

But I feel a bit uncomfortable in changing the semantics without
changing the attribute's name. The 'trackInfo' attribute is used for
platform numbers up to now with no appropriate attribute name.

>> Is there the need for more than one reference to either a 'platformEdge'
>> or a 'stopPost'?
>
> I don't think so. I would provide only one way and wait until somebody
> claims and explains why there is a need for another one which is not
> redundant.

I would like to ask in advance because of the experiences in other
cases: Changing an attribute into an element is not so easy done.

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: "stop post" / "platform edge" reference from ocpTT [message #862 is a reply to message #858] Fri, 09 November 2012 10:32 Go to previous messageGo to next message
Andreas Tanner is currently offline  Andreas Tanner
Messages: 51
Registered: March 2012
Member
Dear all,

I would tend to separate commercial aspects of a stop description from
operational ones. The Czech timetables, e.g., publish only platforms but
no tracks. It should be possible to express this in railML. Now we
/could/ say that for the sake of publication, the trackInfo attribute is
what you have to use. But this being purely textual, we would loose
reference to the infrastructure model.
That's why I would, with caution, pledge for being flexible here: allow
for an ocptt to refer to a platform without referring to a track or stop
post, as well as referring via the track.

By the way, now that we are going to support delay infos, what about
changes in tracks and platforms? Well, maybe an issue for 3.0 and a
dedicated scheme for operation...

Best, Andreas

Am 08.11.2012 22:38, schrieb Susanne Wunsch:
> Dear Dirk, Joachim and others,
>
> Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>>> * A reference from the <ocpTT> to either a certain <stopPost> or a
>>> certain <platformEdge> is currently missing.
>>
>> But they would be a kind of redundant to "the way via the track" which
>> you described above.
>
> There may be more than one stop post that refers to the same platform
> edge.
>
> I thought the train part should refer to its appropriate stop post if it
> exists otherwise to the platform edge.
>
> You may cut the platform edge ref from the ocpTT if you refer to the
> stop post. There is a one-to-one reference from a stop post to a
> platform edge. But nevertheless there is no need to define platform
> edges at all. You may only define tracks and stop posts without platform
> edges.
>
>>> Both attributes are needed for different modeling levels. Some
>>> software tool handles platforms without stop posts another tool
>>> may only accept stop posts but no platforms.
>>
>> In other cases of that kind, RailML forces the user to use the one and
>> only way "in a wider sense".
>
> That would mean to keep the stop post ref and don't implement the
> platform edge ref.
>
>> So why not "forcing" to use <ocpTT>.trackRef to come from a train to
>> platformEdges and stopPosts?
>
> Sorry, I don't understand this suggestion.
>
>>> * The current 'trackInfo' attribute in <ocpTT> would be marked
>>> deprecated.
>>
>> Generally: I understand and tend to agree. But: Do we possibly need
>> the "trackInfo" for additional (plain-text) info on the stop? Possibly
>> remarks for the passengers to be printed by a passenger information
>> system? Possibly for the difference between the railway-internal
>> (IM's) track number and a published platform number (think about
>> Czech platforms -
>> there is a platform name additionally to the track number).
>>
>> For the moment, I would leave the 'trackInfo' for individual
>> plain-text use like "remarks".
>
> I'm totally with you. There are enough examples from the practice for
> meaningful filling this attribute.
>
> But I feel a bit uncomfortable in changing the semantics without
> changing the attribute's name. The 'trackInfo' attribute is used for
> platform numbers up to now with no appropriate attribute name.
>
>>> Is there the need for more than one reference to either a 'platformEdge'
>>> or a 'stopPost'?
>>
>> I don't think so. I would provide only one way and wait until somebody
>> claims and explains why there is a need for another one which is not
>> redundant.
>
> I would like to ask in advance because of the experiences in other
> cases: Changing an attribute into an element is not so easy done.
>
> Kind regards...
> Susanne
>
Re: "stop post" / "platform edge" reference from ocpTT [message #866 is a reply to message #862] Fri, 09 November 2012 12:48 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 187
Registered: August 2008
Senior Member
Dear all,

> I would tend to separate commercial aspects of a stop description from
> operational ones. The Czech timetables, e.g., publish only platforms but
> no tracks. It should be possible to express this in railML.
....
> That's why I would, with caution, pledge for being flexible here: allow
> for an ocptt to refer to a platform without referring to a track or stop
> post, as well as referring via the track.

Please note that currently there is no <platform> in RailML in the "Czech
sense". We do have <platformEdges> but even _one_ "Czech" platform would
have _two_ <platformEdges>. Theres is, as far as I see, currently no
possibility to "to refer to a platform".

> Now we /could/ say that for the sake of publication, the trackInfo
> attribute is what you have to use. But this being purely textual, we
> would loose reference to the infrastructure model.

I agree: A non-plaintext possibility would be much better. But that would
mean to further expand RailML in this direction in advance - before we
have practical need. Since we cannot do everything at the same time, I
think it's better to postpone this and wait.

Let's remember that the current discussion was only about "trackInfo" to
declare obsolete or not.

> There may be more than one stop post that refers to the same platform
> edge.
>
> I thought the train part should refer to its appropriate stop post if it
> exists otherwise to the platform edge.

It is not common to do so in timetables because the operational rules
clarify which stop post to take and would always have "higher priority"
over any timetable information of that kind.

However, I agree that this could be a "theoretic wish", pure
informational: To get a part of the operational rules (which stop post to
take) into RailML. If we deem it necessary, we should provide the
"stopPostRef". Again, it would be a kind of redundant.

> That would mean to keep the stop post ref and don't implement the
> platform edge ref.
>
>> So why not "forcing" to use <ocpTT>.trackRef to come from a train to
>> platformEdges and stopPosts?
>
> Sorry, I don't understand this suggestion.

In my opinion, a platform and the stop posts always belong to the same
station. The "belonging" (linkage) of platforms and stop posts to a
station is an infrastructure information.

So why repeating this infrastructure information at each train? Isn't it
simpler to express is only one time in the infrastructure?

--> providing references from a <platformEdge> to an <ocp>: <platformEdge>
gets an "ocpRef".

--> We then also have the references from the stop posts to its ocp's via
the platformEdges, but there may be stop posts without platforms
(freight-only tracks), so: providing references from a <stopPost> to an
<ocp>: <stopPost> gets an "ocpRef".

--> A <trainPart><ocpTT> already refers to an <ocp> and a <track>. With
this information one can find the <platformEdges> and <stopPosts> through
the infrastructure.

Conclusion:
Since Andreas does not plead against this redundancy, I also would accept
a "shortcut" from <trainPart> with a "stopPostRef" or "platformEdge" or
both.

I think it is necessary to introduce the two "ocpRefs" at <platformEdge>
and <stopPost> because we cannot expect that the programmes always refer
to the stop posts.

Best regards,
Dirk.


>> I don't think so. I would provide only one way and wait until somebody
>> claims and explains why there is a need for another one which is not
>> redundant.
>
> I would like to ask in advance because of the experiences in other
> cases: Changing an attribute into an element is not so easy done.

I was not aware that this is about <element> or attribute. I thought the
question is more or less attributes only. However, our experience shows us
that often we learn much more when implementing the schemes. So we should
not do too much in advance.
Re: "stop post" / "platform edge" reference from ocpTT [message #867 is a reply to message #862] Fri, 09 November 2012 12:49 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 187
Registered: August 2008
Senior Member
Dear Andreas and all others,

> By the way, now that we are going to support delay infos, what about
> changes in tracks and platforms? Well, maybe an issue for 3.0 and a
> dedicated scheme for operation...

This is a much more general question: To take a train to a different track
in a station can be generalised to redirect a train not only in a station.
At least, the topic of 'actual' train information in contrary to
'timetable' information is much wider (redirecting trains, replacing
trains, replacing vehicles, wrong formation order, splitting trains...).
We cannot possibly provide alternative 'actual' attributes for each
'timetable' attribute.

We should provide a solution for 'actual' train information in general
later (earliest in 3.0). This should start with providing a solution to
specify a certain operating day out of the scheduled days as you already
have claimed in another tread. Until that, we should keep discussions on
'actual' information out of the 'timetable' scheme. In my opinion this
includes the delay information.

Best regards,
Dirk.
Re: "stop post" / "platform edge" reference from ocpTT [message #868 is a reply to message #866] Fri, 09 November 2012 15:09 Go to previous messageGo to next message
Susanne Wunsch is currently offline  Susanne Wunsch
Messages: 180
Registered: March 2008
Senior Member
Dear Dirk, Andreas and others,

Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>> That's why I would, with caution, pledge for being flexible here:
>> allow for an ocptt to refer to a platform without referring to a
>> track or stop post, as well as referring via the track.

+1 for flexibility

> Please note that currently there is no <platform> in RailML in the
> "Czech sense". We do have <platformEdges> but even _one_ "Czech"
> platform would have _two_ <platformEdges>. Theres is, as far as I
> see, currently no possibility to "to refer to a platform".

+1

But the 'platform edge' at least has a 'name' that could be the platform
name and should be duplicated in the Czech example for both platform
edges in a short-term solution.

>> There may be more than one stop post that refers to the same platform
>> edge. I thought the train part should refer to its appropriate stop
>> post if it exists otherwise to the platform edge.
>
> It is not common to do so in timetables because the operational rules
> clarify which stop post to take and would always have "higher
> priority" over any timetable information of that kind.
>
> However, I agree that this could be a "theoretic wish", pure
> informational: To get a part of the operational rules (which stop post
> to take) into RailML. If we deem it necessary, we should provide the
> "stopPostRef". Again, it would be a kind of redundant.

OK, I thought of some kind of simulating software. There is no driver to
stop at the appropriate position. It can be done with the now introduced
stopPost element.

>>> So why not "forcing" to use <ocpTT>.trackRef to come from a train to
>>> platformEdges and stopPosts?
>>
>> Sorry, I don't understand this suggestion.
>
> In my opinion, a platform and the stop posts always belong to the same
> station. The "belonging" (linkage) of platforms and stop posts to a
> station is an infrastructure information.

It may be defined by the
operationControlPoints/ocp/propEquipment/trackRef elements. An ocp
defines which tracks belong to itself.

But there are problems with _really long_ tracks through several
ocps. With the help of the
tracks/track/trackTopology/crossSections/crossSection/@ocpRe f one may
determine where the ocp is located along the "long track".

By traversing from ocp/../trackRef to the track one may detect several
stopPosts and platformEdges valid for multiple ocps that may be distinct
by their positions. But that's a really awful model.

Maybe we need the somewhat redundant reference from stopPost and
platformEdge to the ocp for the sake of "long tracks".

> So why repeating this infrastructure information at each train? Isn't
> it simpler to express is only one time in the infrastructure?

The timetable should only express references it has knowledge
about. That may be a certain track, a certain platform edge or a certain
stop post for the ocpTT.

* None of the three references have to be given.

* If a stop post is referred to, the track and platform edge references
are redundant and not needed but not forbidden.

* If a platform edge is referred to, the track reference is redundant
and not needed but not forbidden.

> <platformEdge> gets an "ocpRef".
>
> --> We then also have the references from the stop posts to its ocp's
> via the platformEdges, but there may be stop posts without platforms
> (freight-only tracks), so: providing references from a <stopPost> to
> an <ocp>: <stopPost> gets an "ocpRef".

Thanks for pointing this out. At least for the "long tracks" we probably
need these attributes. We should include Christian in this
discussion, he will probably not follow each timetable thread.

We quite forgot the 'serviceSection'! It is really simular to the
'platformEdge' element. But nevertheless we should provide the
appropriate reference attributes for this element, too.

Should stop posts also refer to service sections, such as
parking/fueling/cleaning/... areas? I don't think so, but have too less
experiences in this field.

> --> A <trainPart><ocpTT> already refers to an <ocp> and a
> <track>. With this information one can find the <platformEdges> and
> <stopPosts> through the infrastructure.

Not at all, there may be several stop posts and platform edges at a
certain track for a certain ocp. If the platform height varies there
have to be several platform edges for each height at the same track.

All these thoughts are only to find the best fitting model, I'm sure
that only rare software tools handle these detailed information.

>>> I don't think so. I would provide only one way and wait until somebody
>>> claims and explains why there is a need for another one which is not
>>> redundant.
>>
>> I would like to ask in advance because of the experiences in other
>> cases: Changing an attribute into an element is not so easy done.
>
> I was not aware that this is about <element> or attribute. I thought
> the question is more or less attributes only.

An attribute can only occur once per element. If we need multiple
information of the same type, we may allow lists in attribute (currently
only practiced for 'coordinates') or define repeatable elements (common
way in railML).

> However, our experience shows us that often we learn much more when
> implementing the schemes.

I'm really keen on your implementation experiences.

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
"Actual" train data (was: "stop post" / "platform edge" reference from ocpTT) [message #869 is a reply to message #867] Fri, 09 November 2012 15:20 Go to previous messageGo to next message
Susanne Wunsch is currently offline  Susanne Wunsch
Messages: 180
Registered: March 2008
Senior Member
Dear Dirk, Andreas and others,

Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>> By the way, now that we are going to support delay infos, what about
>> changes in tracks and platforms? Well, maybe an issue for 3.0 and a
>> dedicated scheme for operation...
>
> This is a much more general question: To take a train to a different
> track in a station can be generalised to redirect a train not only in
> a station. At least, the topic of 'actual' train information in
> contrary to 'timetable' information is much wider (redirecting
> trains, replacing trains, replacing vehicles, wrong formation order,
> splitting trains...). We cannot possibly provide alternative 'actual'
> attributes for each 'timetable' attribute.
>
> We should provide a solution for 'actual' train information in general
> later (earliest in 3.0). This should start with providing a solution
> to specify a certain operating day out of the scheduled days as you
> already have claimed in another tread. Until that, we should keep
> discussions on 'actual' information out of the 'timetable' scheme. In
> my opinion this includes the delay information.

Thank you, Dirk, for separating this part of discussion.

I filed a Trac ticket for this issue:

http://trac.assembla.com/railML/ticket/188

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: "stop post" / "platform edge" reference from ocpTT [message #883 is a reply to message #868] Mon, 12 November 2012 20:34 Go to previous messageGo to next message
Susanne Wunsch is currently offline  Susanne Wunsch
Messages: 180
Registered: March 2008
Senior Member
Susanne Wunsch <coord(at)commonrailmlorg> writes:
>> So why repeating this infrastructure information at each train? Isn't
>> it simpler to express is only one time in the infrastructure?
>
> The timetable should only express references it has knowledge
> about. That may be a certain track, a certain platform edge or a certain
> stop post for the ocpTT.
>
> * None of the three references have to be given.
>
> * If a stop post is referred to, the track and platform edge references
> are redundant and not needed but not forbidden.
>
> * If a platform edge is referred to, the track reference is redundant
> and not needed but not forbidden.

If filed a Trac ticket for this issue:

http://trac.assembla.com/railML/ticket/195

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: "stop post" / "platform edge" reference from ocpTT [message #892 is a reply to message #883] Tue, 20 November 2012 17:04 Go to previous messageGo to next message
Joachim Rubröder is currently offline  Joachim Rubröder
Messages: 88
Registered: April 2007
Member
Hello everybody,
the references from 'stopDescription' to 'stopPost', 'platformEdge' and
'serviceSection' are now available:

* 'serviceSectionRef' as referencing sub element (as decided at the railML
meeting in Zurich)
* 'platformEdgeRef' as referencing sub element (as decided at the railML
meeting in Zurich)
* 'stopPostRef', as referencing attribute

http://trac.assembla.com/railML/changeset/495
http://trac.assembla.com/railML/changeset/492
http://trac.assembla.com/railML/changeset/480

Please check if this level of detail is sufficient!

Kind regards,
Joachim

-------------------------------------
Joachim Rubröder
Schema Coordinator: railML.timetable

--
----== posted via PHP Headliner ==----
'trackInfo' deprecated? (was: "stop post" / "platform edge" reference from ocpTT) [message #904 is a reply to message #866] Wed, 28 November 2012 22:12 Go to previous messageGo to next message
Susanne Wunsch is currently offline  Susanne Wunsch
Messages: 180
Registered: March 2008
Senior Member
Dear all,

Dirk Bräuer <dirkbraeuer(at)irfpde> writes:

>> Now we /could/ say that for the sake of publication, the trackInfo
>> attribute is what you have to use. But this being purely textual, we
>> would loose reference to the infrastructure model.
>
> I agree: A non-plaintext possibility would be much better. But that
> would mean to further expand RailML in this direction in advance -
> before we have practical need. Since we cannot do everything at the
> same time, I think it's better to postpone this and wait.
>
> Let's remember that the current discussion was only about "trackInfo"
> to declare obsolete or not.

I filed a Trac ticket for this issue:

http://trac.assembla.com/railML/ticket/214

Any comments appreciated.

Kind regards...
Susanne
Re: 'trackInfo' deprecated? [message #905 is a reply to message #904] Thu, 29 November 2012 09:20 Go to previous messageGo to next message
Andreas Tanner is currently offline  Andreas Tanner
Messages: 51
Registered: March 2012
Member
The ticket suggests a "remarks" attribute. I'm not so convinced by that
since this is quite generic. The more specific an attribute is, the less
explanation is needed in the documentation.
We (IVU) currently use the trackInfo attribute to store a formatted
string that encodes platform and section. We use our private "decoding"
to map to our infrastructure model. Now the proper references to
infrastructure elements were added and of course, this is much better.
Still, possibly a formatted version of the track info could be useful as
a "commercial" attribute for printouts and displays in case that it
cannot be deduced from the infrastructure references.

Best regards
--Andreas.

Am 28.11.2012 22:12, schrieb Susanne Wunsch:
> Dear all,
>
> Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>
>>> Now we /could/ say that for the sake of publication, the trackInfo
>>> attribute is what you have to use. But this being purely textual, we
>>> would loose reference to the infrastructure model.
>>
>> I agree: A non-plaintext possibility would be much better. But that
>> would mean to further expand RailML in this direction in advance -
>> before we have practical need. Since we cannot do everything at the
>> same time, I think it's better to postpone this and wait.
>>
>> Let's remember that the current discussion was only about "trackInfo"
>> to declare obsolete or not.
>
> I filed a Trac ticket for this issue:
>
> http://trac.assembla.com/railML/ticket/214
>
> Any comments appreciated.
>
> Kind regards...
> Susanne
>
Re: 'trackInfo' deprecated? (was: "stop post" / "platform edge" reference from ocpTT) [message #906 is a reply to message #904] Thu, 29 November 2012 13:29 Go to previous messageGo to next message
Joachim Rubröder is currently offline  Joachim Rubröder
Messages: 88
Registered: April 2007
Member
Hello Susanne,

I agree that declaring the 'trackInfo' as deprecated in connection with
providing a more unspecific 'remarks' as substitute is leading the user in
the desired direction to use the specific infrastructure elements.

If there are no objections from other sides, I tend do implement it that
way.

Kind regards,
Joachim

-------------------------------------
Joachim Rubröder
Schema Coordinator: railML.timetable



--
----== posted via PHP Headliner ==----
Re: 'trackInfo' deprecated? [message #907 is a reply to message #905] Thu, 29 November 2012 13:44 Go to previous messageGo to next message
Joachim Rubröder is currently offline  Joachim Rubröder
Messages: 88
Registered: April 2007
Member
Hello Andreas,

Andreas Tanner wrote:
> We (IVU) currently use the trackInfo attribute to store a formatted
> string that encodes platform and section.

For encoding platforms and sections, the use of infrastructure references
is clearly recommanded.

> Still, possibly a formatted version of the track info could be useful as
> a "commercial" attribute for printouts and displays in case that it
> cannot be deduced from the infrastructure references.

This was exactly the original meaning of the attribute, to be used as
information for printouts. Like the 'published times', this commercial
track information may differ from the real infrastructure values.

This means you are pleading for keeping the 'trackInfo' for commercial
purposes? Maybe in a more formatted way like the internationalized
'messageText' of a 'connection'?

Kind regards,
Joachim

-------------------------------------
Joachim Rubröder
Schema Coordinator: railML.timetable



--
----== posted via PHP Headliner ==----
Re: 'trackInfo' deprecated? [message #908 is a reply to message #907] Thu, 29 November 2012 12:21 Go to previous messageGo to next message
Andreas Tanner is currently offline  Andreas Tanner
Messages: 51
Registered: March 2012
Member
Am 29.11.2012 13:44, schrieb Joachim Rubröder:

> This means you are pleading for keeping the 'trackInfo' for commercial
> purposes?

Yes, along with a clarifying text in the wiki, like
"Textual description of station track for information purposes."

Maybe in a more formatted way like the internationalized
> 'messageText' of a 'connection'?

Well, I cannot currently think of a need for an internationalized
platform description, but one never knows..

--Andreas.
Re: stop probability [message #956 is a reply to message #737] Mon, 02 December 2013 12:00 Go to previous message
Joachim Rubröder is currently offline  Joachim Rubröder
Messages: 88
Registered: April 2007
Member
Hi,
we created a ticket in order to plan this enhancement for a future railML
version: https://trac.assembla.com/railML/ticket/234

Kind regards,
Joachim

-------------------------------------
Joachim Rubröder
Schema Coordinator: railML.timetable

Susanne Wunsch wrote:
>
>
> Hi Joachim,
>
> coord(at)timetablerailmlorg (Joachim Rubröder) writes:
>
>> I would suggest to use an "anyAttribute" within the <stopDescription>.
>> This is the right place, because "stopOnRequest" is already there.
>>
>> If there is anyone else with the same request, we could prepare a new
>> field for a future version.
>
> Thanks for the quick response.
>
> It would be nice to define the anyAttribute in <stopDescription>. That's
> the best place for the needed attribute, I think.
>
> There are further attributes which could be defined in
> <stopDescription>:
>
> * (serviceSectionRef) if platforms, ramps or other facilities are
> defined as "serviceSection"s in IS [1]
>
> * (stopPosition) if serviceSectionRef is used and the train is shorter
> than the service section length
>
> Kind regards...
> Susanne
>
> [1] http://trac2.assembla.com/railML/ticket/122
>
>



--
----== posted via PHP Headliner ==----
Previous Topic: Blockparts: emptyRuns, depotRuns
Next Topic: RFE for connection, DE:Anschluss
Goto Forum:
  


Current Time: Thu Mar 30 04:43:53 CEST 2017