Home » railML newsgroups » railml.infrastructure » Infrastructure semantics
| Infrastructure semantics [message #248] |
Fri, 06 May 2011 11:33  |
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 ==----
|
|
|
|
|
|
|
|
| Language-sensitive names [message #252 is a reply to message #249] |
Thu, 12 May 2011 11:15  |
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 #254 is a reply to message #253] |
Thu, 12 May 2011 23:11 |
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 |
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 ==----
|
|
|
|
|
|
|
|
| Re: Ocp Timezones [message #260 is a reply to message #259] |
Mon, 16 May 2011 21:34 |
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 |
Joerg von Lingen
Messages: 147
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 |
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 |
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 |
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 |
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 ==----
|
|
|
|
Goto Forum:
Current Time: Tue Mar 21 14:42:30 CET 2023
|
Members
Search
Help
Login
Home
