Home » railML newsgroups » railML.infrastructure » Introduction of speedChangeGroups required?
Introduction of speedChangeGroups required? [message #161] Thu, 22 September 2005 11:20 Go to next message
Volker Knollmann is currently offline  Volker Knollmann
Messages: 32
Registered: October 2003
Member
(English version follows after the German text; when answering or
quoting choose the language you prefer)

Hallo railMLer,

auf dem letzten railML-Treffen (am 21.09.05 in Dresden) haben wir ein
paar alte und noch offene Punkte wieder aufgegriffen.

Eines davon sind die von Matthias Hengartner vor einiger Zeit
angesprochenen "SpeedChangeGroups" (siehe auch den alten Beitrag vom
15.03.05).

Es wurde vorgeschlagen, das Element <speedChange> in einen Container
umzuwandeln, der statt einer einzelnen Höchstgeschwindigkeit für
unterschiedliche Zuggattungen unterschiedliche Maximalgeschwindigkeiten
vorgibt:

<speedChangeGroup elemID="SC009" pos="12.039" absPos="46.132" dir="up">
<aSpeedChange vMax="90" trainCategory="R"/>
<aSpeedChange vMax="135" trainCategory="A"/>
<aSpeedChange vMax="160" trainCategory="D"/>
<aSpeedChange vMax="200" trainCategory="N"/>
</speedChangeGroup>


Meine Fragen an die Gruppe:

1) Soll das Feature "Zugartabhängige statische Geschwindigkeitsprofile"
in das Schema aufgenommen werden?

2) Wie bleiben wir zur Version 1.0 kompatibel? Soll das alte
<speedChange>-element weiterhin beibehalten werden?

3) Soll das Feature wie im Beispiel gezeigt implementiert werden, oder
gibt es Änderungswünsche oder Ergänzungen?

4) Wo wird die "trainCategory" definiert? Wäre die Verwendung einer
Referenz (via ID) auf einen entsprechenden Eintrag im
RollingStock-Schema sinnvoll (so es denn einen gibt)?


Bitte um zahlreiche Beiträge! Ich schlage vor, das Thema drei Wochen zur
Diskussion zu stellen. Danach sollte die Community zu einer Entscheidung
gekommen sein!


Gruß,
Volker Knollmann


-------------------------- ENGLISH VERSION --------------------------


Hello railML-fans and developers,

during the last railML-meeting (on 2005-09-21 in Dresden) some old but
so far open points came up.

One of these open points is the introduction of a element called
<speedChangeGroup>. Matthias Hengartner suggested this in his posting on
2005-05-13.

He proposed to convert <speedChange> into a container element that holds
a set of maximum speeds for various train types insted of a single
static speed for all kinds of trains. He suggested a implementation like
this:

<speedChangeGroup elemID="SC009" pos="12.039" absPos="46.132" dir="up">
<aSpeedChange vMax="90" trainCategory="R"/>
<aSpeedChange vMax="135" trainCategory="A"/>
<aSpeedChange vMax="160" trainCategory="D"/>
<aSpeedChange vMax="200" trainCategory="N"/>
</speedChangeGroup>

What I want you to think about is:

1) Should the feature "train-type dependant static speed profile" be
introduced to the schema?

2) How to keep comptability with the version 1.0? Should the old
<speedChange>-element be kept untouched?

3) Should the feature be implemented as shown above or are there
remarks, comments, extensions?

4) Where is the "trainCategory" to be defined? Does it make sense to
reference (via ID) to a definition in the rollingStock-scheme, for
example? Does a suitable entry or branch exist in RS?


I hope for many postings! I think, we should keep the discussion up for
three weeks. After that time, the community should have made a decision!

Best regards,
Volker Knollmann

--
German Aerospace Center (DLR)
Institute of Transportation Systems
Lilienthalplatz 7
38108 Braunschweig, Germany

Dipl.-Ing. Volker Knollmann
Telephone: +49 531 295-3461
Telefax : +49 531 295-3402
Internet: http://www.dlr.de/fs

