Home » railML newsgroups » railml.infrastructure » [railML3] Mandatory <length> element for <track>s
[railML3] Mandatory <length> element for <track>s [message #2224] Thu, 18 July 2019 16:15 Go to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 36
Registered: March 2015
Member
Dear all,

In the current railML schema of version 3.1, one <track> element must
contain 1 or more sub-elements of type <length>. This allows different
lengths (constructional, operational) to be mapped.
From my point of view it is awkward that at least one <length> element
must be specified. For the exchange of timetable data, for example, the
length of a <track> is irrelevant if the infrastructure in the source
and target systems is known.
On the other hand, the scheme only defines that at least one length must
be specified, but not which type (constructional, operational). A system
that can only process one type of length does not benefit from this
constraint.
From my point of view the specification of a <length> for a <track>
element should be completely optional in the next version of the railML
schema. If necessary, the specification of a specific length definition
depending on the usecase can be forced by semantic constraints. What do
you think about this?

Best regards,
Christian Rößiger

--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
Re: [railML3] Mandatory <length> element for <track>s [message #2231 is a reply to message #2224] Mon, 26 August 2019 12:49 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 241
Registered: January 2016
Senior Member
Dear Christian,

Am 18.07.2019 um 16:15 schrieb Christian Rößiger:
> [...]
> From my point of view the specification of a <length> for a <track>
> element should be completely optional in the next version of the railML
> schema. If necessary, the specification of a specific length definition
> depending on the usecase can be forced by semantic constraints. What do
> you think about this?

thank you very much for sharing your idea about making the track length
optional with the community.

Indeed, the question is essential. When making <track><length> mandatory
we followed discussion about the problem of locating elements
(NetEntities) in the topology network without intrinsic coordinates, but
with "positions". Without the information about the track's length, it
is impossible to derive an intrinsic location of the element, which is
being calculated as position/length and thus covers a range {0..1}. So,
in order to make intrinsic coordinates optional, we decided to make
<length> mandatory.

How to continue in future?
If there is a strong demand by the community, we have to think about the
mandatory <length> once again. Everybody is invited to provide their
thoughts on the topic...

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
Re: [railML3] Mandatory <length> element for <track>s [message #2241 is a reply to message #2231] Thu, 29 August 2019 17:16 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 36
Registered: March 2015
Member
Dear Christian,

I haven't quite understood the background yet. Apparently the <length>
element is necessary to calculate the position of elements. But aren't
the positioning systems in the topology layer intended for this?
Apart from that, the scheme only specifies that I have to specify at
least one <length> sub-element for a <track> element, but not which one.
For example, it is possible to specify different <length> elements for
both directions or to distinguish between operational and constructional
length. This certainly makes sense for defining different operational
effective lengths of a track, but is not suitable for calculating
positions and distances.
If the <length> property must actually be mandatory, because it is
required for the calculation of positions, then it should also be forced
in the scheme that it is the structural length of the <track>, which
must also be identical for both directions.

Best regards Christian

--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
Re: [railML3] Mandatory <length> element for <track>s [message #2244 is a reply to message #2241] Mon, 02 September 2019 12:05 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 241
Registered: January 2016
Senior Member
Dear Christian,

Am 29.08.2019 um 17:16 schrieb Christian Rößiger:
> [...]
> If the <length> property must actually be mandatory, because it is
> required for the calculation of positions, then it should also be forced
> in the scheme that it is the structural length of the <track>, which
> must also be identical for both directions.

Thank you for your input on this discussion.

I think it is not guaranteed that <length> is always ment to address
physical lengths in each use case. For example, the
RINF/NetworkStatement use case [1] will be more likely to work with
usable lengths only.

So, considering these use case specific modelling issues I assume that
you want to have <length> becoming optional?
@all: what is your opinion on this?

[1] https://wiki.railml.org/index.php?title=UC:IS:NetworkStateme nt

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
Re: [railML3] Mandatory <length> element for <track>s [message #2249 is a reply to message #2244] Tue, 17 September 2019 09:38 Go to previous messageGo to next message
Fabiana Diotallevi is currently offline  Fabiana Diotallevi
Messages: 16
Registered: October 2018
Junior Member
Dear all,
I also agree to make the track length optional.

As suggested by Christian, the position of all the involved elements should be derived from the topology layer defined by the netElements, which provide with their intrinsic coordinates a reference to the specific used positioning systems (linear or geometric).
I think that the netElements should be the "building blocks" that, alone, are able to define the link between the "logical" and the "real" world: any other element position should be derived from the reference system defined by the netElements network.

To check the stability of this assert we are currently implementing the automatic import/export of railML 3.1 data on our RaIL-AiD tool by making the intrinsic coordinate definition mandatory for all the netElements.
Re: [railML3] Mandatory <length> element for <track>s [message #2254 is a reply to message #2249] Mon, 07 October 2019 21:33 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 241
Registered: January 2016
Senior Member
Dear Fabiana,

Am 17.09.2019 um 09:38 schrieb Fabiana Diotallevi:
> [...] I also agree to make the track length optional.

Thank you for your feedback!

> As suggested by Christian, the position of all the involved
> elements should be derived from the topology layer defined
> by the netElements, which provide with their intrinsic
> coordinates a reference to the specific used positioning
> systems (linear or geometric).
> I think that the netElements should be the "building blocks"
> that, alone, are able to define the link between the
> "logical" and the "real" world: any other element position
> should be derived from the reference system defined by the
> netElements network.

The answer to the question "What is the leading system for defining the
location reference?" is somewhat use case specific. There are scenarios
where the line kilometer system is the primary information and the
intrinsic coordinates are derived from this, but the other scenario
exists as well. railML shall suit all the different scenarios and
related use cases. Therefore, its syntax provides elements/attributes
for both, the intrinsic and the "extrinsic" location.

> To check the stability of this assert we are currently
> implementing the automatic import/export of railML 3.1 data
> on our RaIL-AiD tool by making the intrinsic coordinate
> definition mandatory for all the netElements.

That's a good idea! We at railML.org are interested in "real world
examples" and data sets. So, if you can show that the concept of
mandatory intrinsic coordinates works for your use case (SCTP -
Schematic Track Plan), we may cross-check this approach with other use
cases, too, and learn from the results. Probably, you can present first
experiences at the next railML Conference taking place in Brussels on
November 6, 2019?

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
Re: [railML3] Mandatory <length> element for <track>s [message #2269 is a reply to message #2254] Thu, 07 November 2019 14:59 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 241
Registered: January 2016
Senior Member
christian.rahmig wrote on Mon, 07 October 2019 21:33
Dear Fabiana,

Am 17.09.2019 um 09:38 schrieb Fabiana Diotallevi:
> [...] I also agree to make the track length optional.

Thank you for your feedback!

...
Dear active community,

in order not to forget about this issue to be solved with railML 3.2, I put the proposal into a new Trac ticket #369, see https://trac.railml.org/ticket/369.

Still, your feedback on the proposal is very much appreciated...

Best regards
Christian
Previous Topic: Definition of track/stoppingPlace/platform infrastructure vs. timetable
Goto Forum:
  


Current Time: Fri Nov 15 18:23:34 CET 2019