infrastructure "state" [message #1858] |
Thu, 28 June 2018 08:46 |
christian.rahmig
Messages: 463 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
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
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 |
christian.rahmig
Messages: 463 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
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
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 |
Tobias Bregulla
Messages: 20 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 |
christian.rahmig
Messages: 463 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
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
Re: infrastructure "state" [message #2025 is a reply to message #2010] |
Mon, 26 November 2018 16:28 |
christian.rahmig
Messages: 463 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
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
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 |
Thomas Nygreen JBD
Messages: 68 Registered: February 2017
|
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
Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
|
|
|
Re: infrastructure "state" [message #2049 is a reply to message #2028] |
Wed, 19 December 2018 15:33 |
christian.rahmig
Messages: 463 Registered: January 2016
|
Senior Member |
|
|
Dear Thomas,
Am 03.12.2018 um 16:36 schrieb Thomas Nygreen:
> [...]
> I strongly disagree with constraining
> @status=conceptual|planned to @disabled=true. [...]
>
> 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.
let me briefly summarize your proposal:
@status="conceptual" --> @disabled="true/false"
@status="planned" --> @disabled="true/false"
@status="operational" --> @disabled="false"
@status="disabled" --> @disabled="true"
@status="closed" --> @disabled="true"
In case that there won't be any conflicting reactions on this proposal
until the end of year, I am going to bring it into the forum as semantic
rule for 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
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|