Please use encryption and electronic signatures for secure data
exchange. You can download my public key here:
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xEE4 EB9525CDB6396
Re: Introduction of speedChangeGroups required? [message #164 is a reply to message #161] Mon, 10 October 2005 11:29 Go to previous messageGo to next message
Matthias Hengartner is currently offline  Matthias Hengartner
Messages: 57
Registered: August 2003
Member
Hello,

> 2) How to keep comptability with the version 1.0? Should the old
> <speedChange>-element be kept untouched?

My original idea was to leave the original <speedChange>-element and add the
<speedChangeGroup>-element as an additional possibility (similar to
signal/balise groups).


>
> <speedChangeGroup elemID="SC009" pos="12.039" absPos="46.132" dir="up">
> <aSpeedChange vMax="90" trainCategory="R"/>
> <aSpeedChange vMax="135" trainCategory="A"/>
> <aSpeedChange vMax="160" trainCategory="D"/>
> <aSpeedChange vMax="200" trainCategory="N"/>
> </speedChangeGroup>
>
> 3) Should the feature be implemented as shown above or are there
> remarks, comments, extensions?

--> Where should we place the attribute "dir"? As an attribute of
<speedChangeGroup> (as above) or as an attribute of the single
<aSpeedChange>-elements?
--> Is there any idea for a better name for <aSpeedChange>?



Best regards,
Matthias Hengartner

--
****************************
Matthias Hengartner
IVT ETH Zürich
hengartner(at)ivtbaugethzch
++ 41 44 633 68 16
****************************
Re: Introduction of speedChangeGroups required? [message #165 is a reply to message #164] Thu, 13 October 2005 13:49 Go to previous messageGo to next message
Volker Knollmann is currently offline  Volker Knollmann
Messages: 32
Registered: October 2003
Member
On 10.10.2005 11:29, Matthias Hengartner wrote:
>> 2) How to keep comptability with the version 1.0? Should the old
>> <speedChange>-element be kept untouched?
>

> My original idea was to leave the original <speedChange>-element and add the
> <speedChangeGroup>-element as an additional possibility (similar to
> signal/balise groups).

Hmmm... two different elements for almost the same purpose?

> --> Where should we place the attribute "dir"? As an attribute of
> <speedChangeGroup> (as above) or as an attribute of the single
> <aSpeedChange>-elements?

That points me to a slightly more general question. Image the following
static speed profile for a train of an arbitrary train category:



^ v
|
|
| 80 km/h
+---------------------+
| |
| |
| | 40 km/h
| +----------------
|
|
|
+---------------------|-------------------------> s
s0

---> "up"-direction



Which railML-elements would you introduce at position s0?

A speed change to 40 km/h valid in up-direction?
Plus a speed change to 80 km/h in down-direction?

A speed change to 40 km/h with implicit assumption of a speed change to
80 km/h in opposite direction? (Attention: speed changes are often not
"symmetrically"!)

An extended <speedChange>-element with two v-attributes: vMaxUp,
vMaxDown? This would be incompatible to V1.0, btw!

Anything else?


The more I think about this example, the more I guess we need not only a
clear definition and documentation of the SYNTAX, but also of the
SEMANTICS...

What do you think?


Remember: Answers to this posting in German are as welcome as answers in
English! Don't hesitate to tell us your opinion!


