Home » railML newsgroups » railml.infrastructure » infrastructure "state"
infrastructure "state" [message #1858] Thu, 28 June 2018 08:46 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 181
Registered: January 2016
Senior Member
Dear all,

the state of infrastructure becomes more and more important for several
use cases and therefore requires an appropriate model implementation in
railML, too.

I would like to ask for your feedback on the following ideas related
with the infrastructure state:

1) operational view:
Infrastructure can be "available" or "not available" for operation.
Instead of "available" one could also use the term "valid". In any case,
the time reference (when is the infrastructure not available?) important.

2) asset life-cycle view
An infrastructure component is being "planned", then "manufactured" or
"constructed", then being put "in operation", after some years
"disabled", in between maybe several times "under construction", and
finally some day "removed" or "dismantled".
Despite the time, also the place is relevant here, because an
infrastructure component (e.g. switch) can be installed at different
locations in a track network during its lifetime.

3) funtional view
In railML 3.1 we define "functional infrastructure". Based on what I
wrote in 1) and 2) I consider the operational view to be identical with
the functional view. Do you agree?

Are there further views that I forgot to introduce?
Are there further states in these views that I forgot to mention?

Any comments are highly appreciated with regards to bringing them into
railML 3.1 beta2.

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: infrastructure "state" [message #1933 is a reply to message #1858] Thu, 30 August 2018 08:50 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 181
Registered: January 2016
Senior Member
Dear all,

in a first step of re-newing the data structure for modelling the
infrastructure state, the existing solution from OCP and from
infrastructure element shall be harmonized with upcoming railML 2.4.

OCP status is modelled:

<ocp ...>
<propOther @status="planned">
</ocp>

Further enumeration values are:
* operational
* disabled
* closed

The railML infrastructure element (e.g. levelCrossing) has a different
way of modelling states:

<levelCrossing ...>
<states>
<state disabled="true" operatingPeriodRef="..."/>
</states>
</levelCrossing>

Bringing both concepts together would strengthen the state modelling in
infrastructure. I therefore filed a ticket [1] for this issue that can
be realized quite quickly.

Any comments are appreciated...

[1] https://trac.railml.org/ticket/339

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: infrastructure "state" [message #1937 is a reply to message #1933] Thu, 30 August 2018 16:49 Go to previous messageGo to next message
Tobias Bregulla is currently offline  Tobias Bregulla
Messages: 15
Registered: June 2017
Junior Member
Dear all!

Am 30.08.2018 um 08:50 schrieb Christian Rahmig:
> OCP status is modelled:
>
> <ocp ...>
>   <propOther @status="planned">
> </ocp>
>
> Further enumeration values are:
> * operational
> * disabled
> * closed

We would suggest to add a fifth status for infrastructure, which is
intended to build but not in a real planning status. This would help to
exchange also future plannings e.g. for timetable simulation of long
term planning or for conceptual sketches/drawings.

In this context we suggest to add the following definitions to the
descriptions at https://wiki.railml.org/index.php?title=IS:propOther:

*Completed status value*: The construction or commissioning of the
element is planned for the medium or long term. However, there are still
no concrete (planning) activities for the construction of the element
beyond the preliminary planning and cost estimation.

PLANNED: The construction or commissioning of the element is planned
concretely and at short notice or concrete planning activities for the
construction take place, e.g. design, approval or implementation
planning, cost calculation, award of contracts. It is not normally
possible to use the element.

OPERATIONAL: The element is operational and can be used regularly.

DISABLED: The element is currently not usable, switched off or
deactivated and therefore cannot be used regularly. However, it can be
put back into operation at short notice without further construction,
acceptance or approval activities.

CLOSED: The element is no longer available, removed, dismantled, or no
longer exists. Planning, construction or commissioning activities are
absolutely necessary for recommissioning.

A German description with reference to the HOAI planning stages commonly
used in Germany can be provided.
For railML 3 we suggest a more intuitive naming of the enumeration values.

What does the community think about it?

Best regards,

Tobias and the Bahnkonzept team
Re: infrastructure "state" [message #1978 is a reply to message #1933] Tue, 02 October 2018 12:55 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 181
Registered: January 2016
Senior Member
Dear all,

Am 30.08.2018 um 08:50 schrieb Christian Rahmig:
> [...]
>
> [1] https://trac.railml.org/ticket/339

The concept described in Trac ticket [1] has been implemented (and
documented) with railML 2.4.

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: infrastructure "state" [message #2009 is a reply to message #1978] Thu, 08 November 2018 09:19 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 29
Registered: March 2015
Junior Member
Dear all,

Unfortunately I have only now noticed during the review of the wiki
pages for the <state> element that there is a new "state" attribute in
railML2.4 that de facto replaces or extends the previous "disabled"
attribute. The question for me is how to deal with the old "disabled"
attribute. It's certainly too late to declare it "deprecated with
version 2.4" now. Therefore, I would suggest at least to document in the
wiki that "disabled" and "state" must not have any contradictions. If
possible, only one of the two attributes should be used at a time.

Kind 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: infrastructure "state" [message #2010 is a reply to message #2009] Thu, 08 November 2018 11:50 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 29
Registered: March 2015
Junior Member
Dear all,

As I read in https://trac.railml.org/ticket/339, the attribute
"disabled" could not be set to deprecated because it is mandatory.
Therefore it must be kept in railML 2.4 and always be set. To keep the
consistency between both attributes, I would only add the following
dependencies to the wiki instead of my previous suggestion:

status = conceptual|planned|disabled|closed -> disabled=true
status = operational -> disabled=false

Are there any objections / improvements?

Kind regards
Christian Rößiger

Am 08.11.2018 um 09:19 schrieb Christian Rößiger:
> Dear all,
>
> Unfortunately I have only now noticed during the review of the wiki
> pages for the <state> element that there is a new "state" attribute in
> railML2.4 that de facto replaces or extends the previous "disabled"
> attribute. The question for me is how to deal with the old "disabled"
> attribute. It's certainly too late to declare it "deprecated with
> version 2.4" now. Therefore, I would suggest at least to document in the
> wiki that "disabled" and "state" must not have any contradictions. If
> possible, only one of the two attributes should be used at a time.
>
> Kind 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: infrastructure "state" [message #2025 is a reply to message #2010] Mon, 26 November 2018 16:28 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 181
Registered: January 2016
Senior Member
Hello Christian,

Am 08.11.2018 um 11:50 schrieb Christian Rößiger:
> [...] To keep the
> consistency between both attributes, I would only add the following
> dependencies to the wiki instead of my previous suggestion:
>
> status = conceptual|planned|disabled|closed -> disabled=true
> status = operational -> disabled=false
>
> Are there any objections / improvements?

since there have been no objections, I recommend to go ahead. Do you
want to add this semantic constraint on the wiki page [1] or do you want
me to do it?

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

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: infrastructure "state" [message #2028 is a reply to message #2025] Mon, 03 December 2018 16:36 Go to previous message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 17
Registered: February 2017
Junior Member
Dear all,

I strongly disagree with constraining @status=conceptual|planned to @disabled=true. That would conflict with the use case of simulating planned infrastructure, and break backwards compatibility. Any railML2.3 parser would interpret all planned elements as unusable.

It seems to me that there are different use cases requiring different values for @disabled when @status=conceptual|planned, depending on the relevant time frame.


For @status=operational|disabled|closed it seems more feasible to restrict the value for @disabled.

Best regards,
Thomas
Previous Topic: <railMLv3> Infra Geometry Terminology
Next Topic: How to model ETCS BL2 speed restrictions and gradients, in railML v2.x
Goto Forum:
  


Current Time: Mon Dec 10 16:25:48 CET 2018