| Re: simple Infrastructure scheme usage as a base for Timetable reference [message #201 is a reply to message #200] |
Wed, 24 September 2008 20:46   |
Dr. Volker Knollmann
Messages: 17
Registered: September 2008
|
Junior Member |
|
|
On 23/09/08 22:37, Dirk Bräuer wrote:
> Where is the real cross-section, i. e. the Lichtraumprofil of the
> track?
We once had an intensive discussion about how to store information about
a tracks clearance. This discussion happend during a RailML-meeting
approx. 2 years ago. We had a participant with really deep knowledge
about the different clearance variants for railway tracks and it was
obvious, that we cannot store all related data in two or three data
fields.
I personally don't know enough about that topic to make a sound
suggestion for appropriate data structures. I still hope for an expert
to had in his / her ideas about clearance profiles.
Besides that, the clearance is nothing physical you can touch. And this
was the original criteria for new elements to be added to infrastructure
file. But nevertheless I admit that the clearance is something strongly
related to the infrastructure and it definitely makes no sense to store
it elsewhere than in the infrastructure.
Perhaps we can re-animate that discussion along with the storage of
topographical information like clothoids etc. Susanne did some very good
preparational work for that!
> What I asked for was to get tracks w/o "trackBegin" / "trackEnd"
> elements. These tracks should not be empty at all! They should contain
> the crossSections-OCP-Refs you've shown me above and also nearly all
> trackElements (speeds, gradients, curves, gauge a.s.o.).
But the information inside <trackBegin> and <trackEnd> is vital for all
other elements you mentioned (speeds, gradients, curves, gauge a.s.o.).
Without begin / end, you cannot give proper location information for all
these elements.
> Of course these tracks have a virtual start (the mileage of the first
> crossSection-OCP-Ref) and a virtual end (the mileage of the last
> crossSection-OCP-Ref). But I cannot declare these places as the
> trackStart and trackElements in the meaning of the detailed
> infrastructure architecture where this means the real start/end
> (buffer stop or point) of the track.
Hmm... first of all, I don't like the idea of "virtual" starts and ends
of tracks. This would introduce new semantics to core RailML-elements
which would definitely confuse existing parsers.
But I think there is a solution to your problem, if I understood you
correctly. Time for some ASCII-art:
]-----T1---------|-------------------T2---------------|----- -T3-----[
xxxxxxx xxxxxxx
]-----T4---------|-------------------T5---------------|----- -T6-----[
"]--" denotes a buffer stop, "|" the joint between two <track>s and
"xxx" a platform.
If you compose your infrastructure like this, you gain tracks T2 / T5
with a relative coordinate of value "zero" in the middle of the
platform. All elements placed along these tracks are located relative to
this reference point (e. g. a signal at 1.234 km distance from the
platform center).
Using RailML this way is not exactly how it is intended (T1, T2 and T3
as a single <track>), but it is often used this way and all parses
should be able to handle it.
>> If there really is a common need to add an appropriate attribute for
>> the number of tracks we can insert it in a future RailML release.
> I want to ask you to do that if there is no existing possibility.
I'm afraid that - as usual - things aren't as easy as they seem to be.
In my opinion, a simple "numberOfTracks"-attribute for a <line> is NOT
the solution. Look at your own example in the JPG-file: you have
single- and double-line sections ON THE SAME LINE. So what to store in
the <line>-header? Double track? Single track? 1,5 tracks? "Mostly single
track"?
A better solution could be to store references to parallel <tracks>.
Imagine something like this:
<parallelTracks>
<parallelTrack ref1="T1" ref2="T4"/>
<parallelTrack ref1="T2" ref2="T5"/>
<parallelTrack ref1="T3" ref2="T6"/>
</parallelTracks>
.... with up to ref3 or ref6 or ref42 or whatever attributes. But this
brings in new semantic constraints which are difficult to handle: what
if two tracks marked as parallel do not have the same length? Do two
parallel tracks need to share the same start- / end-coordinates? What if
the two tracks do not have the same alignment? In the latter case, the
line may have double tracks but the routing (and therefore the
infrastructure data) can be completely different. Do you have any ideas
how to handle that?
> What I try to develop is a new generation of RailML timetable scheme.
Uuuhh... especially the timetable file format is heavily used and in my
opinion the most mature part of RailML. And if you talk about "a new
generation" this sounds to me more like a "revolution" and not like
"little enhancements". Without knowing what your ideas and changes are
about my first impression is that "a new generation" is no good signal
to the users of our file format. Especially if we think of the time
table part.
I'd like to strongly encourage you to get in touch with Joachim
Rubröder. He is the coordinator for the time table schema. Additionally,
please post details to your changes and ideas in the newsgroup.
> Parallel to this it would be good to have the extended infrastructure
> scheme where necessary. My expectation is to have them ready at the
> end of the year. May be you can talk and decide about it at Innotrans
> meeting on Friday.
Honestly, I really appreciate your efforts to improve RailML! And I'd
be happy to discuss your ideas together with all the other
participants on Friday. But please understand that we cannot decide
about major changes on Friday without having had the chance to see them
in advance.
If time isn't too short, please prepare a presentation for Friday in
which first of all explain
* WHAT you want to store / change (==> content)
and then, optionally,
* HOW you want to store it (data types, structure).
Please inform Vasco if you want to give a presentation on Friday so that
he can adapt the schedule.
I'm curious about your ideas and comments! See you on Friday!
Best regards,
Volker
--
Dr. Volker Knollmann
RailML Infrastructure Coordinator
Business contact:
Siemens AG
Industry Sector
I MO RA SPP SM MT 1
Ackerstr. 22
38126 Braunschweig
Tel.: +49 (531) 226-2592
mailto:volkerknollmann(at)siemenscom
|
|
|
|
Members
Search
Help
Login
Home
