Forum: railML.infrastructure » Infrastructure element datamodel quality and input-data source

Home » railML newsgroups » railML.infrastructure » Infrastructure element datamodel quality and input-data source

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Infrastructure element datamodel quality and input-data source [message #3208]

Wed, 13 March 2024 11:44

Torben Brand
Messages: 170
Registered: March 2016

Senior Member

With partial reference to [1]

Bane NOR (and the Norwegian Railway Directorate) needs to describe the quality of the (railML) models. The used source for the input data to generate the model (that is transferred via railML) is important to define the quality. I have 3 questions here:

1. We currently use the free text string in railML2: state@remarks for this. But what is the equivalent in railML3? Is it maybe: elementState<name>@name or @description? Feels a bit strange to use <name> here. But @name is mandatory and @description is optional.
Example of a free text format we suggest to use in the Norwegian railway sector is:"Quality:gold; based on USO-15-S-00102_03B; 27.3.2023" So this could then be divided in <name language="en" name="quality:gold" description="based on USO-15-S-00102_03B; source document revision date 27.3.2023">? What goes into @name and what into @description? Or do you just use a dummy name and put the whole description in @description?

2. The infrastructure/element-State@value is important for the definition of the quality. We set elementState@value="operational"/"planned"/"conceptual" on specific elements. But we also set it on the planning/project area of the planned infrastructure that uses <genericArea> (with projectArea@ref to genericArea@id). Note it is currently undefined if the elements within that area inherit the state value (unless specific referenced from elementState@refersToElement).
The question is: can <elementState@refersToElement refer to genericArea@id?

3. There is a desire to model the source and quality descriptions of individual elements or elements grouped in an area (question 2 above) more unambiguously than in free text (as discussed in question 1) using uniform attributes. It would also have been nice to include this in railML3.3. Would this be possible? I have some modelling ideas...

[1]: https://www.railml.org/forum/index.php?t=msg&th=726& goto=2455&#msg_2455

[2] https://railoscope.com/tickets/TcBEfyVmiJTWLZm8?branchId=60a fb99b29ddd44671acafc8&modelId=6074970baba15e47fca2626c&a mp;selectId=5584-3

Update - now with an example of a project area with a state in a project specific branch (a snap shot relevant to the planned project) in Railoscope [2]:

The project area "Rånåsfoss stasjon, forlenget kryssingsspor" has a status "planned" with remark "according to document "KVB-15-C-10000_00B". Elements marked with the status "conceptual" in the project area are based on a model for a 2-track station on a single-track line with ETCS (doc. no.: 202100192-11), adjusted to 740m effective train length for the Kongsvinger line in accordance with effect package 14." PS. Translated from the norwegian description in Railoscope (which is not transferred in railML3.2 as it is ambiguous see question 1).

The elements have different states according to the planning (some examples):
- Switch "1" has state "planned" as it is part of the plan referenced in the project area.
- Switch "2" has state "operational" as it is planned not to be changed as part of the plan referenced in the project area.
- All signals in the station have state "conceptual" as they are not part of the plan as this does not cover signalling. They are designed based on a template as described in the remark of the project area.

[Updated on: Mon, 18 March 2024 14:58]

Report message to a moderator

Re: Infrastructure element datamodel quality and input-data source [message #3213 is a reply to message #3208]

Mon, 18 March 2024 14:34

Torben Brand
Messages: 170
Registered: March 2016

Senior Member

In answer to my own previous post question nr. 3: creating new element(s) for the unambiguous description of parts of the input data source and its quality.

I suggest to add two new sub-elements <source> and <quality> to <infrastructureState>

My initial idea for a definition of a <source> element is:
<source> description of the input data for specific elements for the generation of the model transferred via railML.

With use of generic element <name> for name of:
- Document (example name="USO-15-S-00102_03B" description="Bane NOR system Proarc document number")
- File (example: name="60-00.00-T-SPO-GEOM-00-3.dwg" description="sent from the project engineer Jon Doe 08.02.2024"
- Source (example name="BaneData" description="Bane NOR asset management system")

My initial ideas for a definition of a <quality> element are:
<quality> description of the quality of the input data for specific elements that are contained in the railML model.

With the choice for use of either the generic element <name> for a looser description of the quality or use of <designator> for a standardised quality system/scale and its entry value.

Examples for such a system could be with levels 1-10 with 10 is best quality and 1 is worst. With definition of the 10 quality levels. For example, level 10 measured with a precision of +/- 20 cm and correct attribute values verified according to use case. Level 1: do not use for input data for use case RTCI. Only basic sketch as a foundation for further work.
With use of <designator> you can use your own defined scaling system. For instance Bane NOR is thinking about using a simpler scale with three levels "gold"/"silver"/"bronze".

The element names "source" and "quality" should obviously be checked to be Dublin core compliant.

Alternative we could use Dublin core elements in <metadata> for certain quality levels and reference between those and <elementState>.

Report message to a moderator

Re: Infrastructure element datamodel quality and input-data source [message #3233 is a reply to message #3213]

Fri, 26 April 2024 18:09

Thomas Nygreen
Messages: 79
Registered: March 2008

Member

Dear Torben,

Regarding your question 1, I have to point out that human readable properties like name and description "are not to be used to contain computer-processable data, nor shall it be parsed by programmes in any way." (see https://wiki3.railml.org/wiki/Dev:Identities#Differentiation _from_other_indications)

Regarding question 2, there is also a proposal to move states into Common, to allow use by all the subschemas: https://development.railml.org/railml/version3/-/issues/491
I still think the interpretation of a state referring to an area should be decided in the Infrastructure community.

Regarding question 3, is this covered by an existing or proposed railML 3 use case?

Best regards
Thomas

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: Infrastructure element datamodel quality and input-data source [message #3234 is a reply to message #3233]

Sat, 27 April 2024 09:10

Torben Brand
Messages: 170
Registered: March 2016

Senior Member

Unfortunately I was a bit over eager in my description and described in question 1 something that should be computer parsed. So the (strict) answer is quite correct. However the content is currently only human readable. See example:
«According to KVB-15-C-10000_00B.
Elements marked with the status "conceptual" in the project area are based on a template for a 2-track station on a single-track line with ETCS (doc. no.: 202100192-11), adjusted to 740m effective train length for the Kongsvinger line according to effect package 14. (added by Torben Brand, 24.8.2023)»
So the question remains where to put this human readable text string in railML3.2?

What does the instrastructure coordinator think about question 2?:
can <elementState@refersToElement refer to genericArea@id or projectArea@id? And if yes: which one of the two?

Answer to question 3 is no. So I suggest I make a draft «quality» UC together with the common coordinator and present this in the autum conference to be proposed to be developed in a comunity working group for railML 3.4.

Report message to a moderator

Re: Infrastructure element datamodel quality and input-data source [message #3259 is a reply to message #3234]

Fri, 21 June 2024 13:49

christian.rahmig
Messages: 474
Registered: January 2016

Senior Member

Dear Torben,

thank you for your data model quality input and for your patience waiting for my answer...

Regarding question 2:
From my perspective, elementState can refer to a genericArea, as well as to a projectArea. The question is what is more useful? A genericArea carries relatively little information whereas a projectArea is linked with relevant project meta data. So, I would prefer the projectArea...

Regarding question 3:
I would be very happy and appreciate if you can initiate a data model quality use case and prepare it until the autumn conference. I am sure that the quality topic is interesting also for other members of the community...

Regarding question 1:
Well, this is of course closely linked with question 3. So, before we introduce a string attribute somewhere for information that could be structured in more detail, I prefer to go for the full solution with railML 3.4. But if you and the community have an urgent need, let's find a straight and low-level work-around...

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: Infrastructure element datamodel quality and input-data source [message #3266 is a reply to message #3259]

Fri, 05 July 2024 10:13

Torben Brand
Messages: 170
Registered: March 2016

Senior Member

Dear Christian,

Thank you for your reply.
I think I now have a clear plan! :-)

Regarding question 2: I tricked you due to my lack of railML3 knowledge ;-). The <projectArea> does not have an @id, so the ref can only be to the <genericArea>.

Regarding question 3: Yes, I would very much like to propose a data quality UC. I will ask Bane NOR to participate in the initial draft as they have proposed some system using ISO25012 [1]

Regarding question 1: As an interim sollution for a free-text to describe the quality I suggest to use the name@description already existing under <elementState>. With name@name beeing the short description or a default value like "State remark". The later, when you only have a description field of the state in your tool (as @name is mandatory when using <name>).

See example I made bellow of the "simplest example" found here [2]

    <infrastructureStates>
      <infrastructureState id="iss1">
        <elementState id="es_are101" refersToElement="are101" value="conceptual"/>
          <name name="State Remark" description="According to KVB-15-C-10000_00B. Elements marked with the status &quot;conceptual&quot; in the project area are based on a template for a 2-track station on a single-track line with ETCS (doc. no.: 202100192-11), adjusted to 740m effective train length for the Kongsvinger line according to effect package 14. (added by Torben Brand, 24.8.2023)" language="en"/>
	 </elementState>
      </infrastructureState>
    </infrastructureStates>
...
    <genericLocations>
      <genericArea id="are101">
        <name description="Description: " language="en" name="Project new bridge &quot;Bruse&quot;"/>
        <location>
          <circle radius="0">
            <centerPoint>
              <gml4rail3:pos>0 0</gml4rail3:pos>
            </centerPoint>
          </circle>
        </location>
        <isLimitedBy ref="bor99"/>
        <isLimitedBy ref="bor100"/>
      </genericArea>
    </genericLocations>
...
   <projects>
      <project id="pr6921e524-bf24-145f-f9b3-8428457225c9">
        <name language="no" name="&quot;Bruse&quot; brigde"/>
        <projectArea ref="are101"/>
        <alternative id="pra8b26d91f-791b-16f0-b980-da5ff7ee80e8">
          <name description="Axcle load increase according to concept A2" language="en" name="Brigde improvement"/>
        </alternative>
        <phase id="prp6473936e-7fc0-996f-e56e-0db99c3020ca" startDate="2020-10-01">
          <name language="en" name="As built"/>
        </phase>
      </project>
    </projects>

[1] https://iso25000.com/index.php/en/iso-25000-standards/iso-25 012
[2] https://railoscope.com/tickets/Fyh1WAZliOQbgVmY?modelId=5c81 5c32137e0f14761f0ba8&selectId=81-3

Report message to a moderator

Re: Infrastructure element datamodel quality and input-data source [message #3272 is a reply to message #3266]

Fri, 02 August 2024 15:23

christian.rahmig
Messages: 474
Registered: January 2016

Senior Member

Dear Torben,

thank you for the proposal and first ideas on modelling data quality with the existing schema. This looks fine to me, but let's wait for further feedback from the community.
Dear community, please share with us your feedback...

Thank you very much and best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Previous Topic:	[railML3] <border> representing open ends
Next Topic:	[railML3] Improvement for railML element „etcsLevelTransition"

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Mon Dec 09 21:40:21 CET 2024