| Re: extension of <levelCrossing> in railML2.4nor [message #2179 is a reply to message #2170] |
Tue, 16 April 2019 20:25   |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear Janne,
Am 10.04.2019 um 11:23 schrieb Janne Möller:
> [...] the element <levelCrossing> has been extended for norwegian
> usage. In this forum post I would like to describe the
> changes that were made like announced in: [1]
> The following adjustments have been made [...]
Thank you for your input w.r.t. <levelCrossing> element. I will comment
on the different proposals one by one:
> The attributes @pos and @absPos for <levelCrossing> are
> defined in the following way:
> @pos: This attribute is used to store the measured centre
> position of the level crossing along the track. This does
> not necessarily have to be the actual middle between the
> road borders.
> @absPos: This attribute is used to store the original
> position of the level crossing that is provided in Banedata
> (database on norwegian railway network).
The @pos attribute stores a measurable distance of an object from
<trackBegin>. Your proposal to use the level crossing center as
reference point sounds reasonable to me. What does the rest of the
community think about it?
For the definition of the @absPos attribute we need to be more generic
(not mentioning Banedata...). My proposal for @absPos: This is the
position of the level crossing (center) in the railway line kilometer
reference system (mileage). What do you think?
> Furthermore we introduced to new attributes which define the
> start and end position of the level crossing precisely. With
> this information the length of the element can be
> calculated.
> @nor:roadStartPos: This attribute is used to store the
> measured start position of the road the railway track is
> crossing. It is measured along the track from <trackBegin>,
> similar to the attribute @pos.
> @nor:roadEndPos: see above, but end position
>
> As stated above, the length of the level crossing can be
> calculated by using the newly defined attributes making it
> therefore unnecessary to use @length.
No objections against introducing the extension attributes
@nor:roadStartPos and @nor:roadEndPos and their definitions, but the
last statement is not correct: in railML you are free to define
extensions using the "any anchor points" (element, attribute,
enumeration value) as long as the content expressed in this extension is
not already included in the existing railML model. Of course you can
calculate a length as difference between @nor:roadStartPos and
@nor:roadEndPos, but you must not leave the @length attribute empty and
refer to the new attributes.
So, here is my proposal: keep your extension attributes, calculate the
length from them, and then store this length information in the existing
attribute <levelCrossing>@length. It might look like a redundancy to
you, but for all others not following your extension proposal, the
situation is clear.
From this solution we can derive the following action item w.r.t.
documentation of railML element <levelCrossing>:
It has to be mentioned that @pos refers to the level crossing center and
that the @length of the level crossing need to be projected 50% before
the @pos and 50% behind the @pos value. This is important to mention,
because this approach differs from the existing way of modelling
elements with a length (e.g. tunnels). So, before we put this into a
Trac ticket, let me ask the community for their opinions.
> The attribute @dir is also not used for the element. Here I
> refer to this forum post: [2], in which it us suggested to
> deprecate @dir for <levelCrossing> among other elements.
If we want to mark the @dir attribute DEPRECATED for selected elements,
we have to define some rules for this approach.
My proposal: the @dir attribute represents an "application direction"
describing a direction of travel, for which the element has to be
considered:
* Example 1: a <signal> has a clear application direction as you can see
its lights only from one side.
* Example 2: the <levelCrossing> is always there, no matter from which
direction you come.
I am very interested in the feedback of the community on this approach...
Best regards
Christian
--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
