Home » railML newsgroups » railml.timetable » Datatype for distance in sectionTT
Datatype for distance in sectionTT [message #764] Mon, 26 March 2012 12:27 Go to next message
Christoph.Jobmann is currently offline  Christoph.Jobmann
Messages: 12
Registered: October 2010
Junior Member
Hello everyone,

during recent discussions it was noted that the attribute "distance" of
the element "sectionTT" is interpreted as length in km, at least it looks
this way in the examples.
Yet the schema defines its type as "tLengthM" instead of "tLengthKM".

I would appreciate if there was clarification whether the error lies
within the examples or within the schema.

Kind regards
Christoph Jobmann

--
----== posted via PHP Headliner ==----
Re: Datatype for distance in sectionTT [message #765 is a reply to message #764] Mon, 26 March 2012 11:29 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Hallo Christoph and all other,

this is a known problem since a long time. I do not know the origins
anymore but we already had discussions about it some years ago. I guess
some of the reasons may be that, the decimal separator in XML and
Switzerland is the thousand separator in Germany (a dot), and there are 6
(!) fraction digits allowed in this unit which really does not make sense
if it is meters...

At the moment, we (iRFP) take part at the confusion by writing km into our
RailML files and so we violate the XSD. (We write "distance='0.460'" which
shall mean 460 meters and not 460 kilometers.)

However, we cannot change it back in time for RailML 2.0 but we still can
change it in RailML 2.1 (which is shortly before release here) and we
surely will change it in 2.2. So, I would prefer to write meters
("distance='460'" in the example above) and this is my recommendation.
This would mean not to change the XSD but to change the examples and FBS
output.

If all the others agree (and this means especially the companies reading
FBS RailML output), we will do so from our 2.1 release but we will never
change our 2.0 output.

Sorry for my contingent of this confusion...

Best regards,
Dirk.
Re: Datatype for distance in sectionTT [message #768 is a reply to message #765] Mon, 26 March 2012 22:22 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Hello Dirk, Christoph and others interested,

Dirk Bräuer <dirkbraeuer(at)irfpde> writes:

> this is a known problem since a long time. I do not know the origins
> anymore but we already had discussions about it some years ago.

+1

> So, I would prefer to write meters ("distance='460'" in the example
> above) and this is my recommendation. This would mean not to change
> the XSD but to change the examples and FBS output.

That would be easier for us maintaining the schemas. But is it helpful
for the export and import interfaces?

I thought that the distance between two 'ocp's should be in kilometers
as well. If we look into the new rostering sub-schema we introduced the
attribute 'runLength' in the element 'blockPart'. It should be given in
kilometers.

We should harmonize both values, either the sectionTT or the blockPart
attribute.

BTW all infrastructure length values are expected in meters. That may be
a cause for this "old" attribute.

....just my 2 cents

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: Datatype for distance in sectionTT [message #773 is a reply to message #768] Fri, 30 March 2012 12:50 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Hello to all,

with my statement

> but we will never change our 2.0 output

I did not want to force any additional work at other software companies.
Of course we can change our 2.0 output but with a different dc:identifier
(see Header information, Dublin Core Metadata Element Set) only. So there
would be two different kinds of 2.0 output of FBS. If someone wants to
implement such a 2.0 please contact us.

On the other hand there seams to be no other 2.0 files at the moment and
no import interface which cannot handle the distances in kilometers. So
there seams to be no reason to change anything in 2.0.

> That would be easier for us maintaining the schemas. But is it helpful
> for the export and import interfaces?

I have the agreement of PTV to
- keep importing kilometers in 2.0
- accept meters from 2.1

There are several other interfaces (companies, software) dealing with our
2.0 output. But due to the (sadly) happenings on station identification
(abbreviation, code, number...) I think that none of them can handle 2.1
without any change in programming. And if there has to be a change in
programming at all, it should be a little work to change the kilometers in
meters.

This is my opinion, and so I would prefer this solution and it is also ok
for PTV. Anyway, we have to decide it very soon. SO PLEASE ANY OF THE
OTHER SOFTWARE COMPANIES PLEASE READ THIS AND WRITE WHETHER IT IS OK FOR
YOU OR NOT... ;-)

> I thought that the distance between two 'ocp's should be in kilometers
> as well.

> BTW all infrastructure length values are expected in meters.

I have a strong preference on not using floating point (non-integer)
values at all. Of course, in XML everything is string so even the values
with decimal separator in RailML could be assumed to be fixed-pointed. But
a decimal value in RailML could mislead to put in into a float-point value
in programming. This should be be avoided in any case. So let's skip that
unnecessary decimal separator! It only makes the RailML file unnecessary
longer...

It's ok to have all IS length values in meters. Let's do so in TT.

Dirk.
Re: Datatype for distance in sectionTT [message #842 is a reply to message #773] Tue, 06 November 2012 11:06 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
> It's ok to have all IS length values in meters. Let's do so in TT.

I filed a Trac ticket for this issue (for next major release):

https://trac.assembla.com/railML/ticket/179

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: Datatype for distance in sectionTT [message #844 is a reply to message #773] Tue, 06 November 2012 15:19 Go to previous message
Joachim Rubröder railML is currently offline  Joachim Rubröder railML
Messages: 0
Registered: November 2019
Hello to all,

Dirk wrote:
> I have the agreement of PTV to
> - keep importing kilometers in 2.0
> - accept meters from 2.1

I agree, the field 'distance' is implemented as length in [m] and
documented in the same way. Therefore ony the examples are wrong and
misleading.

I'll change them: http://trac.assembla.com/railML/ticket/180

If certain exporting and importing Programs agreed to use the field
'distance' with [km] it's fine for them. For a new implementation within a
future version 2.2, the field should be used with [m].

Kind regards,

Joachim


--
----== posted via PHP Headliner ==----
Previous Topic: Difference between 'Train coupling & sharing' and 'scope'
Next Topic: Sequence of ocpTT elements
Goto Forum:
  


Current Time: Fri Mar 29 00:13:15 CET 2024