This page describes the 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.
For information on CRS related to Mapping Resources, see Coordinate Reference Systems for Mapping Resources
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.
Supported Transformation methods (EPSG Code).
Missing methods and local grid-based corrections are added upon request, contact Orbit support.
Orbit supports Local Horizontal CRS and Grid Corrections as defined by local authorities.
New definitions are added upon request, contact Orbit support.
Local Horizontal CRS definitions are not available by default.
<Orbit installation directory>/program/system/crs/
Note related to OSTN02 and OSTN15 for ESPG 27700, 29901 and 29903.
Notes related to Amersfoort RD New and NAP height, ESPG 28992 + 5709
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
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.
Snake Grids are supported in orbit as Local Horizontal Definitions, see above.
These specific horizontal definitions are a combination of a correction grid and a local projection.
ETRS89/WGS84 coordinates > GSB > Corrected ETRS89/WGS84 coordinates1) > Local Projection > Snake Grid coordinates
The Grid Shift Binary (GSB) defines the raster to interpolate a correction for each global lat/lon coordinate(WGS84/ETRS89) to a corrected coordinate referencing an intermediate reference frame.
Next, a custom horizontal projection is applied to obtain cartesian coordinates from the geographic coordinates.
Orbit supports Global and Local Geoid references for the combined use of WGS84 Ellipsoidal and Orthometric height.
New definitions are added upon request, contact Orbit support.
Vertical CRS definitions are not available by default. This means that the vertical CRS can't be assigned to a horizontal CRS without relying on a resource representing the Geoid height. This resource doesn't exist by default in the software's installation folder.
<Orbit installation directory>/program/system/crs/
vertical_<EPSG Vertical CRS>.ini
available.in.horizontal.crs 4326;3395;31370
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 2) can be used to create the CRS configuration files :
Scaled and offset vertical CRS definitions. Custom Vertical CRS relies on already existing EPSG codes.
Into the Orbit CRS directory :<Orbit installation directory>/program/system/crs/
:
<EPSG Vertical CRS>_LocalOffsetVerticalCRS.prj
. 9999_LocalOffsetVerticalCRS.prj
and add inside VERTCS["LocallOffsetVerticalCRS"]
vertical_<EPSG Vertical CRS>.ini
. Inside the file do the following: type offset
available.in.horizontal.crs 4326;3395;31370
vertical.offset 20
Restart Orbit to acknowledge in the software the new custom CRS.
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.
Datum transformations are applied as defined by EPSG on XY coordinates. Z values are conserved as is, no transformation is applied.
Datum transformation on Z values can be enabled e.g. to combine multiple 3D data resources with different ellipsoid height definitions.
See Orbit Desktop Startup Configurations > Datum Transformation on Z coordinate
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:
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.
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 the different coordinate systems 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 :
The dataset CRS is saved in the Orbit Resource Descriptor file :
All resources are displayed in the Map CRS. If the Dataset CRS differs from the Map CRS then the dataset will be re-projected on the fly to be displayed on Map.
Re-projecting datasets from their source Dataset CRS into another target Map CRS requires processing time. Consequently, large vector or point cloud resources 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 resources having different Dataset CRS, it is advised to use the Dataset CRS of the resources having most vertices as Map CRS.
Re-projecting means deforming. To retain shape, angles, and presentation it's again advised to use the Dataset CRS as 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
If no datasets are visible in the current workspace then the first visible dataset CRS will be used as Map CRS.