Home » railML newsgroups » railml.common » More standard attributes for objects
| More standard attributes for objects [message #2129] |
Mon, 04 February 2019 19:27  |
Claus Feyling
Messages: 4
Registered: April 2016
|
Junior Member |
|
|
Dear all!
We are using the editor RailCOMPLETE®, a graphical and table-based
editor based on AutoCAD®, in order to enter data into a network-oriented
railway infrastructure model. Such models are usually geographic and
comprises areas (zones), alignments, point objects with XYZ position
(and with a 3D orientation in space).
A simple model in this CAD editor is just a AutoCAD DWG file with
objects. The DWG file structure of AutoCAD is a proprietary to Autodesk
but widely used as a database format. One DWG file may reference another
DWG file. The referenced file may reference another DWG file etc.. We
therefore need an identification which is unique within a context which
changes every time a new DWG file with objects is referenced.
On the other hand, it can be argued that two teams may produce models of
the same infrastructure, and the objects being modelled will usually be
given different id’s by these teams, even though the objects being
modelled are “the same” in a certain way.
Suggestion 1: id - unique within all contexts
We suggest that the existing railML attribute 'id' is defined as it is
at present, allowing the same id to be found in different railML models.
However, its general usage shall be encouraged to be as follows: The id
should be unique within all foreseeable contexts and generated once at
the time the object was created.
We suggest that the following should always hold true for a well-formed
railML file:
a) A globally unique ID (guid) shall be computed and assigned to each
object's id attribute at the time the object is created.
b) The id will never change.
Immediate consequences:
If the same object shall exist in several construction phases, then this
object must contain information about the phases it belongs to.
Two objects may share identical data except their id. They are still two
separate objects in the model. Sharing the same 'code' and/or 'name'
values does not make the two objects the same object in a strict sense.
Practical adaptions:
Even though two objects with different id's are strictly speaking
different objects, a user may still decide, within his or her context,
that when for instance 'ocp' and 'code' have the same value for tow
objects of the same object class, then these two are to be interpreted
as 'the same' within that model.
Suggestion 2: tag - unique within one administration's context
A guid is not human-readable. Most real systems in operation have a TAG
system, which constitutes a unique and human-readable identification of
an object within their context. Bane NOR, as an example, has a tag
system called 'BANEDATA OBJEKT ID', consisting of code of the form
"XX-YYY-nnnnnn", for instance 'SA-TEL-002349'. SA means "Signalanlegg"
(signalling system) in this context, and "TEL" means Axle counter sensor
('Tellepunkt'). The six digits are a unique number within the SA-TEL
category. Other railway administrations might have similar but
differently specified tag encoding systems. We assume that one
administration has only one tag system.
We suggest that the attribute 'tag' is added to all objects in railML.
Suggestion 3: code - unique within the context of a given station and
object type
Railway objects such as switches are usually numbered using a numbering
system which is unique within the station they are part of. These
numbers are then re-used at the next station or at the next railway
line. The same occurs for signal object numbers, which might be unique
within one line but the numbers then re-appear for another line. Many
objects are related to each other in a parent-child relationship where
the child will be referred to using a name formed from its parent and
from some numbering scheme for such child objects, ensuring uniqueness
within the current context. For instance, if a switch is numbered ‘501’
and this switch has three point machines, then these point machines
could be identified using the names “501.1”, “501.2” and “503.1”.
We suggest that the railML attribute 'code' should preferably be used as
a compact, context-sensitive, human-readable and easily remembered
encoding of the object’s identity. It should use the ‘tribe language’ of
those who plan, build and maintain these objects. The 'code' field
should lend itself well as a basis for other, related, objects when such
related objects need a value for their own 'code' attribute. The 'code'
attribute is usually shown in a context where the object type, the
station name, the line name, the administration, the country etc are
already known, for instance as a number appearing in a column in a table.
Suggestion 4: name - an ornamented and context-dependent identification
of an object
With the 'id' and the 'code' attributes used as recommended above, we
still have a need for a human-readable text which may appear in drawings
or in references to an object mentioned somewhat outside their limited
context. As an example, referring to switch number 501 inside Sandvika
station on the Drammensbanen line may be presented in a text or in a PDF
drawing as either "501", "V.501", "SV-V.501", “SV-V.501 (DB)",
“Sandvika sporveksel 501 (Drammenbanen)" or "Sandvika (Norway), switch
501 on the Drammen line" etc – the amount of information provide will
depend on the assumed knowledge of the context that the intended
audience has.
We suggest that the railML attribute 'name' should represent the
object's human-readable name with sufficient extra contextual
information, intended for a reader which does not a priori have enough
contextual knowledge to understand the object’s identity just from the
‘code’ attribute.
Best regards,
--
Claus Feyling
Daglig leder
CEO
Railcomplete AS
Kontor: Vestfjordgaten 4, N-1338 Sandvika
Firmapost: Brageveien 4a, N-0358 OSLO
+47 908 24 018
www.railcomplete.com
|
|
|
|
Current Time: Fri Apr 26 21:37:20 CEST 2024
|
Members
Search
Help
Login
Home
