| Re: Re-factoring of <infraAttributes> [message #1946 is a reply to message #1844] |
Mon, 03 September 2018 17:49  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Christian,
here are some short remarks on your enumeration from our side. I have no general objections nor problems. Items of your list which I did not mention here, I agree with your suggestion or we do not use and not need it.
> The attribute @clearanceManaging lists the following values: "sight", "time", "blocking", "LZB-blocking" and "absBrakeDist". If needed at all, I suggest to mark at least "LZB-blocking" as DEPRECATED. Any comments?
We have an attribute like this in our software but we do currently not use it in railML. We use that attribute to control the "spacing" of trains in our timetable construction: When can one train follow the previous one? Is the distance (in time or space) between two trains ok or is it a conflict? How much time buffer is in the timetable?
- For tramways, we use "spacing by sight": They can follow each other in any possible distance up to the (absolute) braking distance but they cannot overtake each other while driving at the same line.
- For streets/buses (yes, sometimes there are even graphic timetables for "street traffic", connected with replacement buses), we use "no spacing": They can follow each other in any possible distance and even overtake each other while driving at the same line.
- For normal railway operation, we use "spacing by room/block": The blocking sections of a line decide about the spacing of trains.
- We do not support "spacing by time" since, afaik, there is no such railway line any-more.
"Spacing by sight" is functionally the same as "spacing in absolute braking distance". The difference is only who calculates the braking distance (the driver in his mind or any technology). We do not support "spacing in relative braking distance" despite this happens sometimes at our streets... ;-)
Concerning "spacing by room/block", we do not need to distinguish the kind of block (Main signals, "LZB-blocking", ETCS or such) here because this depends on the actual infrastructure alongside the certain tracks.
Conclusion: For railML, I would still see "spacing by sight" and "spacing by room/block" at least because there are such railways. It would be nice to have a representation for street traffic (buses) in case someone needs to encode this for timetables of replacement buses. Or may be railML wants to allow even regular buses?
---
> <infraAttributes><trainProtection>
> Currently, the train protection system is characterized by the attributes @monitoring (enumeration value list: "none", "intermittent", "continuous") and @medium (enumeration value list: "mechanical", "electric", "inductive", ...). How about adding an attribute @trainProtectionSystem (string) to reference the matching train protection system from codelist TrainProtectionSystems.xml. This is already possible for the single <trainProtectionElement>.
This would be redundant since any actual train protection system (model) fits into one of monitoring and medium types. I guess there is no need to describe the generalised kind of train protection. So since we have a list of certain models, to reduce redundancy and effort, I would recommend to declare @monitoring and @medium as deprecated and/or skip them in railML 3.x.
---
> <infraAttributes><powerTransmission>
> The attribute @type is used to distinguish between conventional railways and rack railways (de: Zahnradbahn) or others. The usage of the other attribute @style (string) is completely unclear.
I guess the type shall describe the rack type in case it is a rack railway (like 'Strub', 'Riggenbach', 'Abt 3 Lamellen', Abt 2 Lamellen' etc.). So the question is: Attributes like gauge, electrification and rack type help to allow only fitting vehicles to fitting tracks. If somebody sends me a <railML>.<infrastructure> file with a railway line of 1000 mm gauge, I want to prevent myself from creating timetables with 1435 mm vehicles on it. Do I want to prevent myself from calculating an 'Abt' rack engine at a 'Riggenbach' rack railway? I am not sure but I tend to answer: Yes, for the sake of consequence.
-> Can we offer an enumeration list of rack types here instead of the string attribute? (There is only a small number of!)
-> By the way: Do we have the same types of racks at <rollingStock>.<vehicles>?
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
