Home » railML newsgroups » railml.timetable » Mapping of code and abbreviation for ocps
| Mapping of code and abbreviation for ocps [message #708] |
Thu, 17 March 2011 11:03  |
Simon Heller
Messages: 6
Registered: March 2011
|
Junior Member |
|
|
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/
|
|
|
|
| Fwd: Mapping of code and abbreviation for ocps [message #710 is a reply to message #708] |
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 #712 is a reply to message #710] |
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: Mapping of code and abbreviation for ocps [message #763 is a reply to message #708] |
Mon, 26 March 2012 09:31 |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
We discussed about some aspects 0f Simon's original post from one year ago
again on last Monday, March 19th 2012.
There are normally several abbreviations and/or numbers for the same
station, even in one country. So, the writing and reading software of a
RailML file can have different external primary keys for the same station.
During the evaluation process of the last year we got the new 'code' and
'tsi' as additional external primary keys but somehow we lost
'abbrev[i]ation' and 'number' as well. So where to put the abbreviations
and EFA-numbers (needed in Germany) now? We cannot put both into 'code'....
So, we now have this certain amount of confusion which Simon did warn us
against...
We now intend to allow a kind of enumeration of two-valued elements
(elements with two attributes) per station. Each one can handle one
external primary key of the station, which may be either a string
(abbreviation) or a number.
I try to explain with a simple example (which is _not_ valid RailML nor
agreed in any kind, so key words or syntax may differ later):
<ocp ... name='Passau Hbf.' ...>
<externalPrimaryKeys>
<externalPrimaryKey register='DS100' value='NPA'/>
<externalPrimaryKey register='DB640' value='Pa'/>
<externalPrimaryKey register='UIC:80' value='80.7.33.165.9059'/>
<externalPrimaryKey register='UIC:81' value='81.4.1744'/>
<externalPrimaryKey register='EFA' value='8000298'/>
</externalPrimaryKeys>
</ocp>
The first attribute 'register' means something like catalogue, index,
directory. It shall be an enumeration of predefined values but this would
mean, if someone needs a new register, he would need to call the Scheme
Coordinator first. So I guess we have to allow a free string there. But we
should _strongly_ recommend and agree that each new 'register' has to be
'registered' at the Scheme Coordinator...
The second attribute 'value' has also to be defined as a string but may
contain a number also depending on the 'register'. (This means, some
'registers' require a number which is not forced by XML.)
With this principle, there is no need to use 'code' for the abbreviation
and/or the number. 'Code' will still be there since it is inherited but
(by recommendation) not specially to be used with OCPs.
I herewith apply for the following 'registers' to be defined from the very
beginning:
- 'DS100' for the German "Betriebsstellenkürzel" (referring to the former
"Dienstvorschrift"; I would not agree with "Richtlinie" since it is not a
recommendation to use them but a directive!)
- 'DB640' which is the Austrian pendent to DS100 (DB="Dienstbehelf" - has
nothing to do with Deutsche Bahn nor Dirk Bräuer).
- 'EFA' for the numbers used in some German public timetable databases and
some RaiLML-reading programmes (EFA="elektronische Fahrplanauskunft" - or
however they are called officially - Vasco know how).
The other values I used in the example above are really existing but we do
not use them in RailML so far and I do not know the exact name of their
origin.
It is intended to introduce the new principle with the first pre-launch
RailML 2.2.
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
|
|
|
|
| Re: Mapping of code and abbreviation for ocps [message #779 is a reply to message #763] |
Fri, 27 April 2012 17:26 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hello Dirk and others interested,
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
> We now intend to allow a kind of enumeration of two-valued elements
> (elements with two attributes) per station. Each one can handle one
> external primary key of the station, which may be either a string
> (abbreviation) or a number.
<ocp id="" name="" code="" description="">
<additionalCode register="" value=""/>
...
</ocp>
Is there any globally unique code for any kind of railway locations?
This could be fixed for the general "code" attribute. Otherwise it
would be better to leave this attribute absent and require the
definition of the "register" together with the code "value".
UIC manages the ENEE database. [1]
I don't have any access to the UIC leaflet 920. Does these location
codes serve as additional keys to the well-known
country/company-specific ones? Or does the UIC offer a really unique
code for each location?
The "register" values should be pre-defined by enumeration values. It
may be extended without changing the XML schemas.
> I herewith apply for the following 'registers' to be defined from the
> very beginning:
> - 'DS100' for the German "Betriebsstellenkürzel" (referring to the
> former "Dienstvorschrift"; I would not agree with "Richtlinie" since
> it is not a recommendation to use them but a directive!)
> - 'DB640' which is the Austrian pendent to DS100 (DB="Dienstbehelf" -
> has nothing to do with Deutsche Bahn nor Dirk Bräuer).
> - 'EFA' for the numbers used in some German public timetable databases
> and some RaiLML-reading programmes (EFA="elektronische
> Fahrplanauskunft" - or however they are called officially - Vasco
> know how).
Good starting point. Thanks.
The "value" should be a pure xs:string, allowing letters, numbers,
spaces, underscores, slashes, dashes, points and so on.
[1] http://www.uic.org/spip.php?article378
--
Kind regards...
Susanne
|
|
|
|
| Re: Mapping of code and abbreviation for ocps [message #780 is a reply to message #779] |
Thu, 17 May 2012 12:49 |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Susanne,
> Is there any globally unique code for any kind of railway locations?
No, surely not.
> This could be fixed for the general "code" attribute. Otherwise it
> would be better to leave this attribute absent and require the
> definition of the "register" together with the code "value".
I would prefer the latter, so leaving the attribute 'code' absent.
> UIC manages the ENEE database. [1]
ENEE should be one of the 'register' enumerations but not the 'code'.
> I don't have any access to the UIC leaflet 920. Does these location
> codes serve as additional keys to the well-known
> country/company-specific ones? Or does the UIC offer a really unique
> code for each location?
Even if UIC would try do provide such a word-wide unique code (which they
do not) we should not consider it as a general 'code' for reasons of
universality. RailML shall be usable really universally by internal
structure. Therefor, it should not be forced to UIC territory but also for
Asia, Africa or America. But more important, if you consider that the
following two aspects:
- What in detail will ever be assumed to be an OCP - the general
'stations' or also parts of a station or also block posts and may be also
some virtual location spots?
- RailML shall be usable in any time-relation: Not only with the existing
OCPs/stations but also with future ones (which nobody of UIC knows so far)
and with abandoned ones.
I think that there cannot be a really unique 'code' for all of that and
therefor we should always define the 'register' together with the 'value'
- which is the new principle.
> The "register" values should be pre-defined by enumeration values. It
> may be extended without changing the XML schemas.
Very good.
> The "value" should be a pure xs:string, allowing letters, numbers,
> spaces, underscores, slashes, dashes, points and so on.
Yes, I agree.
Best regards,
Dirk.
|
|
|
|
Goto Forum:
Current Time: Thu Apr 18 21:02:16 CEST 2024
|
Members
Search
Help
Login
Home
