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: 212
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 message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 212
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.
Previous Topic: RailML-compliant?
Next Topic: need for new attribute "virtual" of trainDetector
Goto Forum:
  


Current Time: Thu Jun 29 00:45:12 CEST 2017