This page describes use and application of Coordinate Reference Systems in Orbit.
For basic concepts and theory about the coordinate system, datum and projection, see Coordinate Reference System in Theory.

Orbit supports Horizontal and Vertical Coordinate Reference Systems.
Geographic and projected Horizontal CRS can be used and combined on the fly. Geocentric CRS are supported but need be converted upon import to a supported Geographic or Projected CRS. Use of CRS units foot (ft) or US survey foot (USft) required special attention.

Orbit has the objective to support the most recent definition of horizontal coordinate reference systems as defined by the OGP (International Association of Oil and Gas Producers) and described in the EPSG library. Orbit respects the order of axes as defined by the EPSG Library.

Supported Projection methods (EPSG Code).
Missing methods are added upon request, contact Orbit support.

• Hotine_Oblique_Mercator (9812)
• Krovak_Oblique_Conformal_Conic (9819)
• Lambert_Conformal_Conic_1SP (9801)
• Lambert_Conformal_Conic_2SP (9802)
• Lambert_Conformal_Conic_2SP_Belgium (9803)
• Mercator_1SP (9804)
• Mercator_1SP_Spherical (9841)
• Oblique_Mercator (9815)
• Oblique_Stereographic (9809)
• Transverse_Mercator (9807)

Supported Transformation methods (EPSG Code).
Missing methods and local grid-based corrections are added upon request, contact Orbit support.

• Coordinate Frame Rotation (9607)
• Geocentric transformation (9603)
• Longitude rotation (9601)
• Molodensky-Badekas (9636)
• Position Vector transformation (9606)

Orbit supports Local Horizontal CRS and Grid Corrections as defined by local authorities.
New definitions are added upon request, contact Orbit support.

• EPSG 2039, Israel 1993 / Israeli TM Grid, Israel
• EPSG 27700, OSGB 1936 / British National Grid (OSTN02), United Kingdom.
• EPSG 27700, OSGB 1936 / British National Grid and ODN height (OSTN15), United Kingdom.
• EPSG 28992, Amersfoort / RD New and NAP height, The Netherlands.
• ESPG 29901, OSNI 1952 / Irish National Grid (OSTN02), Northern Ireland.
• ESPG 29901, OSNI 1952 / Irish National Grid and Belfast height (OSTN15), Northern Ireland.
• EPSG 29903, TM75 / Irish Grid (OSTN02), Ireland.
• EPSG 29903, TM75 / Irish Grid and Mailin Head height (OSTN15), Ireland.
• EPSG 31370, Belge 1972 / Belgian Lambert 72.

Local Horizontal CRS definitions are not available by default.

1. Download, unzip and copy the CRS configuration files into the Orbit CRS directory
   <Orbit installation directory>/program/system/crs/
2. Restart Orbit.
   The Local Horizontal CRS definitions are linked automatically to the corresponding EPSG code.

Note related to OSTN02 and OSTN15 for ESPG 27700, 29901 and 29903.

• OSTN02 and OSTN15 Local Horizontal CRS grid definitions include the corresponding Local Vertical CRS definition.
• OSTN02 and OSTN15 grid files cannot be combined! Both are using the same EPSG codes. Do not copy both versions in the Orbit CRS directory. It is the one or the other.
• Orbit's technical implementation scheme for OSTN grid corrections, see Implementation Schemes of OSTN Grid Corrections.

Notes related to Amersfoort RD New and NAP height, ESPG 28992 + 5709

• Amersfoort RD New Local Horizontal CRS definition includes the corresponding NAP height Local Vertical CRS definition.

Orbit supports Custom Horizontal CRS via a Prj file as defined by the OGC.

Copy the OGC structured Prj file into the Orbit CRS directory and restart Orbit :
<Orbit installation directory>/program/system/crs/

Following file name syntax must be applied to the copied Prj file :
<number>_<description>.prj

• <number> must be larger than 1,000,000 and smaller than 2,000,000.
• <description> is optional.
• Example “1031370_Belge 1972 - Belgian Lambert 72.prj”

The Custom Horizontal CRS will be available via the Orbit CRS Window by entering a) the projection name as stated in the prj content, b) its number as used in the prj file name or c) via the CRS By Country list under Undefined Area.

Orbit supports Global and Local Geoid references for combined use of WGS84 Ellipsoidal and Orthometric height.
New definitions are added upon request, contact Orbit support.

• EPSG 3855, EGM2008 height 1x1, World, grid 1'x1'.
• EPSG 3855, EGM2008 height 2.5x2.5, World, grid 2.5'x2.5'.
• EPSG 5773, EGM96 height 15x15, World, grid 15'x15'.
• EPSG 5613, RH2000 height, Sweden.
• EPSG 5701, ODN height, United Kingdom.
  This Vertical CRS is included in the corresponding Local Horizontal CRS definition, see above.
  This Vertical CRS includes additionally following Vertical CRS :
  • EPSG 5740, ODN Orkney height.
  • EPSG 5741, Fair Isle height.
  • EPSG 5742, Lerwick height.
  • EPSG 5743, Foula height.
  • EPSG 5744, Sule Skerry height.
  • EPSG 5745, North Rona height.
  • EPSG 5746, Stornoway height.
  • EPSG 5747, St Kilda height.
  • EPSG 5748, Flannan Isles height.
  • EPSG 5749, St Marys height.
  • EPSG 5750, Douglas height.
