Home » railML newsgroups » railml.timetable » Datatype for distance in sectionTT
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 previous 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.
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Difference between 'Train coupling & sharing' and 'scope'
Next Topic: Sequence of ocpTT elements
Goto Forum:
  


Current Time: Thu May 02 21:57:32 CEST 2024