| Re: InfraAttributes and InfraAttrGroups [message #1406 is a reply to message #1396] |
Thu, 01 September 2016 08:41   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Christoph,
there is currently no other option than to use the "any other" extension
point of an <ocp> to add an <infraAttributes> to an <ocp>.
Since an <ocp> has plenty of attributes and properties so far, I guess
there was no need to do so.
But, it is normally not in the sense of railML to extend it with a
structure coming from railML itself. In other words, the "any other"
extension point should, in my understanding, only be used with your own
sub-structures. If you really need an extension with a railML-own
sub-structure (as <infraAttributes>) there should be an "official" way
to do so.
So my question would be now: Which information exactly do you want to
add to an <ocp>? Since there are these plenty of properties of <ocp>s I
wonder why there is not already a solution for it.
To describe the "owner" of an <ocp>, what your example suggests:
- Please be aware that <ocp> is only a virtual place for a
cross-reference from lines and tracks to the timetable (and vice-versa).
Therefore, the typical place for an <ocp> is the middle of a station or
the middle of a platform of a station alongside a track. There is no
<ocp> in reality. That's why there is no "direct" owner of an ocp so far.
- For the owner of the tracks of an ocp, use <owner
infrastructureManagerRef=.../> of the track.
- For the owner of the platforms of an ocp, there should be a
possibility to use an /infrastructureManagerRef/ attribute at a
<platformEdge>. I do not know whether there is one right now, but if not
it should be better to solve the problem in this way.
- For the owner of the overhead wires of an ocp... And so on, there
should be /infrastructureManagerRefs/ at each physical infrastructure
element.
It is surely not acceptable to use "dummy tracks".
I would suggest you write here by which attributes you want to extend an
<ocp>. This may help us to understand the character and generality of
the extension. May be Christian can check whether there is already a
solution for them.
With best regards,
Dirk Bräuer.
---
Am 16.08.2016 um 15:24 schrieb Christoph Jobmann:
> Greetings,
>
> I recently started looking into the infrastructure
> subschema.
>
> As far as I can tell the element InfraAttrGroup and thereby
> the underlying InfraAttributes elements can only be
> references by track elements. That makes sense considering
> that most infraAttributes children are strongly connected to
> tracks.
>
> Are there similar elements that can be used for the elements
> of type ocp? If not - are there plans to add them?
> For now I see three ways to add information I would rather
> wrap up in some kind of attribute Containers:
>
> Use the regular extension Point and add an element for
> referencing infraAttributes Element Use the "other"
> extension point and add references as user-defined
> attributes or elements. Add a trackref pointing to a dummy
> track that contains an appropriate attributeGroupRefs
> element
>
> I prefer the first option, even though it has the downside
> that it enables connecting an ocp with attributes that only
> make sense for tracks.
> The second option has the downside that the
> generalInfraAttribute Elements can not be used anymore.
> The third option is not really an option from my point of
> view - but it is the only way I see without adding new
> user-defined elements or attributes.
>
> I made up an example where the options are demonstrated and
> hope that they help understanding my point. Extensions are
> marked by a NEW: prefix.
>
> <railml>
> <metadata>
> <infrastructureManager id="im1" name="DB Netz AG"/>
> </metadata>
> <infrastructure id="i">
> <infraAttrGroups>
> <infraAttributes id="ia1">
> <owner infrastructureManagerRef="im1"/>
> </infraAttributes>
> <infraAttributes id="ia2">
> <generalInfraAttributes>
> <generalInfraAttribute>
> <attributes>
> <attribute name="myNewAttribute" value="42"/>
>
> </attributes>
> </generalInfraAttribute>
> </generalInfraAttributes>
> </infraAttributes>
> </infraAttrGroups>
> <tracks>
> <track id="dummy1">
> <infraAttrGroupRefs>
> <infraAttrGroupRef ref="ia1"/>
> <infraAttrGroupRef ref="ia2"/>
> </infraAttrGroupRefs>
> </track>
> </tracks>
> <operationControlPoints>
> <ocp id="ocp1">
> <!-- Option 1 -->
> <NEW:infraAttrGroupRefs>
> <NEW:infraAttrGroupRef ref="ia1"/>
> <NEW:infraAttrGroupRef ref="ia2"/>
> </NEW:infraAttrGroupRefs>
> </ocp>
> <ocp id="ocp2" NEW:OwnerRef="im1">
> <!-- Option 2 -->
> <NEW:myNewAttribute value="42"/>
> </ocp>
> <ocp id="ocp3">
> <!-- Option 3 -->
> <propEquipment>
> <trackRef ref="dummy1">
> </propEquipment>
> </ocp>
> </operationControlPoints>
> </infrastructure>
> </railml>
>
> Am I missing something? Which way is considered as best, are
> there other ways?
>
> Kind regards
> Christoph Jobmann
|
|
|
|
Members
Search
Help
Login
Home
