Home » railML newsgroups » railML.infrastructure » Schema version V0.95-02 released
| Schema version V0.95-02 released [message #93] |
Tue, 07 September 2004 21:27  |
Ulrich Linder
Messages: 28
Registered: July 2003
|
Junior Member |
|
|
Hello,
a new version of the infrastructure schema is released:
http://www.railml.org/genesis/infrastructure
We have a lot of changes compared to the former version 0.94-18. Most of the
proposals in the newsgroup are implemented in this version.
This are the most important changes:
1. General:
- Absolute positions are split in two decimal parts instead of the combined
string-attribute. --> absPosAttrGroup
- The internal inheritance of some schema type definitions have been changed
using attribute groups. This has no effect to the syntax of the
infrastucture files.
2. Tracks:
- Each trach has a new attribute "trackType". The attributes
"posTrackBegin", "posTrackEnd", "absPosTrackBegin", "absPosTrackEnd" and
"length" are canceled. Use the trackTopology child "trackBegin" and
"trackEnd" for this information.
- The child "trackData" is renamed to "trackElements" (and "trackDataType"
to "trackElementType"
- "trackElements" have a new child called "generalElements" containing
multiple elements of the Type "generalElementType". This elements can be
used to store arbitrary track elements.
3. Topology:
- Crossings are supported
- The track begin and the track end can be defined as simple connection,
buffer stop, switch or crossing.
- Connections refer opposite to another connection by the ID
- Each connection can contain a bend (radius) and a maximum speed.
- The connection reference is defined by an connection ID and/or by
references to the topology, the line, track, position and the absolute
postion.
4. Track elements of the operation and control system:
- First proposal for the integration of balises, axle counters, track
circuits and train protection elements.
- "trackType" gets a new child "ocsElements" as container for operation and
control elements of the track. This container is used for blocks, signals,
balises, axle counters, track circuits and train protection elements.
Signals and balises can be grouped.
PLEASE have a look on this proposals, especially on the operation and
control elements and the topology (i.e. crossings).
We plan to release the version 1.0 before the next meeting in Berlin!
The concept document will be revised and published the next days.
With best regards
Ulrich Linder
------------------------------
Dr.-Ing. Ulrich Linder
Linder Rail Consult
Mörchinger Str. 25
D-14169 Berlin
Tel. +49.30.84 72 56 87
Fax. +49.30.84 47 11 56
Email mailto:UlrichLinder(at)linder-rail-consultde
www http://www.Linder-rail-consult.de
|
|
|
|
| Re: Schema version V0.95-02 released [message #94 is a reply to message #93] |
Thu, 09 September 2004 19:52  |
Joachim.Rubröder
Messages: 33
Registered: September 2004
|
Member |
|
|
Crossings:
The introduction of crossings is quiet well and I'm glad they can be
placed at the beginning of a track like switches.
There is one problem with the type:
in the annotations are several types allowed:
simpleCrossing, simpleSwitchCrossingLeft, simpleSwitchCrossingRight,
doubleSwitchCrossingLeft, doubleSwitchCrossingRight
But in the schema there are only three types to be defined:
simpleCrossing, simpleSwitchCrossing, doubleSwitchCrossing
I think the first ones are correct, because we need more information about
the switch inside the simpleSwitchCrossing.
To define it this way works, but with the disadvantage of having a
simpleSwitchCrossingLeft while running on one track and having the same
crossing as simpleSwitchCrossingRight if you are on the other track.
With best regards,
Joachim Rubröder
|
|
|
|
| Re: Schema version V0.95-02 released [message #95 is a reply to message #93] |
Wed, 15 September 2004 20:47 |
Matthias Hengartner
Messages: 57
Registered: August 2003
|
Member |
|
|
Hello,
I'm very glad about the new schema with all the changes and new elements and
hope there is only a small step to version 1.0!
My (and Dani Hürlimanns) comments & questions:
- the attribute "type" (of <track>) should not be required (because some
exporting programms may not know what type a track is)
- could we have something like <generalElement> also in the <infraAttrGroup>
? ("<generalInfraAttribue>" or similar)
- I'm also glad about the possibility to place a switch (and also a
crossing) on a <trackBegin> / <trackEnd>. But I'd prefer to have only a
reference to a switch/crossing which is located in the
<connections>-container.
- It's also a good thing that we have the absolute position separated in 2
parts. But I'm a little bit confused about the format of these to
attributes. Both are decimals with 12 digits, 5 of them after decimal point.
What unit is "absPosOffset" meant to be? In the former versions of the
schema, the 2 patterns for "absPos" were
1. km: {dddd}d.d{dddd}
2. km + m: {dddd}d.d + {ddd}dd{.dd}
If these are close to reality (I guess they are), my suggestion is: 10/5
digits for "absPos" (km) and 7/2 for "absPosOffset" (m)
- <mileageChange>: I'm confused about the use of absPos, absPosOffset,
absPosIn and absPosInOffset, especially after having studied the two
mileageChanges in the demoNet-file. Perhaps it would be clearer if we had
"absPosOut" instead of "absPosIn".
- We have a new element type <trainProtectionElement> in the
<ocsElements>-container, but we have also the ("old")
<trainProtectionChange> in <trackElements>. Intention or mistake?
If it's intention, what is the difference between <trainProtectionElement>
and <trainProtectionChange>?
If it's a mistake, why is the attribute "monitoring" not included anymore?
- The new <crossing>-element has an attribute "dir". What is the use of
this, since we have already the "branchDir"-attribute in the connection?
- I've noticed, that longitude, latitude and altitude are now implemented as
attributes instead of child-elements of <geoCoords>. I'm fine with that.
- and finally, 2 little misprints:
<axleCounter>/posInTrack --> outsideRIght
annotation of "absPosAttrGroup" ("handlicng")
See you next week in Berlin!
Regards,
Matthias Hengartner
|
|
|
|
|
|
| Re: Schema version V0.95-02 released [message #97 is a reply to message #95] |
Wed, 22 September 2004 10:24 |
Ulrich Linder
Messages: 28
Registered: July 2003
|
Junior Member |
|
|
Hello,
"Matthias Hengartner" <hengartner(at)ivtbaugethzch> schrieb im Newsbeitrag
news:cia2it$mjt$1(at)sifaivifhgde...
> ...
> - the attribute "type" (of <track>) should not be required (because some
> exporting programms may not know what type a track is)
ok, is done in the current release.
> - could we have something like <generalElement> also in the
> <infraAttrGroup>
> ? ("<generalInfraAttribue>" or similar)
ok, is done in the current release.
> - I'm also glad about the possibility to place a switch (and also a
> crossing) on a <trackBegin> / <trackEnd>. But I'd prefer to have only a
> reference to a switch/crossing which is located in the
> <connections>-container.
Let's discuss on Thursday.
> - It's also a good thing that we have the absolute position separated in 2
> parts. But I'm a little bit confused about the format of these to
> attributes. Both are decimals with 12 digits, 5 of them after decimal
> point.
> What unit is "absPosOffset" meant to be? In the former versions of the
> schema, the 2 patterns for "absPos" were
> 1. km: {dddd}d.d{dddd}
> 2. km + m: {dddd}d.d + {ddd}dd{.dd}
> If these are close to reality (I guess they are), my suggestion is: 10/5
> digits for "absPos" (km) and 7/2 for "absPosOffset" (m)
"absPos" and "absPosOffset" have now the unit "km" to standardize the units
(see annotations). In the current release I've changed the cont of digits to
10/5. I've not notiived that the decimal point and the sign are not included
in the total count.
> - <mileageChange>: I'm confused about the use of absPos, absPosOffset,
> absPosIn and absPosInOffset, especially after having studied the two
> mileageChanges in the demoNet-file. Perhaps it would be clearer if we had
> "absPosOut" instead of "absPosIn".
The (german) understanding of the position of a mileage change is to assign
the mileage change to the outgoing mileage. Therefore "absPos" and
"absPosOffset" contain the outgoing mileage and "absPosIn" and
"absPosInOffset" contain the incoming mileage. If the international
understanding is different, we should change this soon. Let's discuss on
Thursday.
> - We have a new element type <trainProtectionElement> in the
> <ocsElements>-container, but we have also the ("old")
> <trainProtectionChange> in <trackElements>. Intention or mistake?
> If it's intention, what is the difference between <trainProtectionElement>
> and <trainProtectionChange>?
> If it's a mistake, why is the attribute "monitoring" not included anymore?
The "trainProtectionChange" contains a general information about the train
protection system whereas a "trainProtectionElement" contains a single
element (i.e. INDUSI, "Gleissperre"). Therefore a train protection element
has no information about the type of monitoring.
See also discussion thread from Volker Knollmann 2003-11-19.
> - The new <crossing>-element has an attribute "dir". What is the use of
> this, since we have already the "branchDir"-attribute in the connection?
ok, is done in the current release.
> - I've noticed, that longitude, latitude and altitude are now implemented
> as
> attributes instead of child-elements of <geoCoords>. I'm fine with that.
ok, was done some month before ;-)
> - and finally, 2 little misprints:
> <axleCounter>/posInTrack --> outsideRIght
> annotation of "absPosAttrGroup" ("handlicng")
ok, is done in the current release.
> See you next week in Berlin!
See you tomorrow in Berlin!
With best regards
------------------------------
Dr.-Ing. Ulrich Linder
Linder Rail Consult
Mörchinger Str. 25
D-14169 Berlin
Tel. +49.30.84 72 56 87
Fax. +49.30.84 47 11 56
Email mailto:UlrichLinder(at)linder-rail-consultde
www http://www.Linder-rail-consult.de
|
|
|
|
Goto Forum:
Current Time: Tue Apr 23 22:18:55 CEST 2024
|
Members
Search
Help
Login
Home