Best regards,
Volker Knollmann
Re: Introduction of speedChangeGroups required? [message #166 is a reply to message #165] Fri, 14 October 2005 16:33 Go to previous messageGo to next message
Matthias Hengartner is currently offline  Matthias Hengartner
Messages: 57
Registered: August 2003
Member
Hello,


>> My original idea was to leave the original <speedChange>-element and add
the
>> <speedChangeGroup>-element as an additional possibility (similar to
>> signal/balise groups).
>
> Hmmm... two different elements for almost the same purpose?

So it would be compatible to V1.0. And the case where vMax of only one train
category changes could be modelled a bit simplier... But I agree, it's not
urgently necessary to have both elements.



> That points me to a slightly more general question. Image the following
> static speed profile for a train of an arbitrary train category:
>
>
>
> ^ v
> |
> |
> | 80 km/h
> +---------------------+
> | |
> | |
> | | 40 km/h
> | +----------------
> |
> |
> |
> +---------------------|-------------------------> s
> s0
>
> ---> "up"-direction
>
>
>
> Which railML-elements would you introduce at position s0?
>
> A speed change to 40 km/h valid in up-direction?
> Plus a speed change to 80 km/h in down-direction?
>
> A speed change to 40 km/h with implicit assumption of a speed change to
> 80 km/h in opposite direction? (Attention: speed changes are often not
> "symmetrically"!)
>
> An extended <speedChange>-element with two v-attributes: vMaxUp,
> vMaxDown? This would be incompatible to V1.0, btw!
>
> Anything else?


[[Sorry, no time at the moment to answer this question in English...]]

<german>
Ja daran habe ich auch schon rumstudiert...
Die Frage ist, ob sich das "dir"-Attribut auf die Richtung der Gültigkeit
der Geschwindigkeit relativ zur Gleisrichtung (A) oder auf die
Fahrtrichtung, in welche die Geschwindigkeit gilt, (B) bezieht - oder
beides. Veranschaulicht erklärt:

Eine Strecke mit zwei Abschnitten mit pro Richtung verschiedenen vMax (am
Besten mit einer Courier-ähnlichen Schriftart zu betrachten):

80 --> 70 -->
<-- 60 <-- 50
|-------------|--------------| -->
s0 s1 s2


Also nach meiner bisherigen Auffassung hätte ich dies folgendermassen
modelliert [1]:
s0: <speedChange vMax="80" dir="up">
s1: <speedChange vMax="70" dir="up">
s1: <speedChange vMax="60" dir="down">
s2: <speedChange vMax="50" dir="down">

Hier bezieht sich also das dir-Attribut sowohl auf die Gültigkeit (A) wie
auch die Fahrtrichtung (B).


Andere Möglichkeit [2]:
s0: <speedChange vMax="80" dir="up">
s0: <speedChange vMax="60" dir="down">
s1: <speedChange vMax="70" dir="up">
s1: <speedChange vMax="50" dir="down">

Hier bezieht sich das dir-Attribut auf die Fahrtrichtung (B). Die Gültigkeit
ist hier implizit bestimmt durch die Gleisrichtung (also immer aufwärts).


Version [1] ist meiner Meinung nach etwas "sauberer" (da das dir-Attribut
hier gleich gebraucht wird wie bei anderen xxChange-Elementen [***]).
Version [2] ist bringt wohl bei der Implementierung von
Import/Export-Filtern einige Vorteile.


[***] Wobei <speedChange> soweit mir jetzt gerade bewusst ist das einzige
xxChange-Element ist, das asymetrisch sein kann!

</german>



> The more I think about this example, the more I guess we need not only a
> clear definition and documentation of the SYNTAX, but also of the
> SEMANTICS...

I fully agree with you in this point, totally, extremely, without any
restrictions, ... :-)



I hope, there are not more questions than before?!


Have a nice weekend everybody,
Matthias

