Home » railML newsgroups » railML.infrastructure » Infrastructure semantics
Infrastructure semantics [message #248] Fri, 06 May 2011 11:33 Go to next message
tuomas.tiihonen is currently offline  tuomas.tiihonen
Messages: 15
Registered: May 2011
Junior Member
Hi,

I would appreciate some infrastructure semantics explanations.

Are the translations only supported in OCP (in additionalName)?
Is there possibility to define language code for OCP's default name?
Is there possibility to give timezone for OCP?
Is there possibility to define OCP (if it is a station) to have platforms
and those platforms different segments?
How about side of a platform in relation to train?
Could OCP have different heads (heads could be used for resolving
orientation of the train in relation to stop)? So that line would link
from ocpA head1 to ocpB head2.
Is the OCP->number unique?
How to get distance between OCPs, is it with trackend/trackbegin->pos?
What is the relation of pos to ocpTT->SectionTT->distance in timetable?

Kindest Regards,
Tuomas Tiihonen


--
----== posted via PHP Headliner ==----
Re: Infrastructure semantics [message #249 is a reply to message #248] Mon, 09 May 2011 16:31 Go to previous messageGo to next message
coordination is currently offline  coordination
Messages: 11
Registered: May 2011
Junior Member
Dear Mr. Tiihonen,

Thank you for your enquiries to RailML.infrastructure.

Tuomas Tiihonen wrote:
> I would appreciate some infrastructure semantics explanations.

On behalf of the infrastructure coordinator I will try to answer some of
your questions from the today’s coordinators meeting:

> Are the translations only supported in OCP (in additionalName)?
> Is there possibility to define language code for OCP's default name?

We added a ticket in our SVN (http://trac2.assembla.com/railML/ticket/121)
and will integrate additional names and language codes on short notice in
RailML's version 2.1.

> Is there possibility to give timezone for OCP?

We added a ticket in our SVN (http://trac2.assembla.com/railML/ticket/120)
and will integrate time zones on short notice in RailML's version 2.1.

> Is there possibility to define OCP (if it is a station) to have platforms
> and those platforms different segments?

We added a ticket in our SVN (http://trac2.assembla.com/railML/ticket/122)
and had an intense discussion about this. To avoid an incompatible
extension of RailML due to the wide range of facilities beside a track,
we’re not sure, if we shall implement this request into RailML’s
version 2.1. We will see the discussion and remarks of the users within
the next weeks.

> How about side of a platform in relation to train?

The platforms are defined with their properties (e.g. with platformsides)
in RailML.infrastructure, the platform of a train’s stop will be defined
in RailML.timetable. The reading programme may combine this information
and generate an announcement “Please exit the train on the left hand
side.”.

> Could OCP have different heads (heads could be used for resolving
> orientation of the train in relation to stop)? So that line would link
> from ocpA head1 to ocpB head2.

Would you be so kind to specify this question?

> Is the OCP->number unique?

No. Please do not use this value anymore, because it's deprecated. You may
use OCP->code instead of this.

Best regards,

Dipl.-Ing. Vasco Paul Kolmorgen
RailML-group – Coordinator
Telephone: +49-351-46676939
Zeunerstrasse 1; D-01069 Dresden www.railml.org

--
----== posted via PHP Headliner ==----
Re: Infrastructure semantics [message #251 is a reply to message #249] Tue, 10 May 2011 09:03 Go to previous messageGo to next message
tuomas.tiihonen is currently offline  tuomas.tiihonen
Messages: 15
Registered: May 2011
Junior Member
>> Could OCP have different heads (heads could be used for resolving
>> orientation of the train in relation to stop)? So that line would link
>> from ocpA head1 to ocpB head2.
>
> Would you be so kind to specify this question?

If two OCPs are linked together how can you know which side of the OCP the
train enters the OCP?

I will try to illustrate:

Track: "="
Station OCP: /////OCP////
H1 = Head1
H2 = Head 2
=========H1/////////OCP1/////////H2=============H1//////OCP2 /////H2===========(this
connects back to OCP1/H1)

Now if I make connection from OCP1 to OCP2 the connection would know that
it starts from OCP1->Head2 and ends at OCP2->Head1. This way the data
tells the exact orientation of the train when it arrives from OCP1 to
OCP2. But I could also make connection from OCP1 head1 to OCP2 head2 and
again I know which side of the OCP the train comes from (if illustrated,
this example would make loop).

If in other hand you do not specify whether the train comes from head 1
side or head 2 side you can't know the orientation of the train in
relation to the stop. In essence when you make connection between two OCP
it can be interpreted as the train would arrive the station from two
different sides and you can't know which.

I use term "connection" loosely here as I am not quite sure what is the
correct term in RailML in this context.


--
----== posted via PHP Headliner ==----
Language-sensitive names [message #252 is a reply to message #249] Thu, 12 May 2011 11:15 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
coordination(at)railmlorg (Vasco Paul Kolmorgen) writes:

Hello Tuomas (and others interested in this thread),

>> Are the translations only supported in OCP (in additionalName)?
>> Is there possibility to define language code for OCP's default name?
>
> We added a ticket in our SVN (http://trac2.assembla.com/railML/ticket/121)
> and will integrate additional names and language codes on short notice in
> RailML's version 2.1.

I commited this change according to mentioned ticket.

All elements with id/code/name/description will include the optional
xml:lang attribute for defining the defaults language code.

All theses elements offer the optional element "additionalName" for
defining further names/descriptions with its language codes.

Current ocp element "ocp/propOther/additionalName" is marked
"deprecated" for better using above mentioned structure starting with
railML 2.1.

Is there any need for attribute "type" in "additionalName"? Or is there
any other attribute which is needed in addition to the now provided
ones.

Please, checkout/download current development version and check, if it
works for your needs.

Thank you for revising and improving railML.

Kind regard...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: Language-sensitive names [message #253 is a reply to message #252] Thu, 12 May 2011 14:55 Go to previous messageGo to next message
tuomas.tiihonen is currently offline  tuomas.tiihonen
Messages: 15
Registered: May 2011
Junior Member
Hi,

Looks good to me, however I wonder why the lang does not follow "ISO
639-1" anymore. If I understand correctly it now uses basically IETF BCP
47. Does someone know if ISO 639-1 has some language mapped differently
than in IETF BCP 47? If those are different, it can cause problems, at
least changes in the software if extra mapping is needed between the two
language standards.

Br,
Tuomas

Susanne Wunsch wrote:
>
> coordination(at)railmlorg (Vasco Paul Kolmorgen) writes:
>
> Hello Tuomas (and others interested in this thread),
>
>>> Are the translations only supported in OCP (in additionalName)?
>>> Is there possibility to define language code for OCP's default name?
>>
>> We added a ticket in our SVN (http://trac2.assembla.com/railML/ticket/121)
>> and will integrate additional names and language codes on short notice in
>> RailML's version 2.1.
>
> I commited this change according to mentioned ticket.
>
> All elements with id/code/name/description will include the optional
> xml:lang attribute for defining the defaults language code.
>
> All theses elements offer the optional element "additionalName" for
> defining further names/descriptions with its language codes.
>
> Current ocp element "ocp/propOther/additionalName" is marked
> "deprecated" for better using above mentioned structure starting with
> railML 2.1.
>
> Is there any need for attribute "type" in "additionalName"? Or is there
> any other attribute which is needed in addition to the now provided
> ones.
>
> Please, checkout/download current development version and check, if it
> works for your needs.
>
> Thank you for revising and improving railML.
>
> Kind regard...
> Susanne
>



--
----== posted via PHP Headliner ==----
Re: Language-sensitive names [message #254 is a reply to message #253] Thu, 12 May 2011 23:11 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Hi Tuomas,

thanks for your quick followup.

tuomastiihonen(at)mitroncom (Tuomas Tiihonen) writes:

> Looks good to me, however I wonder why the lang does not follow "ISO
> 639-1" anymore. If I understand correctly it now uses basically IETF BCP
> 47. Does someone know if ISO 639-1 has some language mapped differently
> than in IETF BCP 47? If those are different, it can cause problems, at
> least changes in the software if extra mapping is needed between the two
> language standards.

That's "old" XML style.

ISO 639-1 defines the alpha-2 language code. There are already another
alpha-3 language codes defined in ISO639-2. IETF BSP 47 mostly recycles
ISO 639-1 codes. For mapping hints see:

http://en.wikipedia.org/wiki/IETF_language_tag
("Relation to other standards")

639-1 639-2 IETF

German: 'de' 'ger' 'de', 'de-AT', 'de-CH', 'de-DE'
English: 'en' 'eng' 'en', 'en-US', 'en-GB'
Finnish: 'fi' 'fin' 'fi', 'fi-FI', 'fi-SE'
Swedish: 'sv' 'swe' 'sv', 'sv-SE', 'sv-FI'
N. Sami: 'se' 'sme' 'se'

Sorry for the disappointing answer.

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: Language-sensitive names [message #255 is a reply to message #254] Fri, 13 May 2011 07:49 Go to previous messageGo to next message
tuomas.tiihonen is currently offline  tuomas.tiihonen
Messages: 15
Registered: May 2011
Junior Member
Hi Susanne,

thanks for the reply and the link. Yes, perhaps little disappointment, but
not impossible one to overcome ;)


Br,
Tuomas


> That's "old" XML style.
>
> ISO 639-1 defines the alpha-2 language code. There are already another
> alpha-3 language codes defined in ISO639-2. IETF BSP 47 mostly recycles
> ISO 639-1 codes. For mapping hints see:
>
> http://en.wikipedia.org/wiki/IETF_language_tag
> ("Relation to other standards")
>
> 639-1 639-2 IETF
>
> German: 'de' 'ger' 'de', 'de-AT', 'de-CH', 'de-DE'
> English: 'en' 'eng' 'en', 'en-US', 'en-GB'
> Finnish: 'fi' 'fin' 'fi', 'fi-FI', 'fi-SE'
> Swedish: 'sv' 'swe' 'sv', 'sv-SE', 'sv-FI'
> N. Sami: 'se' 'sme' 'se'
>
> Sorry for the disappointing answer.
>
> Kind regards...
> Susanne
>



--
----== posted via PHP Headliner ==----
Ocp Timezones [message #258 is a reply to message #249] Mon, 16 May 2011 09:24 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Hello Tuomas,
hello railML-Community,

>> Is there possibility to give timezone for OCP?
>
> We added a ticket in our SVN (http://trac2.assembla.com/railML/ticket/120)
> and will integrate time zones on short notice in RailML's version 2.1.
>

I implemented a new attribute "timezone" within the ocp's datatype
<tOperationControlPoint>. It has an enumerator type <tOcpTimeZone>,
which contains all the various timezones on earth based on UTC and the
offset. The values range from "utc-12" via "utc+0" to "utc+14". Some
timezones differ from others by fractions of hours, e.g. "utc-9.30".

Time changes that are only temporarily, e.g. daylight saving time, are
not considered in this list and shall not be used in the infrastructure
schema.

See the changes in http://trac2.assembla.com/railML/changeset/390
Comments and questions on this topic are always appreciated.

Best regards
Christian

---
Christian Rahmig
railML.infrastructure coordinator
Re: Ocp Timezones [message #259 is a reply to message #258] Mon, 16 May 2011 14:58 Go to previous messageGo to next message
tuomas.tiihonen is currently offline  tuomas.tiihonen
Messages: 15
Registered: May 2011
Junior Member
Hi Christian,

Great to see that my comments were quickly adapted! Thanks!

> Time changes that are only temporarily, e.g. daylight saving time, are
> not considered in this list and shall not be used in the infrastructure
> schema.

Could there be some solution for daylight saving time implemented? One
option would be boolean like "OCPinDaylightSavingArea", or what would be
the preferred way to know if OCP obeys daylight saving time or not?
Comments, please.




--
----== posted via PHP Headliner ==----
Re: Ocp Timezones [message #260 is a reply to message #259] Mon, 16 May 2011 21:34 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Hello Tuomas,

>> Time changes that are only temporarily, e.g. daylight saving time, are
>> not considered in this list and shall not be used in the infrastructure
>> schema.
>
> Could there be some solution for daylight saving time implemented? One
> option would be boolean like "OCPinDaylightSavingArea", or what would be
> the preferred way to know if OCP obeys daylight saving time or not?
> Comments, please.

That is a difficult question. In my understanding the daylight saving
time resp. the boolean you suggested is a changing parameter and not
fixed like the timezone information of an ocp. Therefore, I would not
consider it within the infrastructure schema, but somewhere in the
timetable schema, since it is relevant for operation and depends on the
current date/time.

However, I want to hear Joachim's opinion on this first before
implementing it.

Best regards
Christian

---
Christian Rahmig
railML.infrastructure coordinator
Re: Ocp Timezones [message #261 is a reply to message #260] Tue, 17 May 2011 07:07 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 148
Registered: May 2011
Senior Member
Hi everybody,

although it is not relevant for rolling stock I would add some thoughts on daylight saving time.

1) A simple flag (boolean) can only be used in timetable as it has a meaning only in relation to a
certain date.

2) The information is a "feature" of an ocp, however, it has to be much more detailed in order to be
valid in general for an infrastructure item independent of any date. Subsequently it would require
to name start and end date/time of the daylight saving period for each year as this may be subject
to changes.
But do we really need that information?

Regards,
Jörg.

Christian Rahmig wrote:
> Hello Tuomas,
>
>>> Time changes that are only temporarily, e.g. daylight saving time, are
>>> not considered in this list and shall not be used in the infrastructure
>>> schema.
>>
>> Could there be some solution for daylight saving time implemented? One
>> option would be boolean like "OCPinDaylightSavingArea", or what would be
>> the preferred way to know if OCP obeys daylight saving time or not?
>> Comments, please.
>
> That is a difficult question. In my understanding the daylight saving time resp. the boolean you
> suggested is a changing parameter and not fixed like the timezone information of an ocp. Therefore,
> I would not consider it within the infrastructure schema, but somewhere in the timetable schema,
> since it is relevant for operation and depends on the current date/time.
>
> However, I want to hear Joachim's opinion on this first before implementing it.
>
> Best regards
> Christian
>
> ---
> Christian Rahmig
> railML.infrastructure coordinator
Re: Ocp Timezones [message #263 is a reply to message #261] Wed, 18 May 2011 09:43 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Hi,

Joerg von Lingen <coord(at)rollingstockrailmlorg> writes:

> 1) A simple flag (boolean) can only be used in timetable as it has a
> meaning only in relation to a certain date.

I would interprete the flag as "the ocp is located in an area, where
daylight saving is used". This is an geographical feature which is
independent from actual date and time.

It is a very political issue wether DST is used or not. Countries' time
offset to UTC do also change by some reasons.

> 2) The information is a "feature" of an ocp, however, it has to be
> much more detailed in order to be valid in general for an
> infrastructure item independent of any date. Subsequently it would
> require to name start and end date/time of the daylight saving period
> for each year as this may be subject to changes.

These data are already collected and active maintained in the "tz
database". [1] It also hosts the history of time zone/DST regulations
for each region.

> But do we really need that information?

We already offer time zone dependent date and time tags in "timetable"
subschema.

You could fill the timetable with UTC values and the software transforms
it to the actual time according to the regional time zone specified in
ocp.

I think it's a proper enhancement which is worth implementing as
flexible and reliable as possible.

How about the W3C Guideline for "Working with time zones"? [2]

I hope it helps...
Susanne

[1] http://en.wikipedia.org/wiki/Tz_database
[2] http://www.w3.org/International/wiki/WorkingWithTimeZones

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: Ocp Timezones [message #264 is a reply to message #261] Wed, 18 May 2011 09:50 Go to previous messageGo to next message
tuomas.tiihonen is currently offline  tuomas.tiihonen
Messages: 15
Registered: May 2011
Junior Member
Hi,

good comments.

In our implementation timezone is specified like "Europe/Vienna", from
this it is possible to determine the rules of daylight saving time (of
course you would have to know the rules for Vienna).

If we define the timezone wit +2/-2 and so on, we can't interpret if there
is daylight saving time in use or not.

Of course if OCP would know the area where it stands, the interpretation
can be made. However I am not sure what is the semantically correct place
to but location information as the location information should be in
similar format as in timezone definitions (usually capital city). Now if I
consider OCP->area that is not quite suitable for this.. (A <area>
specifies the region, an operation control point is responsible for. )

1) I could use ocp->area anyway
2) OCP->timezone could have also optional field to define timezone like
"Europe/Vienna"
3) or the idea Joerg introduced
4) Or I will just not consider daylight in relation to OCP


Br,
Tuomas


Joerg von Lingen wrote:
>
> Hi everybody,
>
> although it is not relevant for rolling stock I would add some thoughts on
daylight saving time.
>
> 1) A simple flag (boolean) can only be used in timetable as it has a meaning
only in relation to a
> certain date.
>
> 2) The information is a "feature" of an ocp, however, it has to be much more
detailed in order to be
> valid in general for an infrastructure item independent of any date.
Subsequently it would require
> to name start and end date/time of the daylight saving period for each year
as this may be subject
> to changes.
> But do we really need that information?
>
> Regards,
> J�rg.
>
> Christian Rahmig wrote:
>> Hello Tuomas,
>>
>>>> Time changes that are only temporarily, e.g. daylight saving time, are
>>>> not considered in this list and shall not be used in the infrastructure
>>>> schema.
>>>
>>> Could there be some solution for daylight saving time implemented? One
>>> option would be boolean like "OCPinDaylightSavingArea", or what would be
>>> the preferred way to know if OCP obeys daylight saving time or not?
>>> Comments, please.
>>
>> That is a difficult question. In my understanding the daylight saving time
resp. the boolean you
>> suggested is a changing parameter and not fixed like the timezone
information of an ocp. Therefore,
>> I would not consider it within the infrastructure schema, but somewhere in
the timetable schema,
>> since it is relevant for operation and depends on the current date/time.
>>
>> However, I want to hear Joachim's opinion on this first before
implementing it.
>>
>> Best regards
>> Christian
>>
>> ---
>> Christian Rahmig
>> railML.infrastructure coordinator
>
>
>



--
----== posted via PHP Headliner ==----
Re: Ocp Timezones [message #265 is a reply to message #263] Sat, 21 May 2011 12:44 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Hello Tuomas (and everybody),

>> 2) The information is a "feature" of an ocp, however, it has to be
>> much more detailed in order to be valid in general for an
>> infrastructure item independent of any date. Subsequently it would
>> require to name start and end date/time of the daylight saving period
>> for each year as this may be subject to changes.
>
> These data are already collected and active maintained in the "tz
> database". [1] It also hosts the history of time zone/DST regulations
> for each region.

Regarding your comments I changed the timezone definition in
http://trac2.assembla.com/railML/changeset/394

Now, the tz database (Olson database) defines the format of the timezone
attribute, which is a simple string.
The entry, e.g. "Europe/Paris" or "America/New_York", does not refer to
a special UTC time offset, but a location. Thus, it is possible to
consider temporary time changes like DST within the timezone attribute
implicitly.

Best regards
Christian

> [1] http://en.wikipedia.org/wiki/Tz_database

---
Christian Rahmig
railML.infrastructure coordinator
Re: Ocp Timezones [message #266 is a reply to message #265] Mon, 23 May 2011 07:40 Go to previous message
tuomas.tiihonen is currently offline  tuomas.tiihonen
Messages: 15
Registered: May 2011
Junior Member
Hi Christian,

This sounds great, thank you!

Br,
Tuomas

> Regarding your comments I changed the timezone definition in
> http://trac2.assembla.com/railML/changeset/394
>
> Now, the tz database (Olson database) defines the format of the timezone
> attribute, which is a simple string.
> The entry, e.g. "Europe/Paris" or "America/New_York", does not refer to
> a special UTC time offset, but a location. Thus, it is possible to
> consider temporary time changes like DST within the timezone attribute
> implicitly.
>
> Best regards
> Christian
>
>> [1] http://en.wikipedia.org/wiki/Tz_database
>




--
----== posted via PHP Headliner ==----
Previous Topic: Change of infrastructure coordinator
Next Topic: "default" attribute raises implementation problems
Goto Forum:
  


Current Time: Thu Mar 28 11:01:07 CET 2024