Home » railML newsgroups » railML.infrastructure » [railML2] Adding a new element informationArea to ocp
[railML2] Adding a new element informationArea to ocp [message #2733] Mon, 24 May 2021 12:58 Go to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 153
Registered: April 2007
Senior Member
Hi,

in the timetable developer group we recently discussed passenger information in trains and its support by railML. Many of the timetable extensions for railML 2.5 are inspired by the need of feeding systems related to passenger information using railML. Most of these could be handled inside the timetable subschema itself.
However we recently came across some requirements that would be best modelled by extending the infrastructure subschema. In particular we were thinking about ways to describe when a special text on a display should be shown and when it should be removed again. The requirement from the community is that this should be possible when entering or leaving a certain area that can be defined around a point in the infrastructure. From our point of view such area would best be defined in the infrastructure subschema as part of the OCP.

Looking at the existing work in infrastructure we came up with this idea for modelling areas like that:

/forum/index.php?t=getfile&id=83&private=0

So below //infrastructure/operationControlPoints/ocp/propOther we would like to add "informationAreas" as a container, that can be filled with informationArea elements, each specifying an id for later referencing from timetable. Each informationArea would define its shape around the OCP as a set of coordinates. We so far discussed rectangle, polygon and circle.
While the definition of circle and polygone is pretty clear to us, we would appreciate help in modelling rectangular areas. Our discussing showed that using two points like we usually do in computer graphics will not work. So also here we would like to benefit from the experience of the infrastructure group.

So to sum it up, we want to add information areas to the OCPs and we would need help in describing a rectangular area in a non redundant way with geocoordinates.

What is your opinion? What should the name of such information area be? Can you help us with the rectangle?

Thanks in advance for any support you can render.

Best regards, Milan
  • Attachment: infoArea.png
    (Size: 53.09KB, Downloaded 1023 times)


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2738 is a reply to message #2733] Fri, 28 May 2021 13:37 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear Milan,

thank you for sharing these ideas from the TT developers group with the IS community.

The approach of modelling "infomation areas" around OCPs sounds reasonable although it is not "touchable" infrastructure in a straight definition. So, I am curious to hear/read from the community about their needs for having information areas modelled within railML 2.5.

Some specific questions:
* Will information areas also needed for other infrastructure elements, e.g. level crossings or bridges or tunnels?
* naming: To make it more precise, how about <passengerInformationArea>?
* Is there any linking with other types of areas, e.g. track-related areas?

Finally, let's come to the rectangle challenge:
Generally, any kind of area will use <geoCoord> elements to define certain points describing the area boundaries. Every <geoCoord> element contains the attribute @epsgCode to define the coordinate reference system of the coordinate. For instance, EPSG::4326 specifies a WGS84 coordinate in 2D with latitude and longitude axes. Therefore, although not explicitly modelled in railML, the axes of the coordinates are given. Consequently, it is absolutely possible to model a rectangle using two coordinate positions: the rectangle is defined by lower left and upper right point with sides being parallel to the axes defined by the coordinate reference system (EPSG code). But you have to make sure, that all coordinate positions of the rectangle (as well as for any other geoemtry) are linked with the same coordinate reference system.

Any comments from the community are highly appreciated...

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2743 is a reply to message #2738] Tue, 01 June 2021 16:25 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 64
Registered: March 2015
Member
Hello Christian,

we have another question about the representation of the <information
Areas>. We use the <tGeoCoord> elements to define their dimensions.
These also contain information about the height of an item. However, in
the context of the <informationArea> this is irrelevant and could
possibly lead to confusion. In our view, it would be a clearer modelling
if we used geo-coordinates that do not contain height information. Since
we do not necessarily want to introduce a new element for this, our
question is whether such an element already exists. Alternatively, we
would use the existing <tGeoCoord> element and point out in the
documentation that in this context the height should not be specified.

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: [railML2] Adding a new element informationArea to ocp [message #2755 is a reply to message #2743] Fri, 11 June 2021 13:21 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 169
Registered: March 2016
Senior Member
Hi,

I would like to make you aware of the proposal for a generic area in railML2.5 (but now postponed for 2.6).
Orriginal proposal (found here https://www.railml.org/forum/index.php?t=msg&th=804& goto=2681&#msg_2681) was for UC for trac sections (for TVD), but implementation as in railML2.4nor (See chapter 4.6 in https://www.jernbanedirektoratet.no/globalassets/documenter/ railml/20201217_railml2.4norisdocumentation_v1.4.pdf) is generic and could also be used for the purpose of an OCP information area.
Re: [railML2] Adding a new element informationArea to ocp [message #2759 is a reply to message #2743] Fri, 11 June 2021 16:25 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear Christian,

Christian Rößiger wrote on Tue, 01 June 2021 16:25
...
In our view, it would be a clearer modelling if we used geo-coordinates that do not contain height information. Since
we do not necessarily want to introduce a new element for this, our
question is whether such an element already exists. Alternatively, we
would use the existing <tGeoCoord> element and point out in the
documentation that in this context the height should not be specified.

I suggest to define this rule of having only 2-dimensional coordinates for information areas as a semantic constraint for two reasons:
* we don't need to define a new datatype for a spatial coordinate, but can make use of the existing one
* we remain open for future changes, e.g. when railways conquer also the vertical dimension of space ;-)

I created a new Trac ticket #473 [1] for the topic to be included in railML 2.5.

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

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2761 is a reply to message #2755] Fri, 11 June 2021 16:30 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear all,

Torben Brand wrote on Fri, 11 June 2021 13:21
Hi,

I would like to make you aware of the proposal for a generic area in railML2.5 (but now postponed for 2.6).
Orriginal proposal (found here https://www.railml.org/forum/index.php?t=msg&th=804& goto=2681&#msg_2681) was for UC for trac sections (for TVD), but implementation as in railML2.4nor (See chapter 4.6 in https://www.jernbanedirektoratet.no/globalassets/documenter/ railml/20201217_railml2.4norisdocumentation_v1.4.pdf) is generic and could also be used for the purpose of an OCP information area.

I appreciate Torben's idea of fusing the approaches of the generic <area> and the OCP's informationArea. What does the community think about it? And secondly, is it sufficient to have the OCP's informationArea implemented with railML 2.6 (like planned for the generic <area> element)?

Any comments are very much welcome...

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2764 is a reply to message #2761] Tue, 15 June 2021 11:01 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 153
Registered: April 2007
Senior Member
Hi,

I am afraid postponing it to 2.6 would not be soon enough for some members of the timetable community. Since passenger information is a major point of the timetable 2.5 changes I think it would make sense to include that too in order too keep things together.

Regarding the questions above:

Quote:

* Will information areas also needed for other infrastructure elements, e.g. level crossings or bridges or tunnels?
* naming: To make it more precise, how about <passengerInformationArea>?
* Is there any linking with other types of areas, e.g. track-related areas?
We will need those information areas also for tracks and platformEdges. I have created a branch where those changes could be reviewed already in the repository: https://svn.railml.org/railML2/branches/passengerInfo.infras tructure/schema/
Other infrastructure elements havent been requested so far.

Regarding the naming I think your proposal would be fine and a bit more clear. Let me know if I should include that change in the branch above.

Regarding linking, Im not aware of such links. Dont think this is an issue.

Best regards, Milan




Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Tue, 15 June 2021 11:01]

Report message to a moderator

Re: [railML2] Adding a new element informationArea to ocp [message #2765 is a reply to message #2764] Tue, 15 June 2021 13:47 Go to previous messageGo to next message
Thomas Kabisch is currently offline  Thomas Kabisch
Messages: 8
Registered: September 2020
Junior Member
Hello,

for our use case "Passenger information within trains" it is essential to have some kind of area that surrounds dedicated infrastructure objects (most important are OCP's) available in RailML 2.5.
We use areas to control the dynamic behaviour of the PIS. For example, the PIS system initiatates an announcement in the moment when the train enters the area of a dedicated station.
A fusion with a generic area element is reasonable for us as well if a link between the underlying infrastructure element (i.e. ocp) and the area is supported.

Regards,
Thomas
Re: [railML2] Adding a new element informationArea to ocp [message #2773 is a reply to message #2765] Fri, 25 June 2021 15:05 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear Thomas and Milan,

thank you very much for your feedback. So, an implementation of the information area in railML 2.5 is intended.

However, we still need some clarification on the naming: There exists already an area element in railML 2 infrastructure (see [1]). In order to avoid confusion, we should agree on one of the following options:
* introduce <trackElements/area> anyway
* introduce <trackElements/area> and rename <ocp/area> in <ocp/zipCodeDistrict>
* introduce <trackElements/genericArea>
* introduce <trackElements/specificPurposeArea>

Which solution do you prefer? As usual, any comment is highly appreciated...

[1] https://wiki2.railml.org/wiki/IS:area

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
Re: [railML2] Adding a new element informationArea to ocp [message #2777 is a reply to message #2773] Sat, 26 June 2021 06:53 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 169
Registered: March 2016
Senior Member
Christian Rahmig <coord(at)infrastructurerailMLorg> wrote:
> Dear Thomas and Milan,
>
> thank you very much for your feedback. So, an implementation
> of the information area in railML 2.5 is intended.
>
> However, we still need some clarification on the naming:
> There exists already an area element in railML 2
> infrastructure (see [1]). In order to avoid confusion, we
> should agree on one of the following options:
> * introduce <trackElements/area> anyway
> * introduce <trackElements/area> and rename <ocp/area> in
> <ocp/zipCodeDistrict>
> * introduce <trackElements/genericArea>
> * introduce <trackElements/specificPurposeArea>
>
> Which solution do you prefer? As usual, any comment is
> highly appreciated...
>
> [1] https://wiki2.railml.org/wiki/IS:area
>
> Thank you very much and best regards
> Christian

Dear all,

The norwegian community would prefer a new generic implementation of «area»
as described in our earlier proposal that fullfills the use case of the
existing ocp zip code area (can then be deprecated), information area,
track section, work area, local area and project area. Note generic areas
can span over both tracks and ocps, so the suggestion is to place it in the
infrastructure root in a container: <infrastructure/areas/area> For the
rest of the suggested implementation see my previous posting.

--
TOBR
Re: [railML2] Adding a new element informationArea to ocp [message #2781 is a reply to message #2777] Thu, 01 July 2021 23:52 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 79
Registered: March 2008
Member
Dear all,

If merging the two area approaches, then <genericArea> seems like a good name suggestion. If we were to keep them separate, I suggest <trackArea> for the type defined by positions on tracks and maybe something like <geographicArea> for the type defined by geographic coordinates. When joining the two, it is important to make sure that the added flexibility has a benefit and does not only end up being a burden to the consumers of the files. Continuing on that note, I would suggest skipping the rectangle definition altogether, as it is just a special case of a polygon.

Following Torben's train of thoughts, how generic should we make this element? Possible properties include (at least):
  • The usuals: id, code, name, description
  • designator
  • list of references to limiting elements (defining the borders of the area in the track network)
  • geographic coordinates
  • ocp reference (or vice versa: the ocps can reference to its areas by id)
  • zip code or other external area codes or area names
Best regards,
Thomas


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2787 is a reply to message #2781] Fri, 09 July 2021 10:41 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear all,

the Trac ticket #393 [1] summarizes the planned railML 2.5 solution updated with all your comments. Please have a look at it and provide your feedback. Thank you very much.

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

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2789 is a reply to message #2787] Sat, 10 July 2021 22:11 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 79
Registered: March 2008
Member
Dear all,

I have two comments:

1: We should avoid two completely different <area> elements in IS (see Christian's comment from 25 June 2021). Of the options listed there, I prefer calling the new element <genericArea>. Another alternative is something like <infrastructureArea>.

2: I find the requirement that the first and final point of a polygon must be identical to be redundant. I suggest skipping this requirement, reducing the multiplicity to 3..∞ and defining that the final edge of the polygon, from the final to the first vertex is implied. In addition to remove redundancy, this also removes the question how to interpret a provided polygon where the first and final vertices do not match. Should anyone still happen to copy the first vertex at the end, the interpretation is still unambiguous and unchanged.

Best regards,
Thomas


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2791 is a reply to message #2789] Fri, 16 July 2021 13:47 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear Thomas,
dear all,

Thomas Nygreen wrote on Sat, 10 July 2021 22:11

1: We should avoid two completely different <area> elements in IS (see Christian's comment from 25 June 2021). Of the options listed there, I prefer calling the new element <genericArea>. Another alternative is something like <infrastructureArea>.

thank you for your feedback on the terms. As there has been not such a big resonance on my forum post from June 25, I wanted to pickup the topic and ask again for feedback from the community: <area> or <genericArea> or <infrastuctureArea>?

Thomas Nygreen wrote on Sat, 10 July 2021 22:11

2: I find the requirement that the first and final point of a polygon must be identical to be redundant. I suggest skipping this requirement, reducing the multiplicity to 3..∞ and defining that the final edge of the polygon, from the final to the first vertex is implied. In addition to remove redundancy, this also removes the question how to interpret a provided polygon where the first and final vertices do not match. Should anyone still happen to copy the first vertex at the end, the interpretation is still unambiguous and unchanged.

Interesting point! When I developed this solution proposal I was inspired by OpenStreetMap's approach with the element <way> [1]. There, repeating the first point is required in order to distinguish between an open way and a closed way / area. As our railML area is clearly focused on an area only, we can assume that all of these geometric forms are closed. So, I support your idea. What about other opinions from the community?

[1] https://wiki.openstreetmap.org/wiki/Way

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2796 is a reply to message #2781] Fri, 23 July 2021 11:01 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 64
Registered: March 2015
Member
Hello all,

Am 01.07.2021 um 23:52 schrieb Thomas Nygreen:
> Following Torben's train of thoughts, how generic should we
> make this element? Possible properties include (at least):
> The usuals: id, code, name, description
> designator
> list of references to limiting elements (defining the
> borders of the area in the track network)
> geographic coordinates
> ocp reference (or vice versa: the ocps can reference to its
> areas by id)
> zip code or other external area codes or area names

I like the idea of a generic <area>. However, I would strictly ensure
that this element does not contain any properties that are needed for a
specific use case. In my view, an <area> should simply represent an area
on the surface of the earth.
Accordingly, an <area> should not contain any references to <controller>
and <ocp> and also no <state> element as suggested by Christian Rahmig.
This implies that the areas must be referenced from their "owners"
(<controller>, <ocp>), in general several <areas> per owner should be
possible.
Likewise, I would avoid the attribute "type", as this property can also
be derived from the referencing element.

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: [railML2] Adding a new element informationArea to ocp [message #2797 is a reply to message #2796] Fri, 23 July 2021 18:21 Go to previous messageGo to next message
Thomas Kabisch is currently offline  Thomas Kabisch
Messages: 8
Registered: September 2020
Junior Member
Hello everybody,

the idea of having a generic area concept works fine also in our use case "Passenger information within trains".

In our understanding, the area is tightly related to a specific infrastructure element (for the PIS use case, only ocps are required).
For example, we use these areas together with the GPS signal of the train to determine that the train is approaching a particular station.

An only implicit link between the ocp and the area will likely lead to a missinterpretations (e.g. in case of short station distances with overlapping areas).

Therefore, we suggest to establish explicit links from the infrastructure element to the assigned areas. One infrastructure element should have the opportunity to link to a number of areas.

Best regards,
Thomas Kabisch
Re: [railML2] Adding a new element informationArea to ocp [message #2799 is a reply to message #2797] Mon, 26 July 2021 16:00 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear all,

thank you very much for your input and feedback, which I considered when updating the railML 2.5 solution proposal in Trac ticket #393 [1].

The central aspect is the direction of referencing: In order to keep the area generic (which is also visible from the renaming of the element from <area> into <genericArea>), all references from the area to other elements have been removed. Instead, specialization of a generic area is done via the reference from the infrastructure element to the area. For example, an OCP can refer to an arbitrary number of information areas with <informationArea> elements. Likewise, a track can refer to an arbitrary number of <workingArea> elements...

I hope that the adapted railML 2.5 solution proposal meets all your requirements (please cross-check with the Trac ticket #393) and I am looking forward to receiving your comments, critics, suggestions, questions, applause, ...

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

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2800 is a reply to message #2799] Tue, 27 July 2021 14:28 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 153
Registered: April 2007
Senior Member
Hi Christian,

First of all thanks for the work you put in this. The timetable developer group asked me to respond on their behalves to let you know that with your latest changes all wishes have been fulfilled. This should work for our usecases nicely and it should allow for future usage of areas in other use cases as well.

Placing the informationAreaRef inside a propPassengerInformation is a good idea from our point of view and could also be applied to the other places related to passenger information namely //track/mediaResources and //track/trackElements/platformEdges/platformEdge/mediaResour ces.

Thanks again for the your gr8 work.

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Tue, 27 July 2021 14:28]

Report message to a moderator

Re: [railML2] Adding a new element informationArea to ocp [message #2803 is a reply to message #2800] Mon, 02 August 2021 15:49 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear Milan,
dear all,

when we want to use <propPassengerInfo> not only with <ocp>, but also with <track> and <platformEdge>, the question arises, if this <propPassengerInfo> shall be generic or specific. In particular:
* using a generic <propPassengerInfo> would allow <informationArea> elements not only for <ocp>, but also for <platformEdge> and <track> elements.
* using a specific <propPassengerInfo> implementation could be used to restrict <informationArea> elements only for <ocp>

What do you think: do we need <informationArea> also for <track> and <platformEdge>?

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2806 is a reply to message #2803] Mon, 09 August 2021 13:20 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 153
Registered: April 2007
Senior Member
Hi Christian,

as there was no requirement from the community to provide those areas also for tracks as well as platformEdges I think I would go for the specific approach. If at a later time someone has a need for this, we could still unify, but for now I think specific is the way to go.

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2808 is a reply to message #2806] Fri, 13 August 2021 11:40 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Hello Milan,

thank you for your feedback. I followed your advice and implemented it the specific way in railML 2.5: There is now a child element <propPassengerInfo> for <track>, <ocp> and <platformEdge> encapsulating the <mediaResources>, but only for the element <ocp> the child element <propPassengerInfo/informationArea> exists.

All the details can be found in Trac tickets #393 [1], #473 [2] and #477 [3].

[1] https://trac.railml.org/ticket/393
[2] https://trac.railml.org/ticket/473
[3] https://trac.railml.org/ticket/477

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2812 is a reply to message #2808] Thu, 19 August 2021 12:16 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 169
Registered: March 2016
Senior Member
The proposal is quite a large redesign in a late stage. But the norwegian sector can live with the solution after we have checked it. What imideately somes to mind is that in #395:
- the sub element <localArea> is missing (as a redesign of in option 1 proposed @type="local")
- the removed controller reference from the generic area needs to be added somehow in the new sub elements (like for instance <trackVacancyDetectionArea>)
- a misunderstanding that working zones (#395) are the same as working areas and the attributes for working zones have been placed under workingArea. #395 should be as proposed but with a new sub elements <workingZone>

We need some more time to check for the rest... But in principle the solution suggestion as posted here and in #395 is acceptable.
Re: [railML2] Adding a new element informationArea to ocp [message #2815 is a reply to message #2812] Thu, 19 August 2021 15:30 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 153
Registered: April 2007
Senior Member
Hi Torben, as far as I know the idea for the controller reference is to reverse the direction of the reference. The area does not refer to the controller but rather the controller refers to the area. Otherwise the resulting areas would not be context free. We suggested to introducte context free areas, to avoid collecting various references of sorts to all kind of railML elements that all are optional except in that one use case where it is required.

Referencing the area from the //controllers/controller/trackVacancyDetectorArea/@ref would work for you, or am I missing something?

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Thu, 19 August 2021 15:40]

Report message to a moderator

Re: [railML2] Adding a new element informationArea to ocp [message #2817 is a reply to message #2815] Fri, 20 August 2021 14:47 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear all,

the reference between a controller and a track section / tvdSection is realized with the reference attribute <controller/trackVacancyDetectionArea>@ref. Yes, this approach inverts the originally planned reference from the (trackSection) area to the controller. Does this solution suit your requirements?

BR
Christian



Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Adding a new element informationArea to ocp [message #2819 is a reply to message #2812] Fri, 20 August 2021 17:35 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear Torben,

Torben Brand wrote on Thu, 19 August 2021 12:16

- the sub element <localArea> is missing (as a redesign of in option 1 proposed @type="local")

I updated the proposed railML 2.5 solution documented in Trac ticket #393 [1] following the suggestion by Thomas: a <controller> shall have a repeatable, but optional child element <localOperationArea>, which references a <genericArea> with the attribute @ref. This approach models an area that is locally controlled.

Torben Brand wrote on Thu, 19 August 2021 12:16

- a misunderstanding that working zones (#395) are the same as working areas and the attributes for working zones have been placed under workingArea. #395 should be as proposed but with a new sub elements <workingZone>

Following the latest discussion, I want to clarify: a <workZone> is some area considered for working, which is integrated into the interlocking system. Consequently, it is modelled as child element of <controller>, providing a reference to a <genericArea>. On the other side, there exist "track sections with impairments" affecting railway operation, e.g. by extending train running times. The reason for impairments can be construction sites or other reasons. I summarized this approach in modelling <impairmentSection> as optional, but repeatable child element of <track>, which references a <genericArea>.

If anyone has any comments on this updated implementation, please let us know ASAP.

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

BR
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML2] adding new element <area> for the mapping of track sections
Next Topic: [railML2] extension suggestion for the element <state> for working zones
Goto Forum:
  


Current Time: Thu Dec 05 14:12:41 CET 2024