IS:geoCoord ownerChange

From wiki.railML.org
Jump to: navigation, search

geoCoord
 


Scheme description / Schemenbeschreibung / Description du schéma

Position of geoCoord in the XML-Tree / Position von geoCoord im XML-Baum / position de geoCoord dans l’aborescence XML

  • Children: None

Multiplicity / Anzahl / Multiplicité

[0..1]

Semantics / Bedeutung / Sémantique

<geoCoord> provides the definition of a geographical position (e. g. longitude, latitude, altitude). It can be used in case that element positions should not only be specified by relative or absolute mileage along the track but via geographical reference as well. Thus, <geoCoord> defines exactly one point on earth given by either two or three dimensional coordinates.

The coordinate system is specified by its EPSG-Code (external link). It can either be provided as optional value for each coordinate element or as a default value assigned in <infraAttributes>. By default, the coordinates shall be given in the reference system WGS84, because it is valid worldwide — see http://spatialreference.org/ref/epsg/wgs-84 (external link).

The semantics for the list contents of the coord attribute are implicitly defined by their bounded EPSG-Code (external link).

Attributes of geoCoord / Attribute von geoCoord / Attributs de geoCoord

  • coord: This is a list of values representing the coordinates.
  • extraHeight: This is a separate value for the altitude/height. It is used
    • if altitudes are stored in an own reference system (i. e. epsgCode refers to a GeodeticCRS rather than a CompoundCRS),
    • if there are no long/lat coords given or known but a height (see notes below).
  • epsgCode: This is an URI pointing to the EPSG-Code (external link) as reference system for the coordinates in coord.
  • heightEpsgCode: This is an URI pointing to the EPSG-Code (external link) for the separate altitude reference system.

Syntactic Constraints / Syntaktische Beschränkungen / Contraintes syntactiques

  • coord "whitespace" separated list of xs:double values, at minimum two values, at maximum three values, mandatory (for arrangement see below)

For 2-dimensional reference, there are two values in the coord attribute, extraHeight attribute is absent.

For 3-dimensional references, there are either three values in the coord attribute and extraHeight is absent or two values in the coord list together with the extraHeight attribute. The third value in coord and the attribute extraHeight shall not be used in conjunction (the third value may be set to zero if there is an attribute extraHeight).

The usage of geographical coordinates in <geoCoord> is optional. Regarding the positioning of elements, the relative position along the track (see pos attribute in <ownerChange>) is mandatory.

epsgCode is highly recommended (mandatory for a future release) if there are coordinates given in the attribute coord (i. e. if both long and lat coords are not zero).
epsgCode has to refer to a GeodeticCRS (incl. projected geodetic CRS) or CompoundCRS (such as 4258, 4326, 4314).

heightEpsgCode is highly recommended (mandatory for a future release)
- if there is a height given in the attribute coord and epsgCode does not refer to a CompoundCRS,
or
- if the attribute extraHeight is used.
heightEpsgCode has to refer to a VerticalCRS (such as 5621, 5730, 5783, 5785) but not to a VerticalDatum (such as 6258, 5183, 5181).

Best practice & Examples / Empfohlene Anwendung & Beispiele / Bonnes pratiques & exemples

