| Freight yard services [message #3872] |
Fri, 16 January 2026 15:38 |
Torben Brand
Messages: 205
Registered: March 2016
|
Senior Member |
|
|
With reference to posting #3841 "ISO RailDax TSI Telematics (TAF/TAP) mapping"
Telematics LocationSubsidiaryTypeCode defines a type not available in railML3.3:
36 - Freight yard: A freight yard is commercial usage of a physical location which can be used as a sending or a destination station in freight orders of rail freight transports. The freight yard can have his own codification
37 - Loading point: A loading point is a commercial usage of a physical location. Each loading point is assigned to a yard.
57 - Intermodal Terminal: Intermodal Terminal is a location which provides the space, equipment and operational environment under which the transfer of loading units (freight containers, swap bodies, semi-trailers or trailers) takes place
60 - Multifunctional rail terminal: Facilities for conventional and/or intermodal rail/road transshipment principally open for public use and for all types of cargo. This kind of facility does not only provide transshipment, but also additional services like storage, consignment or road pre/end haulage. Physical part of Primary Location.
Does anybody have a UC requirement for freight services provided in an operational points with trafficType="freight"?
In railML 2.5 there are services in general as a sub element under operational point [1] that have not been transferred to railML3 (in lack of a UC) that would be relevant here. Maybee remodelling these is the simplest approach?
Attributes relevant for freight terminals would be:
- goodsLoading: if true, the ocp is capable of loading / unloading goods on trains
- goodsSiding: if true, the ocp has a siding for exchanging goods
- goodsIntermodal: if true, the ocp offers intermodal goods exchange, e. g. transfering trucks on trains
- goodsMarshalling: if true, the ocp offers marshalling services (e. g. composing freight trains)
These would also more or less map well to the values listed for TSI Telematics, above.
This would be a macroscopic model. You could also modell mesiscopic with existing railML3 modelling with use of a child OP (with the freigt properties mentioned above) with reference to a parent OP.
Alternative we could model the properties on a microscoipic/track level with new properties of <serviceSection>.
I would suggest to implement the simpler macro modelling for now, and if there is a requirement by the community in the future to add the micro details in the service section.
[1] https://wiki2.railml.org/wiki/IS:propService
|
|
|
|
Members
Search
Help
Login
Home
