Home » railML newsgroups » railML.infrastructure » Haltetafel / stop post
| Re: Haltetafel / stop post [message #289 is a reply to message #288] |
Tue, 03 April 2012 21:07   |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hello Dirk,
> Dear Christian,
>
> sorry, but with
>
>> although any railML user didn't reply to your questions...
>
> I am a little bit annoyed because with my message form Monday March 26th
> where I indeed thought to reply to Susanne:
>
>> Additionally, I want to remember to Susanne's post from 2011-11-04
>> where she pleads for a stop markers (Haltetafeln) in RailML.
>
> I also wrote a suggestion to handle stop posts both from the view of
> infrastructure as well as from a train (timetable).
I am sorry, but my comment was not meant to ignore your post from March,
26. On the contrary, it was exactly your post that let me focus on
Susanne's post again, which has not been answered until then. So, sorry
again for causing any misunderstandings.
>> The stop post itself is a physical element, which is a sign right next
>> to the track. Therefore I would not use the crossSection element for
>> specifying stop posts.
>
> I agree with you. The crossSection is intended to specify a virtual
> place not marked by any physical sign.
>
>> Instead I would put the stop post element inside the ocsElements
>> container.
>
> I agree.
So I suggest defining a new ocsElement named <stopPost>. Like the other
ocsElements, it is an optional element and it will be placed in a
container <stopPosts>. Required attributes for a <stopPost> element are:
- "id"
- "pos"
Further attributes for describing the stop post may be optional:
- "serviceSectionRef" for referencing the service section, where the
stop post is situated.
- "stopPostType" for specifying the stop post element.
Connected with the last two attributes, the following two questions need
to be answered:
1. Does any stop post exist, which is not referenced to a service
section (or platform)?
2. Is it necessary to further specify a stop post element? If so, which
types are useful?
>> The even more difficult question is how the stop post can be
>> referenced with a certain platform (=serviceSection). Like with an
>> ocpRef, the sign post may directly refer to the ID of a serviceSection
>> via an attribute serviceSectionRef. What do you think?
>
> I also agree in general. But as written in the above mentioned post I
> would not create a <serviceSection> but a <platform> (splitting
> 'passenger service sections' and other service sections into different
> elements). But this is only a small detail which does not change the
> principle.
This idea sounds reasonable to me. However, what do other users think
about it (see also discussion in post "Platforms and ramps for railML 2.2")?
> From my side, it would also be ok to add the properties of a platform
> (orientation, length, height, a. s. o.) directly into the stop post
> element and in that way to eliminate the <serviceSection> or <platform>
> at all. But I understand that this is probably too much from the
> operational view. So defining a <serviceSection> or <platform> and
> referencing it from the stop post would be ok from my side.
Interesting idea, but I think that we should keep both elements
<stopPost> and <serviceSection> or <platform> since it provides us more
flexibility in extending this first approach to the platform problem.
Best regards
---
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Current Time: Thu May 09 02:16:22 CEST 2024
|
Members
Search
Help
Login
Home