--
****************************
Matthias Hengartner
IVT ETH Zürich
hengartner(at)ivtbaugethzch
++ 41 44 633 68 16
****************************
Re: Introduction of speedChangeGroups required? [message #167 is a reply to message #166] Wed, 19 October 2005 11:34 Go to previous messageGo to next message
Volker Knollmann is currently offline  Volker Knollmann
Messages: 32
Registered: October 2003
Member
On 14.10.2005 16:33, Matthias Hengartner wrote:
>> Hmmm... two different elements for almost the same purpose?
>
> So it would be compatible to V1.0. And the case where vMax of only one train
> category changes could be modelled a bit simplier... But I agree, it's not
> urgently necessary to have both elements.

What if we add an additional attribute like "trainGroups", which is
optional. Without this attribute, the speed change is valid for all
trains and otherwise for the mentioned group only.

Advantage: Compatible with V 1.0 and only one element for one purpose
Disadvantage: Multiple elements needed for multiple train groups.


Example 1 (Speed change for all trains):

<speedChange vMax="42.0" dir="up" pos="1.234" elemID="9876">


Example 2 (Speed change for two groups only):

<speedChange vMax="42.0" dir="up" pos="1.234" trainCategory="R"
elemID="9876">
<speedChange vMax="42.0" dir="up" pos="1.234" trainCategory="A"
elemID="9877">


As you can see from example 2, there is lots of redundant information
and additional IDs.

> Eine Strecke mit zwei Abschnitten mit pro Richtung verschiedenen vMax (am
> Besten mit einer Courier-ähnlichen Schriftart zu betrachten):
>
> 80 --> 70 -->
> <-- 60 <-- 50
> |-------------|--------------| -->
> s0 s1 s2
>
>
> Also nach meiner bisherigen Auffassung hätte ich dies folgendermassen
> modelliert [1]:
> s0: <speedChange vMax="80" dir="up">
> s1: <speedChange vMax="70" dir="up">
> s1: <speedChange vMax="60" dir="down">
> s2: <speedChange vMax="50" dir="down">
>
> Hier bezieht sich also das dir-Attribut sowohl auf die Gültigkeit (A) wie
> auch die Fahrtrichtung (B).
>
>
> Andere Möglichkeit [2]:
> s0: <speedChange vMax="80" dir="up">
> s0: <speedChange vMax="60" dir="down">
> s1: <speedChange vMax="70" dir="up">
> s1: <speedChange vMax="50" dir="down">
>
> Hier bezieht sich das dir-Attribut auf die Fahrtrichtung (B). Die Gültigkeit
> ist hier implizit bestimmt durch die Gleisrichtung (also immer aufwärts).

Sehen wir das ganze mal aus Sicht einer Simulation. Da muß man am
zweckmäßigsten den Geschwindigkeitswechsel an der Stelle speichern, ab
der er wirksam wird. Ansonsten müßte man immer "vorausschauen", und das
ist unschön.

Nehmen wir also an, wir fahren von s2 über s1 nach s0. Dann muß ich an
Stelle s2 erfahren, dass ab hier 50 km/h vorgegeben sind. So als würde
dort ein "echtes" Schild stehen. Das ist in [1] der Fall.

Bei [2] müßte ich bis s1 vorausschauen um die Begrenzung zu bekommen,
die de facto ab s2 gilt. *brrrr* ;-)

Ich würde mich daher eher für [1] aussprechen.

> Version [1] ist meiner Meinung nach etwas "sauberer" (da das dir-Attribut
> hier gleich gebraucht wird wie bei anderen xxChange-Elementen [***]).

Ack.

> Version [2] ist bringt wohl bei der Implementierung von
> Import/Export-Filtern einige Vorteile.

Äääähem... wirklich? ;-)


>> The more I think about this example, the more I guess we need not only a
>> clear definition and documentation of the SYNTAX, but also of the
>> SEMANTICS...
>
>
> I fully agree with you in this point, totally, extremely, without any
> restrictions, ... :-)

Okay, I'll set up a new posting for this in order not to mix the topics.

Best regards,
Volker Knollmann

--
German Aerospace Center (DLR)
Institute of Transportation Systems
Lilienthalplatz 7
38108 Braunschweig, Germany

Dipl.-Ing. Volker Knollmann
Telephone: +49 531 295-3461
Telefax : +49 531 295-3402
Internet: http://www.dlr.de/fs

