Home » railML newsgroups » railML.infrastructure » simple Infrastructure scheme usage as a base for Timetable reference
Re: simple Infrastructure scheme usage as a base for Timetable reference [message #202 is a reply to message #201] Thu, 25 September 2008 00:10 Go to previous messageGo to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Hallo Volker,

Am 24.09.2008, 20:46 Uhr, schrieb Dr. Volker Knollmann <coord(at)infrastructurerailmlorg>:

> 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.

I diagree. I do not know what exactly you mean with "proper location information". All I have and all I need is mileage/kilometres of the trackside elements. It is possible to describe the kilometres of the line with only the kilometres of its elements and the "mileageChange" element.

> 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.

Please look at the graphic timetable header I sent: As you can see, there is no trace of a buffer stop at the start nor the end of the line. The graphic timetable starts at the first | in your ASCII art, NOT at any buffer stop before. So again: My problem is the T1, T3 T4, T6 sections because a graphic timetable consists only of T2 and T5. I want to start my track at | and end at | and do not want to have any buffer stops!

> 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).

I am aware of the difference between relative and absolute kilometres. I do not have any problem with kilometres of the line, changes of kilometres and I am able to use the element type "mileageChange".

> 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.

But I did never write that I want to have a "numberOfTracks"-attribute. Never. I do not want it!

What I did ask you is to make "trackBegin" and "trackEnd" optional. Please tell me "yes" or "no, because...".

> 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"?

This is not objective. Who said anything about a RailML line header???

Concerning my graphic example, in RailML would look like:

infrastructure
lines
line id=5102
tracks
track id=5102.0
trackTopology
crossSections
crossSection id=OR
crossSection id=ONPNU
crossSection id=OSTB
crossSection id=OTHA
crossSection id=OCB
crossSection id=OC
/crossSections
/trackTopology
/track
track id=5102.1
trackTopology
crossSections
crossSection id=OC
crossSection id=OCS
crossSection id=OESS
crossSection id=OWSK
/crossSections
/trackTopology
/track
track id=5102.2
trackTopology
crossSections
crossSection id=OC
crossSection id=OCS
crossSection id=OESS
crossSection id=OWSK
/crossSections
/trackTopology
/track
track id=5102.3
trackTopology
crossSections
crossSection id=OWSK
crossSection id=OMOLL
... a. s. o.

As you can see: The line 5102 has two tracks (=is double-track) between OC and OWSK. There is only one track between OR and OC. There are no trackBegin and trackEnd elements. The kilometres will be defined by the crossSections and by mileageChange elements.

I AGAIN REPEAT MY WISH: Please tell me whether my example of usage of infrastructure scheme will be possible (by making trackBegin / trackEnd optional) OR please make trackBegin / trackEnd usable in such a kind that it needs not to be a buffer stop nor a point nor a head-on junction. THANK YOU.

-------

> 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".

You can believe me that I am aware of the usage and limits of the current RailML timetable scheme. At some earlier meeting in Dresden I demonstrated some of the reasons why there are needs for a new timetable scheme. Joachim knows about this and is already working on this new scheme. My work should be only a support to him.

But here, we should discuss technical and technological problems.

> But please understand that we cannot decide about major changes on Friday without having had the chance to see them in advance.

??? I do not want to have major changes! What I want is simply to have trackBegin and trackEnd to be optional!
I was told that this forum is the right way to get such little improvements.

> 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)

??? I did sent you a message describig exactly that and I did send you a graphic timetable header. This is what I want to store!

I think that the time at our fairground stand at InnoTrans needs my presence and therefore I will not be present at the RailML meeting on Friday.. Let's see. Since the infrastructure of a graphic timetable (what I want to store in RailML) should be a very common thing and I want only two minor changes (optional elements) I wonder why it is necessary therefor to prepare a speech.

It seems that there are major misunderstandings and I think that a personal talk would be good. If you can find the time to visit our stand at InnoTrans on Thursday or Friday (hall 2.1 stand 220) it would be fine. If not, I try to come to the meeting at least for a short talk.

Thank you,
with best regards,
Dirk.
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Infrastructure, properties of OCPs
Next Topic: Derailer
Goto Forum:
  


Current Time: Sat May 18 20:24:29 CEST 2024