A Standard job format, is an interchange format that an Orbitas field job can be imported from or exported to. Upon request, each format will be added to an Orbitas Subscription and can then be optionally redistributed by a Pro (or Subscription Administrator) to groups within that Subscription. I may have gone into slightly too much information on the Shape format. However, that is the one that gets us into issues with most city/state entities so documenting it well I think will help with that.
Standard Exports will look the same for all users. Each format has unique constraints. Please see the details on the constraints of each format. Should a user desire a standard format that has different constraints / schema from what is listed, it can be requested to be upgraded to a "Premium" format. Please see details on premium formats.
Additional Exports Standard for Partner Users:
Additional Exports Standard for AT&T Contractors:
All Standard Exports will have the same parameters as shown below:
DATUM: This parameter (defaulted to WGS84) represents the correction datum that was in use at the time of collection. By default GNSS devices will record Latitude/Longitude/Altitude information in World Geodetic System of 1984, adjusted by epoch to conform with the International Terrestrial Reference Frame. However, it is possible to apply a different "correction datum" in the field. The most common is when utilizing an RTK network that is referenced to NAD83(2011) or NSRS11 (National Survey Reference System of 2011.
It is highly critical to ensure that you select the NAD83(2011) option if exporting from an RTK corrected job in the US, to avoid datum shifts.
LINE_SPAN: This parameter (defaulted to span) allows the user to visualize their "Line" information collected with an Orbitas location as either segments (spans), or as one continuous line. If continuous is selected, lines will be broken at the change of "LineType" attribute or if the parenting ends or forms a loop. * Please note that if Spans are not chosen, span form information will not be properly displayed.
The exception to the line_span is PNEZD format. Due to the nature of PNEZD file types, there is no line to include.
USERDEPTH_UNIT: This parameter (defaulted to feet) allows users that collected data with a supported line locator, to change the units that the depth exports to. * In the KMZ format, this field will also affect the reported accuracy units.
Exports to a compressed, "zip" file with the name of the job that was collected. Once extracted, each job will have a number of shapefiles. Each shapefile consists of a PRJ,CPG,DBF,SHP and SHX file as you can see below. There will be a generic shapefile called "Locations" exported. This will include every location collected, regardless of Location Type. Each "Line Type" will be exported to its own shapefile. If "Form" information is collected for any location or quick feature… a shapefile of that name will also be created.
Foreword: In order to maintain a dynamic schema, Orbitas software utilizes a JSON collection format for its forms. Any Form data exported to a "Standard ESRI Shapefile" Format will be displayed in this JSON format (See the example of EdgeofPavement Below). If it is desired to break these form controls out into individual attributes, a "Premium" export must be created with custom setup and change fees.
PNEZD (or Point, Northing, Easting, Zed, Descriptor) is an industry standard comma delimited text format. It is a common import method to populate many drawing applications. The one unique part of the PNEZD is our descriptor. The Tri-Global Descriptor upon export consists of "Location Type"-"Location Note"-"Depth".
Google KMZ is a zipped folder, containing a Tri-Global formatted Google KML file, plus icons and color schemes as defined in the Orbitas style set for the subscription. This is one of the most complete standard formats due to its dynamic nature and can contain all information included in the configuration, with (1) notable difference.
Attachments (or Photos), photos are now "Reduced" from their original size. They are reduced to be 600 pixels wide. The width of these photos corresponds with their display size within the KML itself. This is an attempt to prevent KMZ files from "timing out" on export. The size of the photos could prevent some KMZ files from being exported in the original format.
Should a user desire full size photos, they can be downloaded directly using the instructions in our "Accessing Photos" documentation: https://www.triglobal.net/orbitas-rms-editor/accessing-photos
A Premium Job Export, is a format that an Orbitas created job can be exported to or imported from as well, however the difference is that a Premium Job Export carries with it an additional cost. The additional cost will consist of a creation and modification cost, as well as an annual maintenance cost. The benefit to this format is that it is created uniquely for each entity that contracts it, and can save hours of time on data management for Tri-Global clients.
The following are all Premium Job formats, some additional criteria may be necessary for some formats:
