| Re: Introduction of speedChangeGroups required? [message #169 is a reply to message #167] |
Tue, 25 October 2005 16:53  |
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
|
|
|
|
Members
Search
Help
Login
Home
