This page describes the supported Mobile Mapping, UAS and Oblique resources, any combination of the listed resources can be used.

• DEM, if available. Preferably *.tif 32bit.
• Metadata:
  • CRS of every resource (information about height system is also required: ellipsoid or geoid height and in case of later which geoid)
  • System information (if available,especially for commercially available systems)
  • Expected quality\accuracy.
  • Camera Calibration information, if applicable (for planar images): focal length, principal point, image size in pixels and mm, pixel size, distortion parameters.
  • Information about orientation model (definition of the orientation angles: rotation axes, reference 0 direction, units.. )
• OrthoPhoto, if available. Preferably *.jpg.
• Photo position: Positions and orientation at the moment of exposure (absolute orientation parameters per image or position and orientation of IMU with LeverArms and Boresight information). Preferably *.txt or *.csv.
• Planars (frame images), if available. Preferably *.jpg.
• Point Cloud. Preferably *.las (v1.2).
• Reference data, if available (GCPs, vector data)
• Spherical images, if available: Equirectangular or Cubic panoramas. Preferably *.jpg.
• Trajectory, if available. Preferably *.txt or *.csv.

Orbit imports 3D mapping data using intelligent templates. An import template is configured according to a well known set of configurations, given carrier (vehicle, UAV, aircraft, etc..) setup and available data.
The use of templates simplifies and standardizes the import procedure for a well known set of data.

Download Templates
system and custom custom import templates can be downloaded here : 3D Mapping Data Preparation and Import Templates.

Customize Import
In addition to the available templates the Orbit engine offers all configuration possibilities to customize and optimize the import for using any kind or combination of 3D mapping data. Once the configuration is known, it can be added as a new import template to simplify all future imports.
Please contact the Orbit support team (support at orbitgt dot com) for more information or to create your customized template.

Orbit supports any combination of 3D mapping data and any coordinate system (CRS) on import. But be wise :

• The coordinate reference system should be part of the metadata of each resource.
• It is advised that all georeferenced resources are using the same CRS to avoid processing time of continuous coordinate transformation. If required convert CRS on import run.
• When converting the coordinate system of image positions apply the according adjustments on all orientation angles referring the reference direction of the coordinate systems (most probably north).

Optionally time-stamps can be imported. Time value can be a text string, integer or decimal value.

String values will be displayed as is and cannot be used for Content Manager post processing and point cloud view restrictions.
For post processing and point cloud view restrictions use of single time reference and “seconds” as time unit is required. A

Use of Absolute (Standard) GPS Time is advised.
If Absolute GPS time values (600,000,000 < Timestamp < 3,000,000,000) are detected, Orbit will display these as “yyyy-mm-dd hh:mm:ss”¹⁾.
If GPS Week Time Seconds values (0 ⇐ Timestamp =< 604,800) are detected, Orbit will be displayed these as “d hh:mm:ss”.

Notes on Absolute GPS Time :

• Orbit doesn't take leap seconds are not taken into account, more information : Wikipedia, GPS Timekeeping and Leap seconds.
• On storing Absolute GPS Time values in Point Cloud LAS files the actual stored value is the Absolute GPS Time minus 1,000,000,000. More information, see ASPRS LASer File Format Exchange Activities.

Orbit supports spherical and planar images.
There are no limitations on the number of cameras, the type of camera or the resolution of images.
One camera import requires one set of images and one positions and orientations file.

The absolute position and orientations at time of recording of all images must be available unambiguously.
Two possibilities :

• absolute position and orientation for each camera at time of recording
• combining the absolute position and orientation of a reference frame at time of recording with the fixed relative position and orientation for each camera to this reference frame (aka lever arm corrections).

Supported formats
Preferably .txt or .csv files.
But any supported point vector resource can be used.

Specifications

• One text file for each camera containing at least the below described information for each image.
• Column headers are optional and free of choice.
• Columns and order of columns can be customized.
• Coordinates can be expressed using any supported coordinate system.
  After import, it is strongly advised that all mobile mapping resources use the same coordinate reference system. If required coordinates can be re-projected or transformed on import.
