Forum - RDF feed
https://www.railml.org/forum/index.php
geometric and linear coordinates in linearLocation
https://www.railml.org/forum/index.php?t=rview&goto=3088&th=909#msg_3088
There are two paths for geometric and linear coordinates in a <linearLocation>:
(1) Using the <geometricCoordinateBegin> and <geometricCoordinateEnd> or <linearCoordinateBegin> and <linearCoordinateEnd> of an <associatedNetElement>. This leaves no ambiguity.
(2) Using the subelements <geometricCoordinate> and <linearCoordinate> directly under <linearLocation>. These seem to be redundant to (1) and I have no idea how to interpret their presence.
Suggestion: remove the subelements <geometricCoordinate> and <linearCoordinate> directly from <linearLocation> (similarly to <areaLocation>).
Best regards,
Thomas]]>Thomas Nygreen2023-05-12T15:30:44-00:00RTM 1.4 released
https://www.railml.org/forum/index.php?t=rview&goto=3022&th=884#msg_3022
it has been some time since the last activities here in the RailTopoModel forum, but now I am pleased to inform you about the release of RailTopoModel version 1.4. This new version is basis for railML 3.2, which has been released on April 26, 2022 (see [1]). Our Gitlab system [2] holds all the issues and resulting model changes forming the basis for the new RTM version. It can be summarized, that the changes are not that many, but bring more clarity for the model usage.
RailTopoModel is also usable as own model independent from railML. The RTM website [3] provides further details on this. There, you can also find information about the timeline of planned future RailTopoModel development [4].
Now, that the new model version has been released and is available for download and usage, we are looking forward to receiving your feedback, comments and experiences with RTM 1.4. Based on this, we want to continue developing RTM matching the needs of the whole railway sector as best as possible.
Best regards
Christian]]>christian.rahmig2022-06-14T19:03:03-00:00Re: Modelling of gaps and overlaps in mileage
https://www.railml.org/forum/index.php?t=rview&goto=1975&th=602#msg_1975
Am 27.08.2018 um 16:12 schrieb Martin Karlsson:
> [...]
>
> I have already asked about this problem in a previous forum
> post
> ( https://www.railml.org/forum/index.php?t=msg&th=471& start=0&).
> This time, I would like to propose a solution.
>
> I suggest that the "measure" attribute of LinearCoordinate
> is replaced by two attributes, measureBase (an integer) and
> measureFraction (a double). Same for all the other measures,
> like startMeasure and endMeasure of LinearPositioningSystem.
> Alternatively, there could be a LinearMeasure class to use
> in all these cases, containing the attributes "base" and
> "fraction". Probably, the attribute "units" in
> LinearPositioningSystem should also be replaced by baseUnits
> and fractionUnits, for clarity.
This proposal sounds valid to me, and indeed, it could solve existing
problems of ambiguity related to railway line coordinates. Having a
"base measure" and a "fraction measure" instead of a single "measure"
therefore seems to be a very straight-forward solution.
The questions about mileages and their various specialities has already
been raised earlier [1] and is still waiting for a profound answer by
the RTM Expert Group. In particular, it has to be clarified how class
LinearAnchorPoint shall be used and which role it can play for defining
mileage gaps and overlaps.
--
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.rahmig2018-09-24T12:55:11-00:00Re: Proposal for incorporating length information in RTM NetElement
https://www.railml.org/forum/index.php?t=rview&goto=1973&th=579#msg_1973
Am 04.09.2018 um 11:18 schrieb Airy Magnien:
> Following further discussion in the RTM expert group, I
> confirm that the proposed solution is rejected.
>
the decision of RTM Expert Group on this issue is not in favor of
railML.org, but accepted. In case, length information need to be
explicitly provided, new versions of railML 3 will foresee an own
optional attribute @length that may be used complementary to intrinsic
coordinates.
The latest railML version 3.1 beta 2 is available in [1].
--
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.rahmig2018-09-17T12:02:40-00:00Re: Harmonize rolenames for association between *Location and *AssociatedNetElement
https://www.railml.org/forum/index.php?t=rview&goto=1972&th=592#msg_1972
Am 16.08.2018 um 10:24 schrieb Airy Magnien:
> This one is taken on board for the next release, together
> with a more significant change regarding linear locations.
can you please clarify your decision on this issue:
* Which future version (1.2 or 2) are you talking about?
* Will the suggested change be implemented with that new version or will
it be a matter of dicsussion then?
Thank you very much and 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.rahmig2018-09-17T11:41:34-00:00Re: Network location
https://www.railml.org/forum/index.php?t=rview&goto=1971&th=598#msg_1971
Am 16.08.2018 um 10:36 schrieb Airy Magnien:
> Located net entities are net entities, and Net Entities are
> Network Resources. As such, they can be unambiguously associated with
> any Network or LevelNetwork without
> referring to any particular Net Element.
>
> [...]
>
> Provisional conclusioin : your requirement seems to be
> fulfilled by the current version (RTM 1.1) without any
> changes.
I am not sure whether my requirement is fulfilled by current RTM 1.1
without any changes. EntityLocation derived classes may only refer to an
instance of PositioningNetElement via "netElement". If I read the RTM
UML correctly, this reference cannot be used to refer to a Network or
LevelNetwork. Secondly, referencing a Network or LevelNetwork does not
require an attribute "applicationDirection" (SpotLocation and
LinearLocation) or "associatedNetElements" (AreaLocation).
So, to cut it short: I don't see how to use existing *Location classes
to model a reference to a Network in whole. Please correct me if I am wrong.
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.rahmig2018-09-17T11:37:26-00:00Re: Reference to PositioningSystem
https://www.railml.org/forum/index.php?t=rview&goto=1970&th=558#msg_1970
Am 04.09.2018 um 11:34 schrieb Airy Magnien:
> [...] After review with RTM experts and
> talkback with C. Rahmig, this is where we are:
> Role 'positioningSystem' of class
> AssociatedPositioningSystem shall be made optional
> (cardinality 0..1 instead of 1). This leaves the possibility
> to omit redundant info. However it is not clear why this
> redundancy would cause a genuine problem. Our compromise
> solution is:
>
> - We insist that the relation shall me maintained, because
> it embodies the meaning of the AssociatedPositioningSystem
> class;
> - We recommend to use this redundancy for consistency
> checking;
> - We demand not to mix coordinates referring to different
> positioning systems in one same composition, because this is
> why the class "AssociatedPositioningSystem" has been
> introduced in the first place.
>
railML.org appreciates the decision of RTM Expert Group to make the
positioningSystem reference in class AssociatedPositioningSystem
optional. The resulting simplified solution has been implemented with
railML 3.1 beta 2 that is available in [1].
From modelling point of view, I generally prefer solutions without
redundancy in order to limit risk of inconsistencies. So, maybe the
question to be answered in future is whether the positioningSystem
reference shall be located in class AssociatedPositioningSystem OR in
PositioningSystemCoordinate.
--
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.rahmig2018-09-17T11:19:43-00:00Re: Lateral location of elements
https://www.railml.org/forum/index.php?t=rview&goto=1969&th=574#msg_1969
the following solution / clarification by RTM Expert Group has been
considered in latest railML version 3.1 beta (2) implementation. You may
download the related schema files etc. via railML's SVN repository in [1].
Am 04.09.2018 um 11:12 schrieb Airy Magnien:
> After discussion in the RTM expert group workflow, this is
> the result:
>
>
> - Side and positive "offset" (once the side is known) shall
> be provided
> - Semantic clarification: in general, "offset" may be
> positive or negative, we prefer not to use it in RTM because
> it may induce misunderstandings; instead:
> - Attributes @lateralSide and @lateralDistance are
> introduced, replacing the proposed @lateralOffset, where
> @lateralDistance is essentially positive. Rules are: both
> attributes are optional; if @lateralDistance is provided, it
> shall be positive or zero, and @lateralSide must also be
> provided.
> - Attributes @verticalSide (proposed values: 'up', 'down')
> and @verticalDistance also to be adopted, as suggested in
> the workflow, for reasons of consistency.
> ]]>christian.rahmig2018-09-17T10:29:09-00:00Re: Feedback from 1st railML 3.1 Workshop 09./10.01.2018 - intrinsic coordinates
https://www.railml.org/forum/index.php?t=rview&goto=1954&th=550#msg_1954
Airy Magnien2018-09-04T09:36:56-00:00Re: Reference to PositioningSystem
https://www.railml.org/forum/index.php?t=rview&goto=1953&th=558#msg_1953
Role 'positioningSystem' of class AssociatedPositioningSystem shall be made optional (cardinality 0..1 instead of 1). This leaves the possibility to omit redundant info. However it is not clear why this redundancy would cause a genuine problem. Our compromise solution is:
- We insist that the relation shall me maintained, because it embodies the meaning of the AssociatedPositioningSystem class;
- We recommend to use this redundancy for consistency checking;
- We demand not to mix coordinates referring to different positioning systems in one same composition, because this is why the class "AssociatedPositioningSystem" has been introduced in the first place.
]]>Airy Magnien2018-09-04T09:34:37-00:00