Home » railML newsgroups » railML.infrastructure » Haltetafel / stop post
| Re: Haltetafel / stop post [message #290 is a reply to message #289] |
Wed, 04 April 2012 10:45   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hello to all,
Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>>> 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.
Yes, that's a good position in the XML tree.
> 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.
Please do not repeat the elements' name in the attribute. 'Type' is
often used for 'datatype'. Let's find a more concise term. Which
enumeration should be offered behind this attribute?
> 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?
Yes, you may define the additional sign.
- train length
- axle count
- wagon count
- verbal definition (S-Bahn Berlin)
- ...
Does anybody know, whether only one of the above constraints may be
defined or also combinations of them occur?
>>> 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")?
Good to notice here. Let's discuss this topic in the neighbouring thread.
>> 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.
+1
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Current Time: Wed May 08 23:21:16 CEST 2024
|
Members
Search
Help
Login
Home
