Home » railML newsgroups » railML.infrastructure » Line category according to EN 15528
Line category according to EN 15528 [message #1250] Mon, 01 June 2015 11:38 Go to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear railML community,

with railML 2.3 we also want to implement line categories as defined in
EN 15528. Therefore we set up the Trac ticket [1] including the following:

The European standard EN 15528 defines line categories depending on the
maximum allowed meter load and axle load. The following entries are
possible:
* A
* B1
* B2
* C2
* C3
* C4
* D2
* D3
* D4
* D4xL
* E4
* E5

Any comments on this approach, which has been initially implemented with
revision 621 (see [2]), are welcome.

[1] https://trac.railml.org/ticket/259
[2] https://trac.railml.org/changeset/621/railML

Best regards
Christian

--
Christian Rahmig
railML.infrastructure coordinator
Re: Line category according to EN 15528 [message #1251 is a reply to message #1250] Fri, 24 July 2015 18:02 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Christian,

> Any comments on this approach ... are welcome.

Well, then pleas welcome my comments:

During earlier discussions on this "approach" we came to the conclusion
better to handle "physical" values behind these rather "political"
classes in railML. This means: Rather use "maxAxleLoad" and
"maxMeterLoad" or "maxSpecificLoad".

The reasons were:
There are more local (country-specific) line classes than in EN15528
which means that the enumeration from EN will not fulfil many practical
demands. How should we classify a German line of CE or CM2..4 when only
the EN15528 are allowed? And from the other way 'round: If we allow
country-specific classes as CE, how should one compare or convert it
with the other values? This would only be possible by "understanding"
the physical background (axleload, meterload a.s.o.), therefore we
should always name this background.

There are also many examples where the classes do not fit the actual
physical values (you could say, from a technical point of view, the line
is wrongly classified - but the classification is political... For
instance, the German line 6686/6709 is classified D4 but has apparently
a load spread of less then 6 tons per meter.). So you cannot decide
whether a certain vehicle or train can use the line if you only know the
classification but not the actual physical values.

---
I personally think that this earlier conclusion is still reasonable and
therefore would still prefer the physical values such as "maxAxleLoad"
and "maxMeterLoad" or "maxSpecificLoad".

Best regards,
Dirk.


---
Am 01.06.2015 um 11:38 schrieb Christian Rahmig:
> Dear railML community,
>
> with railML 2.3 we also want to implement line categories as defined in
> EN 15528. Therefore we set up the Trac ticket [1] including the following:
>
> The European standard EN 15528 defines line categories depending on the
> maximum allowed meter load and axle load. The following entries are
> possible:
> * A
> * B1
> * B2
> * C2
> * C3
> * C4
> * D2
> * D3
> * D4
> * D4xL
> * E4
> * E5
>
> Any comments on this approach, which has been initially implemented with
> revision 621 (see [2]), are welcome.
>
> [1] https://trac.railml.org/ticket/259
> [2] https://trac.railml.org/changeset/621/railML
>
> Best regards
> Christian
>
Re: Line category according to EN 15528 [message #1252 is a reply to message #1251] Mon, 31 August 2015 11:18 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear Dirk,

thank you very much for your feedback. I'll comment on it below:

Am 24.07.2015 um 18:02 schrieb Dirk Bräuer:
> [...]
>
> During earlier discussions on this "approach" we came to the conclusion
> better to handle "physical" values behind these rather "political"
> classes in railML. This means: Rather use "maxAxleLoad" and
> "maxMeterLoad" or "maxSpecificLoad".
>
> The reasons were:
> There are more local (country-specific) line classes than in EN15528
> which means that the enumeration from EN will not fulfil many practical
> demands. How should we classify a German line of CE or CM2..4 when only
> the EN15528 are allowed? And from the other way 'round: If we allow
> country-specific classes as CE, how should one compare or convert it
> with the other values? This would only be possible by "understanding"
> the physical background (axleload, meterload a.s.o.), therefore we
> should always name this background.
>
> There are also many examples where the classes do not fit the actual
> physical values (you could say, from a technical point of view, the line
> is wrongly classified - but the classification is political... For
> instance, the German line 6686/6709 is classified D4 but has apparently
> a load spread of less then 6 tons per meter.). So you cannot decide
> whether a certain vehicle or train can use the line if you only know the
> classification but not the actual physical values.
>
> ---
> I personally think that this earlier conclusion is still reasonable and
> therefore would still prefer the physical values such as "maxAxleLoad"
> and "maxMeterLoad" or "maxSpecificLoad".
>
> Best regards,
> Dirk.
>
> [...]

I agree with the conclusion reached after previous discussions: it makes
more sense to explicitly define the physical values of a line or track
and to derive a track or line category from it. It is also clear, that
there are national categories that differ from the international ones
and that you may have different categories for the same railway segment.
Further, I also agree with you that some category decisions are only
politically motivated and differ from reality. However, since political
decisions can be very relevant for railway operation, we should not
forget about such aspects - and if required include them in our schema.

So, for railML modeling I suggest the following:
If you are interested in the physical parameters of your line / track,
please use the more detailed and more specific parameters. As you
correctly mentioned, in most cases the line category can be "derived"
from these values. But if you only have the information about the line
category, deriving the physical values from it may cause errors i.e. for
political motivated category decisions. In this case, I suggest to use
the line category parameter.

Summary: Keep both options. Use the more detailed modeling where available.

Any further comments are still welcome.

Best regards
Christian

--
Christian Rahmig
railML.infrastructure coordinator
Re: Line category according to EN 15528 [message #1254 is a reply to message #1252] Wed, 16 September 2015 12:19 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Christian and all others,

Am 31.08.2015 um 11:18 schrieb Christian Rahmig:
>
> So, for railML modeling I suggest the following:
> If you are interested in the physical parameters of your line / track,
> please use the more detailed and more specific parameters. As you
> correctly mentioned, in most cases the line category can be "derived"
> from these values. But if you only have the information about the line
> category, deriving the physical values from it may cause errors i.e. for
> political motivated category decisions. In this case, I suggest to use
> the line category parameter.
>
> Summary: Keep both options. Use the more detailed modeling where available.

I think the conclusion is acceptable. We should then draw another
conclusion NOT to limit the category class enumeration to the values of
EN15528 to allow country-specific values as CE or CM2.

As you wrote, the category classes are rather ‘political’, so no need to
avoid the country-specific values. As shown above, one cannot draw a
‘hard’, ‘automatic’ technical conclusion (concerning acceptance of
certain vehicles) from a line’s classification, so the country-specific
should do no further harm.

Best regards,
Dirk.
Line category in Norway [message #1674 is a reply to message #1252] Wed, 29 November 2017 09:29 Go to previous message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
I have been asked by Christian Rahmig to produce the enumeration list for the Norwegian line categories for railML3. As also previously stated in this topic. We have a separate list from the international list according to European standard EN 15528. Although it bases itself strongly on the international values. We have a category c+, which is not in the international list. Also we have variations of the axle load within a category based on the maximum allowed speed. Thus I agree with the previous request from Dirk to also optionally map the specific attributes: "maxAxleLoad" and "maxMeterLoad". I would also suggest a value "maxSpeedLoad". Additionally we should be able to define one or more defined enumeration list (international/national). Furthermore I think the element is to global as placed on the line level. The Norwegian term for line category "overbyggingsklasse" translates to "superstructure class". I think this more specific. Also the superstructure class/ line category can be different within a line. For instance siding tracks are usually of a lower quality. Our asset database (Banedata) defines the superstructure class (line category) on track level. Nevertheless we also group the superstructure class/ line category on a line level in Network statement (http://orv.jbv.no/ns/doku.php?id=vedlegg:aksellast)

Our Norwegian values are:

Name of Norwegian list: "Overbygningsklasser"
Suggestion for univocal enumeration UUID: "NO:TRV-530-4-2"
https://trv.jbv.no/wiki/Overbygning/Prosjektering/Generelle_ tekniske_krav
List values:
a
b
c
c+
d
Ofotbanen

[Updated on: Wed, 29 November 2017 09:31]

Report message to a moderator

Previous Topic: How to model speed restrictions for ETCS train categories based on axle load
Next Topic: [railML3]: openend and Macroscopic nodes
Goto Forum:
  


Current Time: Thu Mar 28 13:24:32 CET 2024