| infrastructure_V094_13 [message #48] |
Thu, 27 November 2003 15:30  |
Matthias Hengartner
Messages: 57
Registered: August 2003
|
Member |
|
|
Hello,
on http://www.theband.ch/matthias/railml/infrastructure_V094_13 .zip you can
find a new suggestion for the infrastructure-schema.
After a short meeting with Nikolaus Fries last friday, we agreed that
Nikolaus will make some considerations about signals and other "operation-
and controlsystem elements" (ocs) resp. "command and control system
elements", whereas I'll think about switches and connections.
In my scheme, there are some parts adopted from Nikolaus' thesis and from
the suggestions of Volker Knollmann.
Some suggestions from Volker are not yet included, because they concern
mostly the area of ocs. And there are more elements and attributes in
Nikolaus' scheme which could be adopted in a next draft.
Let's begin:
--- begin switches ---
A <switch> can be either a <junction> (Abzweigung) or a <crossover>
(direkter Gleiswechsel). A crossover refers to another crossover, while a
junction refers to a <connection> element.
For each track, there can be at maximum 2 connection elements. A connection
element is meant to be the begin or the end of another track. It refers
either to another connection element (to connect 2 tracks) or to a switch
element (which has to be a junction in this case).
Additionally, I added the attribute "branchFile" to the switch element to
give the possibility to refer another railML infrastructure file in which
the branch track (and its superior line) is stored.
If a switch is a crossover, there can be appended one or more
<clearTrackContrElements>, which can be <trackCircuitBorders> or
<axleCounters>. clearTrackContrElements can also appear as "normal" track
elements (in trackData). This idea is fully adopted from the scheme of
Nikolaus and covers parts of the suggestions from Volker Knollmann.
--- end switches ---
--- begin unique IDs ---
According to the suggestions of Joachim Büchse on sept 25 about unique IDs.
For a first approach, I've added an attribute named "uniqueId" to the
elements <infrastructure>, <line>, <track>, <ocp> and all the elements in
<trackData>. The "old" IDs (lineId, trackId etc.) are kept in the scheme,
because they are intended to correspond to "real-world"-IDs.
If we really introduce these uniqe IDs, it becomes unnecessary to provide
lineId, trackId and elemId to identify an track element uniquely. But we
could leave these attributes to accelerate search in the data structure.
--- end unique IDs ---
--- begin other ---
Finally, I reintroduced the attribute "ocpId" for the element
<crossSection>, which refers to a <ocp> and I adapted the visualisation part
of the scheme according to the changes descripted above.
--- end other ---
That's it for the moment...
Kind regards,
Matthias Hengartner
|
|
|
|
Members
Search
Help
Login
Home