Please use encryption and electronic signatures for secure data
exchange. You can download my public key here:
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xEE4 EB9525CDB6396
Re: Introduction of speedChangeGroups required? [message #169 is a reply to message #167] Tue, 25 October 2005 16:53 Go to previous message
Matthias Hengartner is currently offline  Matthias Hengartner
Messages: 57
Registered: August 2003
Member
Hi again,


> What if we add an additional attribute like "trainGroups", which is
> optional. Without this attribute, the speed change is valid for all
> trains and otherwise for the mentioned group only.
>
> Advantage: Compatible with V 1.0 and only one element for one purpose
> Disadvantage: Multiple elements needed for multiple train groups.
>
>
> Example 1 (Speed change for all trains):
>
> <speedChange vMax="42.0" dir="up" pos="1.234" elemID="9876">
>
>
> Example 2 (Speed change for two groups only):
>
> <speedChange vMax="42.0" dir="up" pos="1.234" trainCategory="R"
> elemID="9876">
> <speedChange vMax="42.0" dir="up" pos="1.234" trainCategory="A"
> elemID="9877">
>
>
> As you can see from example 2, there is lots of redundant information
> and additional IDs.

This would help us only in the case where ALL train groups change to the
SAME speed. But I'm convinced that it'd be more helpful when we have a point
on the track (same ID + positioning data), where we could define SEVERAL
speeds for SEVERAL train groups.

It's ok with me if we agree, that a <speedChange>-element WITHOUT a
trainCategory is valid for ALL train categories - but it doesn't substitute
the suggested <speedChangeGroups> in my opinion.



>
>> Eine Strecke mit zwei Abschnitten mit pro Richtung verschiedenen vMax
(am
>> Besten mit einer Courier-ähnlichen Schriftart zu betrachten):
>>
>> 80 --> 70 -->
>> <-- 60 <-- 50
>> |-------------|--------------| -->
>> s0 s1 s2
>>
>>
>> Also nach meiner bisherigen Auffassung hätte ich dies folgendermassen
>> modelliert [1]:
>> s0: <speedChange vMax="80" dir="up">
>> s1: <speedChange vMax="70" dir="up">
>> s1: <speedChange vMax="60" dir="down">
>> s2: <speedChange vMax="50" dir="down">
>>
>> Hier bezieht sich also das dir-Attribut sowohl auf die Gültigkeit (A)
wie
>> auch die Fahrtrichtung (B).
>>
>>
>> Andere Möglichkeit [2]:
>> s0: <speedChange vMax="80" dir="up">
>> s0: <speedChange vMax="60" dir="down">
>> s1: <speedChange vMax="70" dir="up">
>> s1: <speedChange vMax="50" dir="down">
>>
>> Hier bezieht sich das dir-Attribut auf die Fahrtrichtung (B). Die
Gültigkeit
>> ist hier implizit bestimmt durch die Gleisrichtung (also immer
aufwärts).
>
> Sehen wir das ganze mal aus Sicht einer Simulation. Da muß man am
> zweckmäßigsten den Geschwindigkeitswechsel an der Stelle speichern, ab
> der er wirksam wird. Ansonsten müßte man immer "vorausschauen", und das
> ist unschön.
>
> Nehmen wir also an, wir fahren von s2 über s1 nach s0. Dann muß ich an
> Stelle s2 erfahren, dass ab hier 50 km/h vorgegeben sind. So als würde
> dort ein "echtes" Schild stehen. Das ist in [1] der Fall.
>
> Bei [2] müßte ich bis s1 vorausschauen um die Begrenzung zu bekommen,
> die de facto ab s2 gilt. *brrrr* ;-)

Hmnaja, kommt ein bisschen draufan... Wenn eine Applikation direkt auf der
railML-Datenstruktur arbeitet, geb ich Dir recht. Wenn jedoch railML-Daten
importiert (und in eine andere Datenstruktur transformiert) werden, dann
kann [2] durchaus von Vorteil sein (ich spreche aus eigener Erfahrung...)
Kommt aber natürlich auf das importierende Programm bzw. dessen
Datenstruktur an.
--> Gebe Dir somit (insgesamt gesehen) recht, [1] ist "schöner" und
sozusagen realitätsbezogener.

Viele Grüsse / Best regards
Matthias Hengartner
Previous Topic: [IL] Contents and structure of interlocking schema
Next Topic: [IL] Ideas about interlocking schema
Goto Forum:
  


Current Time: Fri Mar 29 01:06:19 CET 2024