A receiver can show a valid position while the delivered GIS point is still wrong for the project's map or height reference. The field team may save coordinates in one reference system, display them against another, and export a file whose Z field means something different from the receiver's altitude. The deliverable therefore needs a traceable path from receiver output through the field application and layer to the file handed to the GIS team.
This guide is for field-data integrators and rugged-tablet buyers planning that handoff. It addresses coordinate and height meaning, not whether a receiver can achieve a specified survey accuracy. A status such as RTK fixed is useful metadata, but it cannot by itself certify the final coordinate or elevation.
Name the reference system at every handoff
Before collection, name the receiver or correction service's coordinate reference system, the map or basemap system, the editable layer system and the requested export system. Record the horizontal datum or reference frame, projection if used, units and, where material, the epoch and area in which a transformation applies. A field called latitude or an EPSG code pasted into a spreadsheet is not enough if the team cannot say which value was observed and which was transformed.
Esri's current ArcGIS Field Maps high-accuracy collection guide describes a location profile that identifies the receiver's and map's coordinate systems and applies a horizontal datum transformation when required. It also warns that Field Maps itself supports horizontal, not vertical, datum transformations in that profile. This is a named application workflow, not a claim that an AIDC GO tablet runs Field Maps or supports a particular receiver.
Assigning a known coordinate system to an otherwise undefined dataset is different from converting its coordinate values. Esri's Define Projection tool changes stored coordinate-system information without changing geometry; its Project tool produces coordinates in a different system and may require a specified geographic or vertical transformation. If the source definition is wrong, relabelling it as the target does not repair the field observation.
Keep the height pathway explicit
An ellipsoidal height, an orthometric height referenced to a geoid, the antenna's measured height above the point and the saved feature's Z are different fields. Esri's supported GPS metadata defines its Altitude metadata as ellipsoidal height in metres, while its Orthometric height metadata is a separate receiver value. The same document describes GNSS antenna height and a receiver geoid-model field. It says Field Maps records an orthometric Z based on the receiver's geoid model and that another required geoid model calls for postprocessing.
Do not infer a vertical datum from a label such as altitude, height or Z. For the named application and receiver, identify whether antenna-height correction has already been applied, which geoid or height model produced an orthometric value, and what the layer actually stores. A horizontal location profile does not prove a vertical conversion occurred. An offline team must have any required horizontal grid files on the device before collection; a different vertical model may require a documented later processing step. Neither an online map preview nor a fixed-solution badge supplies the missing transformation history.
Follow one explicitly hypothetical record to export
Consider an invented point, not a surveyed control mark. Assume the approved receiver, field map, editable layer and delivery file all use the same named horizontal system, CRS-A, so this example requires no horizontal conversion. The receiver reports latitude_raw = 34.000000°, longitude_raw = -117.000000°, ellipsoidal_height = 245.20 m, orthometric_height = 210.00 m, antenna_height = 2.00 m and a named GEOID-X model. These numbers are teaching values, not measurements, a real geoid solution or an AIDC GO performance claim.
For this editorial record only, assume the receiver documentation confirms that its reported position is already corrected to the survey point using that antenna-height setting, and the project accepts the receiver's named orthometric-height pathway. The field application stores the unchanged horizontal coordinates in CRS-A and, under its verified configuration, saves feature_z = 210.00 m with the project's stated height reference. The export retains the same coordinate values, the horizontal and vertical definitions, units, receiver/source fields, geoid-model name, antenna-height method, fix time and transformation history marked “none for horizontal; receiver orthometric pathway for Z.” It must not quietly substitute 245.20 m simply because a receiving system calls its field altitude.
If the target GIS instead requires CRS-B or another height model, this example no longer supplies valid output coordinates. The team must select an approved transformation for the project area, run it in the specified software and version, retain the source values and method, and inspect the resulting file. It should leave the transformed result pending until the actual method and files are known—not invent an offset or move points by eye. A change of units or axis order must also be recorded rather than inferred from a map display.
Accept the exported file, not just the field screen
At handoff, open the actual delivered file in the target GIS and inspect a known control point under the project's stated horizontal and vertical references. Compare the receiver metadata, stored feature geometry, exported coordinates and Z, transformation record, units and any offline grid or geoid dependencies. Check a record where quality status changed and one where a height field is absent. The project's survey or GIS authority decides the tolerance and whether recollection, correction or rejection is needed; this guide supplies no universal precision value.
The GNSS/DGNSS/RTK configuration guide addresses the receiver, antenna and correction chain. The external-receiver data-path guide asks whether the field app actually uses that receiver. This guide begins when a position has been collected and asks whether the final coordinates and height can be interpreted and imported consistently.
Use Rugged Tablets and Rugged Tablet Field Operations to discuss the host's screen, storage, interfaces and field workflow, then take the named application, receiver, output file and coordinate requirements to Integration Support. Those pages do not establish survey-grade positioning or compatibility for a particular AIDC GO model.