Home » railML newsgroups » railML.infrastructure » [railML2] Adding a new element informationArea to ocp
|
|
| Re: [railML2] Adding a new element informationArea to ocp [message #2738 is a reply to message #2733] |
Fri, 28 May 2021 13:37   |
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 #2759 is a reply to message #2743] |
Fri, 11 June 2021 16:25 |
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 #2764 is a reply to message #2761] |
Tue, 15 June 2021 11:01 |
Milan Wölke
Messages: 150
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 #2773 is a reply to message #2765] |
Fri, 25 June 2021 15:05 |
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 |
Torben Brand
Messages: 165
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 |
Thomas Nygreen
Messages: 78
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 #2789 is a reply to message #2787] |
Sat, 10 July 2021 22:11 |
Thomas Nygreen
Messages: 78
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 |
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 |
Christian Rößiger
Messages: 63
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 #2799 is a reply to message #2797] |
Mon, 26 July 2021 16:00 |
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 |
Milan Wölke
Messages: 150
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 |
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 |
Milan Wölke
Messages: 150
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 #2815 is a reply to message #2812] |
Thu, 19 August 2021 15:30 |
Milan Wölke
Messages: 150
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 |
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 |
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
|
|
|
|
Goto Forum:
Current Time: Sun Nov 03 20:42:13 CET 2024
|
Members
Search
Help
Login
Home