• EPSG 5703, NAVD88 height, North American Vertical Datum of 1988 for the conterminous United States.
  Definition based on GEOID12B as defined by National Geodetic Survey (NOAA).
  This Vertical CRS includes additionally following Vertical CRS :
  • EPSG 6640, NMVD03 height, Northern Marianas Vertical Datum of 2003.
  • EPSG 6641, PRVD02 height, Puerto Rico Vertical Datum of 2002.
  • EPSG 6642, VIVD09 height, Virgin Islands Vertical Datum of 2009.
  • EPSG 6643, ASVD02 height, American Samoa Vertical Datum of 2002.
  • EPSG 6644, GUVD04 height, Guam Vertical Datum of 2004.
• EPSG 5705, CR2005, Czech and Slovak Republics.
  
• EPSG 5709, NAP height, Netherlands.
  This Vertical CRS is included in the corresponding Local Horizontal CRS definition, see above.
• EPSG 5720, NGF-IGN69 height, France.
• EPSG 5941,NN2000 height, Norway.
  
• EPSG 5710, Ostend height, Belgium.
• EPSG 5731, Malin Head height, Ireland.
  This Vertical CRS is included in the corresponding Local Horizontal CRS definition, see above.
• EPSG 5732, Belfast height, Northern Ireland.
  This Vertical CRS is included in the corresponding Local Horizontal CRS definition, see above.
• EPSG 7839, NZVD2016, New Zealand.
• EPSG 9988, ILUM 1.2, Israel.

Vertical CRS definitions are not available by default.

1. Download, unzip and copy the CRS configuration files into the Orbit CRS directory :
   <Orbit installation directory>/program/system/crs/
2. Verify and enter if missing the EPSG codes (semicolon separated) of the Horizontal CRS that needs to be linked to the Vertical CRS into following Vertical CRS configuration file :
   vertical_<EPSG Vertical CRS>.ini
   For example

   available.in.horizontal.crs 4326;3395;31370

3. Restart Orbit.

Orbit supports Custom Vertical CRS via a Geoid Height Raster definition.

In cooperation with the Orbit Support team, Geoid reference resource files can be converted into the required Orbit CRS configuration files.
One of the following resources representing the Geoid height ¹⁾ can be used to create the CRS configuration files :

• Supported raster resource, see Supported Geodata Resources.
• Esri ascii raster file.
• XYZ ascii file space, comma or semicolon separated.

Scaled and offset vertical CRS definitions.

For any coordinate system, Orbit follows the order of axes as defined by the EPSG library. As a result, Orbit expects data to also respect the order as defined by EPSG definition.

In practice, for various reasons like changes in the CRS definitions by local mapping authorities or different order of axes implementations in other software, data may be stored using a different order. Because of this, you will find that some coordinate systems are listed as both the original crs and the inverted one in the Orbit CRS Library.

To define the projection of any resource, the original CRS should be used if the data is stored according to the EPSG order axes definition, and the inverted CRS should be used for data in which the order is reversed.

Projected CRS using International feet (ft) or US survey feet (ftUS) units require special attention.

The Orbit Core and Map Components support Projected CRS using ft and ftUS. Orbit uses https://www.epsg-registry.org/ as the reference database. In United States, the Federal definition of the CRS is metric at all time, but State law defines the CRS in International feet or US survey feet.

The MapCanvas CRS can be set to any CRS supported by Orbit - feet or metric. Although for optimal rendering performance, we do advice to use the CRS of the resources which are currently viewed.

Absolute measurements (2D and 3D Coordinates) use the MapCanvas CRS. In case the vertical MapCanvas CRS is in feet, than the Z-coordinate will be visualized in feet in the measurement sidebar.

A resource can have any CRS supported by Orbit - feet or metric. But be careful with the following:

• Some Orbit Extensions expect data to be stored as meters or degrees to operate.
• For Oblique, UAS and Mobile Mapping resources and Vector Datasets, we do advise to convert the CRS to the parent metric definition when importing the original resource files into the optimized Orbit Runs.
• All resources of a run or project should have the same CRS.

When using these converted resources, display and exports can still be set to ft or ftUS to get exactly the expected results. A user won't notice the data is actually stored using the parent metric CRS.

see Preferences of Map Canvas

Every single resource has a CRS.
If no Orbit dataset CRS is set, Orbit will read the resource assuming that dataset has the same coordinate system as the MapCanvas (see below). When combining resources with different coordinate system it is strongly recommended to define the coordinate system for every single resource.
Orbit supports imagery to be reprojected on the fly.

There are two ways to set the CRS of a dataset in Orbit :

• Context Menu > Dataset Properties Inspect
• Context Menu > Coordinate Reference System > Define Dataset CRS

The dataset CRS is saved in the Orbit Resource Descriptor file :

• Orbit Resource Descriptor

All resources are displayed in the Map CRS. If the Dataset CRS differs from the Map CRS than the dataset will be re-projected on the fly to be displayed on Map.

Optimize Performance
Re-projecting datasets from their source Dataset CRS into another target Map CRS requires processing time. Consequently large vector or point cloud resource will take more time to load and will slow down map rendering. It is advised to avoid on the fly re-projection by using the Dataset CRS as Map CRS. When using multiple resource having different Dataset CRS, it is advised to use the Dataset CRS of the resources having most vertices as Map CRS.

Deformations
Re-projecting means deforming. To retain shape, angles and presentation it's again advised to used the dataset crs as map crs.

Define Map CRS
The Map CRS can be changed quickly via the map status bar “Coordinate Reference System selection” window.
Open this window via a single click on the current map crs in the map statusbar.

The map crs on start-up is defined in your workspace

• Orbit desktop Standalone : Orbit GIS Workspace file
• Orbit desktop Client, set by administrator via the EOS Console > EOS Console > Workspaces

Default behavior and preferences
If no datasets are visible in the current workspace, than the first visible datset crs will be used as map crs.