| Re: [railML 3] Areas in railML 3 [message #2836 is a reply to message #2833] |
Mon, 11 October 2021 12:37   |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear Fabiana, dear Thomas,
thank you for your input and ideas regarding modelling specific areas with railML 3.x. I agree with you to have a look at railML 2.5 implementation of <genericArea> first [1] and evaluate how to adapt it for railML 3.x.
Here comes my proposal:
* a new "view" is added to <infrastructure>: it is named <genericLocations>
* within <genericLocations> an arbitrary number of <genericArea> elements may exist
* a <genericArea> has an ID, name and designator attributes / child elements
* a <genericArea> contains child elements for specifying a location, e.g. as <circle> or <polygon>
* like any functional infrastructure element, the <genericArea> shall have child elements to be located within the topology network using <spotLocation>, <linearLocation> and/or <areaLocation>
* the <genericArea> may reference bounding elements using <isLimitedBy> references pointing to functional infrastructure elements
* the specific purpose of the generic area comes from outside via the specific elements pointing to the <genericArea>, e.g. an <etcsArea>
What does the community think about this approach?
[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
|
|
|
|
Members
Search
Help
Login
Home
