Forum - RDF feed
https://www.railml.org/forum/index.php
creating a railML example for rolling stock for RTCI-b UC
https://www.railml.org/forum/index.php?t=rview&goto=3119&th=919#msg_3119
What does the WG think about creating an rolling stock example for RTCI-b UC?
I have attached the railML2.4nor export of the example.
From the documentation of railML2.4nor Example:
The Norwegian sector decided to attach one very simple example of railML2.4 RS to this documentation. This example is also available for viewing and exporting online in NorRailView the Norwegian railML2.4 editor and viewer. To view the example, please click Navigate and then the Model "railML2.4 Rollingstock Example for Norwegian documentation", to view the data in NRV. Click the -button to export to railML. In future also further examples and the public available operational rolling stock data set will be provided publicly accessible by the Norwegian sector in NorRailView. The following example is only meant to illustrate the syntax and the use of railML2.4 RS. The contained data is only meant as exemplary information and Jernbanedirektoratet does not guarantee that the contained data is correct.
]]>Torben Brand2023-09-01T10:30:28-00:00[railML3]: vehicle class - individual vehicle
https://www.railml.org/forum/index.php?t=rview&goto=3074&th=903#msg_3074
as result of discussion about correct handling of 'belongsToParent' in
terms of any inheritance the use of this attribute in vehicle element of
rollingstock schema was argued. The wording of this attribut suggest a
handling as aggregation which is not intended here. Therefore we will
set @belongsToParent in vehicle as deprecated in version 3.3. For the
correct usage of inheritance we will introduce 'basedOnTemplate' instead.
The intention was clearly to define all common features of a vehicle
class whereas an individual vehicle will inherit this and only
overwrites/extend the values with its own attributes. Thus the full
repetition of all common features for each individual vehicle can be
avoided.
https://development.railml.org/railml/version3/-/issues/510
--
Dr.-Ing. Jörg von Lingen - Rollingstock scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 351 87759 40; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org]]>Joerg von Lingen2023-04-18T04:39:30-00:00[railML3.2]: Proposal for removal of xs:any elements
https://www.railml.org/forum/index.php?t=rview&goto=2958&th=864#msg_2958
bei unserer letzten Konferenz in Göteborg, Schweden hatte unser
Common-Koordinator das Thema aufgebracht, in railML3 die Art und Weise
zu ändern, mit der Erweiterungen für railML erstellt werden können.
Thomas hat in dort eine neue Vorgehensweise vorgestellt, die sich
allerdings mit der gegenwärtigen Herangehensweise ausschließt. Er hat
dazu einen Forumpost erstellt, der leider bisher nicht viel Beachtung
gefunden hat.
Die railML.org-Koordinatoren halten es für eine gute Idee, diese neue
Technik zu nutzen, da es unter anderem erlaubt, auch Dokumente mit
eigenen Erweiterungen der jeweiligen railML-Schnittstellen zu
validieren. Da eine solche Änderung aber eben dazu führt, dass
bestehende Erweiterungen mit einer neuen railML Version nicht mehr
funktionieren werden, brauchen wir euer Feedback um zu prüfen, ob die
Vorteile, die wir auf dem neuen Weg sehen, auch euch überzeugen. Bitte
lasst uns unter dem Thread oben wissen, wie ihr darüber denkt.
Zum Hintergrund:
Bisher war die gängige Praxis im offiziellen railML Schema
Erweiterungspunkte vorzusehen. Damit wurde zugelassen, dass ein XML, das
an einer solchen Stelle Tags enthält, die nicht zu railML gehören,
trotzdem als valides railML angesehen wurde. Der Nachteil dieses
Vorgehens ist, dass es damit nicht möglich ist, durch das
Erweiterungsschema selbst festzulegen, wo diese railML-fremden Tags
zulässig sind und wo nicht. Eine Erweiterung, die dafür gedacht ist,
Öffnungszeiten für ein Stationsgebäude zu erfassen, könnte so auch dazu
genutzt werden, Öffnungszeiten für einen Umlauf zu erfassen oder für
eine Zugnummer. Dies ist fachlich nicht sinnvoll. Mit den
Erweiterungspunkten ist es nicht möglich, dies einzuschränken. Mit der
neu vorgeschlagenen Herangehensweise (siehe Forenpost) wäre das kein
Problem mehr. Zusätzlich könnten auch Tools zur Codegenerierung
eingesetzt werden, um effizienter Code zum Im- und Export von railML zu
implementieren.
Wir schlagen daher vor die Erweiterungspunkte mit railML 3.2 durch die
neue Vererbungsmethode abzulösen. Bitte lasst uns unter dem Link oben
wissen, wenn aus eurer Sicht fachlich/technisch etwas dagegen spricht.
----------------------------------
At our last conference in Gothenburg, Sweden, our Common Coordinator
raised the issue of changing the way extensions for railML can be
created in railML3. Thomas presented a new approach there, which is,
however, mutually exclusive with the current approach. He has created a
forum post on this, which unfortunately has not received much attention
so far.
The railML.org coordinators think it is a good idea to use this new
technique, as it allows, among other things, to validate documents with
custom extensions of the respective railML interfaces. However, since
such a change will mean that existing extensions will no longer work
with a new railML version, we need your feedback to check whether the
advantages we see in the new way are convincing to you as well. Please
let us know what you think under the thread above.
Background:
Previously, the common practice was to provide extension points in the
official railML schema. This allowed an XML that contained non-railML
tags at such a point to still be considered valid railML. The
disadvantage of this approach is that it is not possible to specify
through the extension schema itself where these non-railML tags are
allowed and where they are not. An extension that is intended to record
opening hours for a station building could thus also be used to record
opening hours for a circulation or for a train number. From a technical
point of view, this does not make sense. With the extension points it is
not possible to restrict this. With the newly proposed approach (see
forum post) this would no longer be a problem. In addition, code
generation tools could also be used to implement code for importing and
exporting railML more efficiently.
We therefore propose to replace the extension points with railML 3.2
with the new inheritance method. Please let us know at the link above
whether there are any professional/technical arguments against this from
your point of view.
--
Dr.-Ing. Jörg von Lingen - Rollingstock scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 351 87759 40; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org]]>Joerg von Lingen2022-03-16T10:19:34-00:00Re: [railML3.2] Cant Deficiency Class for RS and/or TT
https://www.railml.org/forum/index.php?t=rview&goto=2895&th=853#msg_2895
we will surely need possible brake positions separated from cant deficiency classes (as already existing in railML). This leads to possible contradictions between "original" brake positions and such encoded into integers of cant deficiency classes.
I understand that this does not necessarily need to be a direct redundancy. So, I do not dare to have a final conclusion here. However, in such cases it was at least in the past tradition in railML to tend to the basic physical values and leave the higher "aggregated" values to the context of the reading software. (For instance, this also applies to track classes A..E which can only be given within a certain national context. So, railML encodes the basic physical values of axle load and load spread.)
If there would be a resulting integer in railML like in UNISIG, there should also be the "original" cant deficiency separated.
Best regards,
Dirk.]]>Dirk Bräuer2022-02-01T09:22:37-00:00[railML3.2] Cant Deficiency Class for RS and/or TT
https://www.railml.org/forum/index.php?t=rview&goto=2891&th=853#msg_2891
for use case ITMS there is the request to have "Cant Deficiency Class" in
rollingstock data. There is reference given to UNISIG Specification SUBSET-026-06.
When looking into chapter 6.5.1.5.34 NC_DIFF it becomes clear the resulting
Static Speed Profile (SSP) is what's needed. The definition of values for
NC_DIFF is the typical mixture of physical values and other conditions. Most of
the values for NC_DIFF are related to a specific value of cant deficiency in mm.
However, there are three values in-between referring to the brake position.
Question: Shall we model in railML the brake position and cant deficiency
separately or as a resulting integer like in UNISIG?
P.S: Be reminded that RS can only take (maximal) values of a train. But TT may
define deviating values/settings according to the needs of the specific run.
--
Best regards,
Joerg v. Lingen - Rollingstock Coordinator]]>Joerg von Lingen2022-01-30T12:46:33-00:00Re: [railML2] Re: Do we need a solution to declare the states of rolling stock?
https://www.railml.org/forum/index.php?t=rview&goto=2811&th=775#msg_2811
ticket #478 was created for the issue. A possible solution is included for
review in commits [1246] and [1247].
Basically the <state> element from infrastructure was re-used in rollingstock
for formation and vehicle. As a rule the information at formation shall
overwrite possible information in vehicle.
Best regards,
Joerg v. Lingen - Rollingstock Coordinator
On 18.08.2021 10:23, Carsten Weber wrote:
> Dear community,
> dear Torben,
>
> in my eyes your suggestion makes sense. Bound a data field like status to the
> vehicle so that you can check whether it is one current in use or it is only an
> idea or whatever. Maybe it should be checked before whether all entries of the
> infrastructure field could be taken one by one.
>
> Best regards.
>
> Carsten Weber
> Bahnberatung Carsten Weber]]>Joerg von Lingen2021-08-18T14:07:38-00:00[railML2] Re: Do we need a solution to declare the states of rolling stock?
https://www.railml.org/forum/index.php?t=rview&goto=2810&th=775#msg_2810
dear Torben,
in my eyes your suggestion makes sense. Bound a data field like status
to the vehicle so that you can check whether it is one current in use or
it is only an idea or whatever. Maybe it should be checked before
whether all entries of the infrastructure field could be taken one by one.
Best regards.
Carsten Weber
Bahnberatung Carsten Weber
In Zusammenarbeit mit
iRFP e.K.
Institut für Regional- und Fernverkehrsplanung
Hochschulstraße 45
01069 Dresden
Am 11.11.2020 um 10:57 schrieb Torben Brand:
> Dear railML-community,
>
> We have had a previous mishap where the wrong vehicle (and
> formation that is built on the vehicle) was used for runtime
> calculations. This as the same vehicle was in several
> versions in the same database/railML exchange file. The
> different versions were due to different states of the
> vehicle. In an early stage the vehicle was conceptual with
> "glossy marketing paper" values from the vendor. At a later
> stage the vehicle was planned and the values dropped/got
> more realistic. Finally, when the vehicle was in operation
> the values where investigated and found to be even lower.
> To mitigate this source of potential error and to transmit
> more information in railML should we consider adding a
> construct like <states> under infrastructure (example:
> https://wiki2.railml.org/wiki/IS:state) in rolling stock?
> Or do you suggest it's enough to demand from the user to
> transmit information outside railML of which correct vehicle
> to be used, to describe the vehicle further in the
> human-readable @description attribute or to purge the
> dataset transmitted on the desired state of vehicles (for
> instance only operational vehicles in data set)?
>
> What does the community think? Any feedback is highly
> appreciated.
>
> Kind regards
>
>
> Torben Brand
> Jernbanedirektoratet]]>Carsten Weber2021-08-18T08:23:59-00:00Distinguish between physical and operational
https://www.railml.org/forum/index.php?t=rview&goto=2618&th=784#msg_2618
rather often I have the impression that it is difficult to clearly distinguish
the use of data in railML.
As noted in post "[railML2] extend <formation> with the attribute @load" we have
some data, which are used in different context. In rollingstock we can define
only the physical characteristics of the formation or the vehicle. This data are
completely independent of the ones when using the formation/vehicle in train
operation. The structure of data may similar but the values may differ. See also
the attached table of non-exhaustive examples of such values.
--
Best regards,
Joerg v. Lingen - Rollingstock Coordinator]]>Joerg von Lingen2020-12-20T12:16:20-00:00Re: [railML2] extend <formation> with the attribute @load
https://www.railml.org/forum/index.php?t=rview&goto=2597&th=767#msg_2597
the @load attribute is a good example to stress again - in rollingstock always
the physical possible values are defined, in timetable the actual use or planned
use is defined. In the attached picture the first line shows the partially
loaded wagons - this is TT. The lower line shows the completely loaded wagons -
this is RS.
Best regards,
Joerg v. Lingen - Rollingstock Coordinator
Am 27.10.2020 um 21:41 schrieb Torben Brand:
> Dear railML-community,
>
> In the Norwegian railway sector we would like to use
> predefined formations for usage in the timetable. For this
> purpose we would also like to use formations with real
> referenced vehicle, but with virtual wagons and payload.
> This is possible today in railML2.4, but is cumbersome as
> you can only define the complete formations weight with
> payload with usage of formation@bruttoWeight. We would like
> to be able to define only the towed weight of the wagons and
> payload, excluding the locomotive. This in the same manner
> as possible in formationTT@load.
> ]]>Joerg von Lingen2020-11-22T11:37:25-00:00Re: [railML2] extend <formation> with the attribute @load
https://www.railml.org/forum/index.php?t=rview&goto=2583&th=767#msg_2583
I have submited the attribute for <formation> into the 2.5 development branch.
<xs:attribute name="load" type="rail:tWeightTons">
<xs:annotation>
<xs:documentation>weight without engine</xs:documentation>
</xs:annotation>
</xs:attribute>
In addition I will consider it for railML3 development.
--
Regards,
Jörg von Lingen - Rollingstock Coordinator
Torben Brand wrote on 11.11.2020 10:25:
> Dear Jörg,
>
> We thank you for your quick reply and for considering the
> suggested attribute in railML3.
> However the Norwegian sector would need the attribute
> already in railML2.5, else we have to make a national
> extension.
> ]]>Joerg von Lingen2020-11-12T04:57:34-00:00