Home » railML newsgroups » railML.infrastructure » Fwd: Mapping of code and abbreviation for ocps
| Fwd: Mapping of code and abbreviation for ocps [message #246] |
Thu, 17 March 2011 13:19  |
Simon Heller
Messages: 6
Registered: March 2011
|
Junior Member |
|
|
.... I accidently posted this infrastructure message in the timetable forum.
Simon Heller
IVU Traffic Technologies AG
Bundesallee 88, D-12161 Berlin
Telefon: +49.30.8 59 06-343
mailto:sih(at)ivude, http://www.ivu.de
---- Weitergeleitete Usenet-Nachricht ----
Von: "Simon Heller" <sih(at)ivude>
Newsgroups: railML.timetable
Betreff: Mapping of code and abbreviation for ocps
Datum: Thu, 17 Mar 2011 11:03:40 +0100
URL: news://<opvshfkebqj84x31(at)sih-nbivu-agcom>
Hello all,
when adding a code attribute to the <ocp> element, we have to define what
real world information shall become the code and what the abbreviation.
According to the "Technical Specifications for Interoperability" (TSI) of
the UIC (I'm refering to Annex B.9 of TAP TSI: Standard numerical coding
of locations) a railway location is idetified by
- a primary code that consists of
- numerical country code (2 digits)
- railway location number (5 digits)
- check digit (1 digit)
- a unique official location name
- optional additional shortened names
Furthermore we have the letter or letter/number codes known in Germany as
"Betriebsstellenkürzel" that are not only in Germany widely used.
To avoid confusion we should clearly document which railML-attribute is
intended to be used for which identifier. Otherwise we will see in the
railML code attribute letter codes, and 5-, 6-, 7- and 8-digit number
codes, depending on who sent the data.
My view of the issue is that when I hear "code" I immediately think of the
uic code.
So I would map
uic_primary_code (all 8 digits) -> ocp.code
Ortskürzel -> ocp.abbreviation
location name -> ocp.name
Defining the code as the uic code including the county code would make
ticket #112 (attribute for uic country code)redundant.
Two interface partners could still agree on sending only 5 or 6 digits for
national implementations though I woulnd't recommend this (I spent whole
days at one of may old jobs to transform 5-digit interfaces files into
6-digit ones).
Best wishes from Berlin
Simon Heller
IVU Traffic Technologies AG
Bundesallee 88, D-12161 Berlin
Telefon: +49.30.8 59 06-343
mailto:sih(at)ivude, http://www.ivu.de
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
|
|
|
|
| Re: Fwd: Mapping of code and abbreviation for ocps [message #247 is a reply to message #246] |
Mon, 21 March 2011 15:35  |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hello Simon,
"Simon Heller" <sih(at)ivude> writes:
> ... I accidently posted this infrastructure message in the timetable forum.
I don't think, it was a bad choice posting this issue to both timetable
AND infrastructure forum. It is an aspect of infrastructure with high
relevance for timetables.
I add a short reply from Joachim (by mail)
On Mon, Mar 21, 2011 at 11:45:09AM +0100, Joachim Rubröder wrote:
>
> Der Vorschlag von Simon, den UIC-Code am ocp zu berücksichtigen finde
> ich sehr vernünftig. Da es dafür ja eine Beschreibung gibt, sollten
> wir die auch möglichst 1:1 umsetzen:
> - numerical country code (2 digits)
> - railway location number (5 digits)
> - check digit (1 digit)
> -> neue eigene Felder speziell hierfür "uic-xy"
>
> "code" sehe ich für den Länder-intern bzw. System-intern üblichen
> Schlüssel, also DS100 bzw. die mehrbuchstabige Abkürzung. Da können
> wir in railML aber schwer eine verbindlichen Vorgabe über die Nutzung
> machen. Viriato würde da wohl am ehesten den UICCode (2-digits) und
> dann den vom Anwender vergebenen Schlüssel (also z.B. '85ZUE' für
> Zürich) reinschreiben
>
> "name" ist dann wohl der Name des ocp (z.B. 'Zürich'), auch ohne
> verbindliche Vorgaben für die Nutzung.
I translate this into the following (currently non-valid) XML fragments:
<xs:attribute name="tsiCountry" type="rail:tTwoDigits" />
<xs:attribute name="tsiLocation" type="rail:tFiveDigits" />
<xs:attribute name="tsiCheck" type="rail:tOneDigit" />
The newly introduced "code" attribute should be used for local location
codes, like (RL100 in Germany). I would prefer using the "code"
attribute with pure local (non-central) location codes (allowing
letters, digits and whitespaces) but without additional country code
prefixes, like Joachim suggested.
The "old" attributes "abbrevation" and "number" stay marked as
"Deprecated" for next major release. see:
http://trac2.assembla.com/railML/changeset/335
http://trac2.assembla.com/railML/ticket/94
Some example would be:
<ocp id="o12345"
code="ZUE"
name="Zürich"
description="Zürich Hauptbahnhof"
tsiCountry="85"
tsiLocation="12345" <!-- ?? -->
tsiCheck="3" />
Thank you Simon, for mentioning some official source.
Current file for download (as draft version):
http://www.era.europa.eu/Document-Register/Documents/TAP-TSI -Technical_Document_TAP_B_9_v1.1.pdf
(without according code lists, with some missing paragraphs and small
inconsistent explanations!)
There are some more definitions for location code lists that should be
used in telematic applications for passenger railway services in future
assumed this TSI is put into practice.
I resume the official code snippets for railML attributes:
tsiCountry (2 Digits) - country to which the location belongs in
accordance to the Code List B.9.1
(currently missing!)
tsiLocation (5 Digits) - railway location number, the code shall be
allocated by a national authority according
to its own rules... Each Primary Code shall
have an unambiguous and compulsory
designation which shall be defined by the
national authority.
tsiCheck (1 Digit) - check digit in accordance with the rules
specified in Annex A.
tsiReservation (5 Digits) - seat reservation code are defined and
allocated by each RU according to its own
rules.
tsiType (1 Digit) - Type used to indicate the type of location [see
code list B.9.2];
(currently missing!)
tsiInfrastructureBorder (3 Digits) - frontier and IM-transit point
code used to identify the
frontier and transit point
concerned within the different
"Type" categories. ...The
allocating body tries to achieve
agreement between the concerned
parties and allocates the
Subsidiary Code.
tsiRailwayA (4 Digits) - Company Code of RU A according ERA TAP TSI
Technical Document B.8
tsiRailwayB (4 Digits) - Company Code of RU A according ERA TAP TSI
Technical Document B.8
If we agree, implementing these attributes, I would prefer adding a new
element, called "tsi" or "era" or "uic", cutting the attributes'
prefixes.
just my 2 cents...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: Fwd: Mapping of code and abbreviation for ocps [message #257 is a reply to message #247] |
Sun, 15 May 2011 22:50 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hello Simon,
please read my comment to the current implementation for closing
http://trac2.assembla.com/railML/ticket/112 below.
Am 21.03.2011 15:35, schrieb Susanne Wunsch:
> Hello Simon,
>
> "Simon Heller"<sih(at)ivude> writes:
>
>> ... I accidently posted this infrastructure message in the timetable forum.
>
> I don't think, it was a bad choice posting this issue to both timetable
> AND infrastructure forum. It is an aspect of infrastructure with high
> relevance for timetables.
>
> I add a short reply from Joachim (by mail)
>
> On Mon, Mar 21, 2011 at 11:45:09AM +0100, Joachim Rubröder wrote:
>>
>> Der Vorschlag von Simon, den UIC-Code am ocp zu berücksichtigen finde
>> ich sehr vernünftig. Da es dafür ja eine Beschreibung gibt, sollten
>> wir die auch möglichst 1:1 umsetzen:
>> - numerical country code (2 digits)
>> - railway location number (5 digits)
>> - check digit (1 digit)
>> -> neue eigene Felder speziell hierfür "uic-xy"
>>
>> "code" sehe ich für den Länder-intern bzw. System-intern üblichen
>> Schlüssel, also DS100 bzw. die mehrbuchstabige Abkürzung. Da können
>> wir in railML aber schwer eine verbindlichen Vorgabe über die Nutzung
>> machen. Viriato würde da wohl am ehesten den UICCode (2-digits) und
>> dann den vom Anwender vergebenen Schlüssel (also z.B. '85ZUE' für
>> Zürich) reinschreiben
>>
>> "name" ist dann wohl der Name des ocp (z.B. 'Zürich'), auch ohne
>> verbindliche Vorgaben für die Nutzung.
>
> I translate this into the following (currently non-valid) XML fragments:
>
> <xs:attribute name="tsiCountry" type="rail:tTwoDigits" />
> <xs:attribute name="tsiLocation" type="rail:tFiveDigits" />
> <xs:attribute name="tsiCheck" type="rail:tOneDigit" />
>
> The newly introduced "code" attribute should be used for local location
> codes, like (RL100 in Germany). I would prefer using the "code"
> attribute with pure local (non-central) location codes (allowing
> letters, digits and whitespaces) but without additional country code
> prefixes, like Joachim suggested.
>
> The "old" attributes "abbrevation" and "number" stay marked as
> "Deprecated" for next major release. see:
>
> http://trac2.assembla.com/railML/changeset/335
> http://trac2.assembla.com/railML/ticket/94
>
> Some example would be:
>
> <ocp id="o12345"
> code="ZUE"
> name="Zürich"
> description="Zürich Hauptbahnhof"
> tsiCountry="85"
> tsiLocation="12345"<!-- ?? -->
> tsiCheck="3" />
>
> Thank you Simon, for mentioning some official source.
>
> Current file for download (as draft version):
>
> http://www.era.europa.eu/Document-Register/Documents/TAP-TSI -Technical_Document_TAP_B_9_v1.1.pdf
>
> (without according code lists, with some missing paragraphs and small
> inconsistent explanations!)
>
> There are some more definitions for location code lists that should be
> used in telematic applications for passenger railway services in future
> assumed this TSI is put into practice.
>
> I resume the official code snippets for railML attributes:
>
> tsiCountry (2 Digits) - country to which the location belongs in
> accordance to the Code List B.9.1
>
> (currently missing!)
>
> tsiLocation (5 Digits) - railway location number, the code shall be
> allocated by a national authority according
> to its own rules... Each Primary Code shall
> have an unambiguous and compulsory
> designation which shall be defined by the
> national authority.
>
> tsiCheck (1 Digit) - check digit in accordance with the rules
> specified in Annex A.
>
> tsiReservation (5 Digits) - seat reservation code are defined and
> allocated by each RU according to its own
> rules.
>
> tsiType (1 Digit) - Type used to indicate the type of location [see
> code list B.9.2];
>
> (currently missing!)
>
> tsiInfrastructureBorder (3 Digits) - frontier and IM-transit point
> code used to identify the
> frontier and transit point
> concerned within the different
> "Type" categories. ...The
> allocating body tries to achieve
> agreement between the concerned
> parties and allocates the
> Subsidiary Code.
>
> tsiRailwayA (4 Digits) - Company Code of RU A according ERA TAP TSI
> Technical Document B.8
>
> tsiRailwayB (4 Digits) - Company Code of RU A according ERA TAP TSI
> Technical Document B.8
>
> If we agree, implementing these attributes, I would prefer adding a new
> element, called "tsi" or "era" or "uic", cutting the attributes'
> prefixes.
The currently implemented solution, which will be part of the railML 2.1
release, follows this concept:
There is a new optional element <tsi> within the element <ocp>. It shall
include all the code values that are set in the "TAP TSI: ANNEX B.9
STANDARD NUMERICAL CODING OF LOCATIONS" by the ERA. Currently, this
document is a draft document only and the proposed values are not
confirmed, yet.
As discussed during the meeting in Braunschweig last Monday, we
therefore focus on the country code in the first place. The new tsi
element contains the attribute:
<xs:attribute name="tsiCountry" type="rail:tTwoDigits" />
Further attributes need to be discussed on the basis of a confirmed TAP
TSI and can be added in future after the railML 2.1 release.
This concept has been implemented in
http://trac2.assembla.com/railML/changeset/391
Best regards
Christian
---
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Fwd: Mapping of code and abbreviation for ocps [message #380 is a reply to message #376] |
Sat, 06 October 2012 08:06 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Dear Dirk,
>> 'date' defines the publishing date of the register.
>
> I guess 'date' is optional. Before it is too late: Shouldn't we name it
> 'startDate' and possibly introduce an (optional) 'endDate', too?
thank you for your important remark. As described in detail in trac
ticket [1] I renamed "date" into "beginDate" and added "endDate". Both
dates are optional while the other parameters, "register" and "entry"
are set to be required.
Can you please copy your examples into the Wiki? Thank you again.
[1] https://trac.assembla.com/railML/ticket/112
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Goto Forum:
Current Time: Fri Apr 19 23:56:13 CEST 2024
|
Members
Search
Help
Login
Home
