| Datatype for distance in sectionTT [message #764] |
Mon, 26 March 2012 12:27  |
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 #768 is a reply to message #765] |
Mon, 26 March 2012 22:22  |
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 |
Dirk Bräuer
Messages: 313
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 #844 is a reply to message #773] |
Tue, 06 November 2012 15:19 |
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 ==----
|
|
|
|
Members
Search
Help
Login
Home