There are some aspects about geographical coordinates and the current implementation in railML, which are not yet solved and require further discussion. These aspects are listed below:

  • At the moment, only one <geoCoord> per element can be defined. It is not possible, to give one point multiple geographical coordinates, e.g. for locating a point in different reference systems.
  • At the moment, height coordinates cannot exist without horizontal coordinates. From the timetable's perspective this is difficult since often coordinates are not know and only the vertical height/gradient profile could be modelled. Therefore, the height coordinates should be defined independent from the horizontal coordinates. Until then, please use the parameter extraHeight in combination with zero horizontal coordinates (example for German DHHN92):
  <geoCoord coord="0 0 0" extraHeight="123.4" epsgCode="urn:ogc:def:crs:EPSG::5783" />
  • The height coordinates may differ in various countries referencing different national peils (Amsterdam's Peil, Kronstadt Peil, ...). The peil systems are categorized in the EPSG code too. You may find the EPSG codes at the website of EPSG Geodetic Parameter Dataset (external link).

Examples

  <geoCoord coord="52.2449 10.5466" epsgCode="urn:ogc:def:crs:EPSG::4326"/>


This code example defines the position of Oslo Sentralstasjon in WGS84 coordinates:

  <geoCoord coord="59.911 10.754" epsgCode="urn:ogc:def:crs:EPSG::4326" />


This code example defines the position of Oslo Sentralstasjon in ETRS89 / ETRS-TM32:

  <geoCoord coord="598059.6081 6642972.5966" epsgCode="urn:ogc:def:crs:EPSG::3044" />


The following code example defines a height without long/lat coordinates:

  <geoCoord coord='0 0' extraHeight='250.03' heightEpsgCode='5783'/>

(In railML 2.0 and 2.1, for syntactical reasons, there has to be a third 0 in coord:)

  <geoCoord coord='0 0 0' extraHeight='250.03' heightEpsgCode='5783'/>


The following code example of Görlitz defines a height in a different reference system than the long/lat coordinates:

  <geoCoord coord='51.1473 14.9783' epsgCode='4326' extraHeight='209.42' heightEpsgCode='5783'/>

which is equivalent to

  <geoCoord coord='51.1473 14.9783 209.42' epsgCode='4326' heightEpsgCode='5783'/>


The following code example of Görlitz defines a height in the same compound reference system as the long/lat coordinates:

  <geoCoord coord='51.1473 14.9783 209.38' epsgCode='6893' />

Notes / Anmerkungen / Notes

A database of EPSG-Codes http://en.wikipedia.org/wiki/EPSG EPSG-Codes (external link) is available from the EPSG-Registry (external link).

The full urn reference part of the attributes epsgCode and heightEpsgCode - that is "urn:ogc:def:crs:EPSG::" - is treated to be constant. (Between the last two colons :: is the place for a version number of the EPSG code if there would be any.) Since it is clear that the attributes are only allowed to contain EPSG numbers, and if there would be no version number, you can omit the constant part, just reducing the value to the actual EPSG code number: epsgCode="urn:ogc:def:crs:EPSG::4326" is the same as epsgCode="4326".

Unit for height coordinates

The unit for the height coordinate is given by the used EPSG code. For example, the "Deutsches Haupthoehennetz 1992" with EPSG code 5783 defines the height in meters — see http://www.spatialreference.org/ref/epsg/5783/prettywkt (external link).

Sequence of coordinates / Reihenfolge der Koordinaten

The order of the coordinates is specified by the spatial reference system (SRS), which has to be given, e.g. in form of the EPSG code. The EPSG code is a standard for identifying all the different coordinate reference systems that exist and the EPSG register (external link) contains them all. The most common basis is the World Geodetic System 84 (WGS 84) with the EPSG code 4326. WGS 84 is a geodetic coordinate reference system, which includes an ellipsoidal coordinate system (EPSG::6422) defining the axes geodetic latitude (1, north) and geodetic longitude (2, east). Therefore, the correct order of coordinates is: latitude, longitude. The complete schema definition can be found in the OpenGIS register (external link).

Prinzipiell richtet sich die Reihenfolge der Koordinaten nach der Definition im zugehörigen SRS (Spatial Reference System), welches in Form des EPSG-Codes angegeben ist. Mit Hilfe des EPSG-Codes lassen sich alle verschiedenen Koordinatensysteme angeben. Einen Überblick über diese Koordinatensysteme liefert das OpenGIS schema (externer Link). Das meistgenutzte System ist das "World Geodetic System 84 (WGS 84)" mit dem EPSG-Code (externer Link) 4326. WGS 84 ist ein geodätisches Koordinaten-Referenzsystem, welches einen Referenzellipsoiden (EPSG::6422) besitzt, dessen Koordinatenachsen "Geodetic Latitude" (1, Nord) und "Geodetic Longitude" (2, Ost) aufspannen. Daher ist die korrekte Reihenfolge der Koordinaten: Latitude, Longitude.

Open issues / Offene Punkte/Pedenzen / Questions ouvertes

There are some aspects about geographical coordinates and the current implementation in railML, which are not yet solved and require further discussion. These aspects are listed below:

  • At the moment, only one <geoCoord> per element can be defined. It is not possible, to give one point multiple geographical coordinates, e.g. for locating a point in different reference systems.
  • At the moment, height coordinates cannot exist without horizontal coordinates. From the timetable's perspective this is difficult since often coordinates are not know and only the vertical height/gradient profile could be modeled. Therefore, the height coordinates should be defined independently from the horizontal coordinates. Until then, please use the parameter extraHeight in combination with zero horizontal coordinates (example for German DHHN92):
  <geoCoord coord="0 0 0" extraHeight="123.4" heightEpsgCode="urn:ogc:def:crs:EPSG::5783" />
  • The height coordinates may differ in various countries referencing different national peils (Amsterdam's Peil, Kronstadt Peil, ...). The peil systems are categorized in the EPSG code too. You may find the EPSG codes at the website of EPSG Geodetic Parameter Dataset (external link).
  • The definition of EPSG codes for every geoCoord element provides redundancy and enlarges the railML files. Therefore, it is suggested to define an attribute for a global EPSG code being valid for all coordinates of the railML file. See http://trac.railml.org/ticket/265 (link to the railML® website) for more details and follow up.