Hello Andreas,
> the trainProtection element offers a somewhat rough classification of
> train protection equipment for tracks. On the other hand, in the
> timetabling scheme we have the <equipmentUsage> of a trainPart where a
> predefined list is offered. I think this should be harmonized.
You are right, the trainProtection element within the infrastructure
scheme is still quite abstract and needs revision. Your idea is to add
the enumeration attribute
tNationalSystemsType
(ALSEN, ALSN, ASFA, ATB, ATBEG, ATBEN, ATC, ATSP, ATSS, AWS, BACC,
CIR-ELKE, CIR-ELKE2, Crocodile, CSS, DATC, EBICAB, EVM120, EVM160,
Fahrsp, GWATP, Indusi54, Indusi60, Indusi60R, Integra-Signum, KHP,
KLUBU, KVB, LS, LS90, LZB, Memor, Memor2, Mirel, PZ80, PZB90, RS4c,
SAUTC, SAUTCM, SAUTU, SCMT, SELCAB, SHP, SSC, TBL, TPWS, TVM300, TVM430,
ZSI127, ZSI90, ZSL90, ZST90, ZUB121, ZUB122, ZUB123, ZUB262)
that is being used within the timetable schema in the
trainProtectionElement object? Thus, the string attributes "system" and
"model" may become redundant. What do other users of the
trainProtectionElement think about this idea? Would you like to see the
strings substituted by the enumeration list?
Another idea of how to bring more structure inside the train detection
and protection topic was proposed in a ticket by Susanne [1]. Maybe it's
possible to combine these two ideas.
[1] http://trac.assembla.com/railML/ticket/23
---
Christian Rahmig
railML.infrastructure coordinator
|
Members
Search
Help
Login
Home
