| Re: infrastructure_V094_13 [message #49 is a reply to message #48] |
Thu, 27 November 2003 16:47   |
nfries
Messages: 6
Registered: November 2003
|
Junior Member |
|
|
Hello back,
thanks for your effort to integrate these elements!
> --- 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 ---
What did you mean by "otherID"? Is it meant to replace the attribute
"connSwitchID"?
> --- 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 ---
Here we will have to define how to use them. Keeping the old IDs implies
once again the danger of redundant information. Is the "uniqueID" meant to
become a required attribute later on?
> --- 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 ---
However, I can cope very well with this version.
Best regards,
Nikolaus
|
|
|
|
Members
Search
Help
Login
Home
