How to Export RTK Points to Google Earth

Prepare a review package, not just an overlay

A useful RTK handoff pairs the KML or KMZ with the information needed to interpret it. Include the source filename, coordinate reference, units, height convention, and the control points used for checking. Label separate occupations or survey dates when they are displayed together. If a point was excluded, note the reason instead of silently removing it.

For recurring site reviews, keep a simple comparison routine: open the latest output, check two known points, compare the project boundary, and scan for unexpected clusters or gaps. If the overlay changes after a source update, record whether the cause was new observations, a field mapping change, or a coordinate-system correction. This makes the geographic view useful to both GIS users and survey teams without overstating what it proves.

When sharing externally, remove unrelated project files and retain only the source context needed to interpret the output. A clear filename and a short read-me note can prevent a geographic preview from being mistaken for the complete survey deliverable. Review the RTK to Google Earth workflow before preparing a repeat handoff.

If the geographic view is used in a meeting, keep a copy of the checked control points and the source reference nearby. That context helps the team discuss what the overlay shows without treating visual alignment as a survey certificate.

Keep the review date and coordinate reference with the file.

Record who performed the check and which points were compared.

What makes RTK data different to review

RTK and GNSS point files often arrive with more coordinate context than a simple local point list, but that context still needs interpretation. Identify the horizontal reference, height or elevation convention, units, and any field coding used for quality or occupation status. A point can be precise in the field and still appear in the wrong place if the file is mapped to the wrong coordinate system or if latitude and longitude are reversed.

Google Earth is useful for a visual geographic check. It is not a substitute for the survey record. Treat the KML or KMZ as a review-oriented handoff and keep the original RTK file available for comparison.

Step-by-step RTK to Google Earth workflow

1. Identify the coordinate context

Before uploading, note whether the source is already in geographic coordinates or in a projected grid. Record the datum, units, and height convention supplied by the survey workflow. If the file contains multiple jobs or occupations, separate them or label them clearly so the geographic preview does not mix unrelated points.

2. Import and inspect the point fields

Upload the supported file to the TopoAssist browser workspace and map point ID, horizontal coordinates, and elevation deliberately. Scan for blank coordinates, duplicated IDs, decimal-format problems, and values outside the expected region. Review several control or check points against the field notes before preparing any geographic output.

3. Review the spatial pattern

Use the 2D view to confirm that the footprint, orientation, and point density match the project. If the project includes terrain interpretation, generate contours or inspect the related TIN surface as an additional check. A cloud that lands in the wrong country, appears mirrored, or has an extreme vertical pattern is a reason to stop and revisit the source context.

4. Prepare KML or KMZ

Select the supported KML or KMZ output for the next Google Earth-oriented review. Keep the filename descriptive and record the coordinate-system choice and preparation date. If the receiving person needs the original survey attributes, send the source or a separate handoff note as well; a geographic overlay alone may not preserve every field detail.

5. Verify in Google Earth

Open the actual output in Google Earth and compare its location with known roads, control points, or site boundaries. Check that the extent is plausible, labels are readable, and the elevation interpretation is understood. Compare at least two known points with the source record before sharing the file more widely.

Common mistakes and practical tips

• Confusing projected and geographic coordinates: identify the source reference before mapping fields.
• Reversing latitude and longitude: use a known point to confirm axis order.
• Mixing height conventions: note whether values are ellipsoidal, orthometric, or project-specific before interpreting the view.
• Exporting all occupations together: keep jobs and control points labelled so the overlay remains understandable.
• Trusting a visually plausible location: compare control points; a nearby-looking overlay can still be shifted.

Limitations and verification note

TopoAssist helps organize a browser-based import, review, and supported KML/KMZ preparation workflow. It does not resolve an unknown datum, recover missing field metadata, or certify RTK quality. Confirm coordinate-system information, source-data quality, and the geographic result with the project’s normal professional checks.

Begin with coordinate awareness

Before preparing KML or KMZ, identify the coordinate-system information supplied with the survey points and confirm that the input is appropriate for the intended geographic view. Do not treat an exported view as proof that the source data is correct.

TopoAssist supports KML and KMZ among its browser-based GIS export options. Current access can vary, so review the available option before beginning a handoff.

Use a review-first workflow

Keep the limitations visible

FAQ

Related resources

Read about RTK points for Google Earth, compare KML and KMZ export, review features, or see pricing.