• Orientations can be expressed as :
  • Pan (heading, yaw), Tilt (pitch), Roll ²⁾
    Reference direction and orientation are documented below, but can be customized.
  • Omega, Phi, Kappa ³⁾.
    Reference direction is pointing eastwards, but can be customized.
  • Normalized direction and up vector (direction Easting, direction Northing, direction Elevation, up Easting, up Northing, up Elevation)
• Origin (rotation = 0°) or rotation offset and positive sense of rotation of orientation angles can be customized.

Attributes

Only when using an absolute position and orientation of a reference frame at time of recording, the fixed relative position and orientation for each camera to the used reference frame must be known. Relative position and orientation can be ignored when using the absolute position and orientation of images at time of recording.

Origin (rotation = 0°) or rotation offset and positive sense of rotation of orientation angles can be customized.

Metadata is optional, there is no limitation on the number of added image meta-attributes on import.

• date
• timestamp
• date time
• accuracy
• GPS information
• photo group id
• …

Panoramas (spherical or 360° images) are optional for Orbit MM Desktop products. The Orbit MM Publisher requires the availability of spherical images (panoramas) to operate.

Supported formats
Preferably .jpg files.
But any supported image resource can be used.

Supported types
Orbit supports any Spherical and Cubic Panorama, independently of file size or pixel resolution.
For example, Ladybug 3 and 5 are supported.

When working with Spherical panoramic images Orbit is using the stitched 360 x 180 degree panoramic image.

• Stitching the images should be done by the camera software, knowing and applying all camera calibration and distortion parameters.
• The centered pixel of the picture will be used to affect the orientation angles. If required this can be re-configured via a customized import.
• Any 2 x 1 pixel resolution ratio can be used but an equirectangular panoramic image should always be 360 x 180 degree.
  There are no limitations on the image pixel resolution. If required Orbit can optimize high resolution images (> 8000 x 4000 pixels) for online use.

Since Orbit AIM version 10.5.1 Cubic Panoramas are supported.

When working with Cubic panoramic images Orbit is using the 6 original equirectangular images.

• To display and use cubic panoramas properly it is required to know all orientation, calibration and distortion parameters from the used camera's.
• Any pixel resolution can be used.

There are no limitations on the number of cameras, the type of camera or the resolution of images. One camera import requires one set of images and one positions and orientations file.

Supported formats
Preferably .jpg files.
But any supported image resource can be used.

Supported types
Orbit supports any distorted Planar picture, independently of file size or pixel resolution.

For each camera following camera and sensor specifications will be used to optimize the integration and accuracy in Orbit.

A trajectory of the mobile mapping vehicle is optional and can be used to display the accuracy or to adjust, clip or extract a segment of the entire mobile mapping run.
Prepare the trajectory file in the same way as the image position and orientation file : see above.

LiDAR point cloud or point cloud derived from dense matching.
There are no limitations on the number of points, files or the total size.

Required for

• Mobile Mapping: Recommended
• Oblique Mapping: Optional
• UAS Mapping: Strongly recommended

Supported formats

• One or more supported point cloud resources, see Supported Geodata Resources.
• Preferred: *.las files.

Notes

• CRS: can be expressed using any supported coordinate system.
  After import, it is strongly advised that all mobile mapping resources use the same coordinate reference system. If required coordinates can be re-projected or transformed on import.
• Timestamps: Time at recording, see “Special Notes” above.

Additional Notes for ASCII text files
When using an Ascii text file as point cloud import it is possible to configure the data-structure :

• Flat ASCII text file, separated, columns and column headers
• R, G, B, I value ranges 0-25, values may be empty
• Character to define end of line

A Digital Terrain Model or Digital Surface Model covering the same area as the Mapping Resources.
Both a DTM or DSM can be used, but we recommend DTM for measurements and navigation.
Wikipedia, Digital Elevation Model.

Required for

• Mobile Mapping: Optional
• Oblique Mapping: Recommended
• UAS Mapping: Optional

Supported formats

• One or more supported raster resources, see Supported Geodata Resources.
• Preferred : single raster geotif file.

Notes

• CRS: Any supported projected coordinate system can be used.

Any supported reference data can be added into Orbit. Reference data is not part of a Run or a Project.