Here is a small validation method for point-table exports. It does not test whether a CSV reproduces a complete map. Google's KML reference distinguishes Point, LineString and other geometries; a tool that exports point rows may intentionally omit a route or polygon.

Define the expected result before exporting

Use two tiny, fictional KML documents:

KML coordinates are longitude, latitude, optional altitude. The exact decimal strings are useful test values because a swap or premature rounding is obvious. If your workflow needs the omitted line, a polygon, styling or coordinate reprojection, use a GIS export that handles those features and keep the original map.

Run six assertion groups

Save the two exported files as points.csv and mixed.csv. This Python script expects the column names and protective Note behavior shown in the table; adapt those parts if your exporter uses a different schema. Reading with utf-8-sig handles a UTF-8 BOM if one is present, while newline="" lets Python's CSV parser handle quoted multiline fields.

import csv


def read_rows(path):
    with open(path, encoding="utf-8-sig", newline="") as stream:
        return list(csv.DictReader(stream))


points = read_rows("points.csv")
mixed = read_rows("mixed.csv")

# 1. Did the ordinary point document yield both locations?
assert len(points) == 2

# 2. Did coordinate order and source precision survive?
assert (points[0]["Longitude"], points[0]["Latitude"]) == (
    "-0.125700", "51.508500"
)

# 3. Is explicit zero different from missing altitude?
assert (mixed[0]["Altitude"], mixed[1]["Altitude"]) == ("0", "")

# 4. Did both Points inside one placemark become separate rows?
assert [(row["Placemark ID"], row["Point number"]) for row in mixed] == [
    ("pair-003", "1"), ("pair-003", "2")
]

# 5. Did quoting and Unicode survive a CSV round-trip?
assert points[0]["Name"] == 'Café, "North"'
assert "\n" in points[0]["Description"]

# 6. Did text identifiers survive, and what did text protection do?
assert [row["Data: Site code"] for row in points] == ["001", "002"]
assert points[1]["Data: Note"] == "'=1+1"

That last Note assertion is specific to an export made with formula-like text protection enabled. Other exporters may escape the cell differently or leave it unprotected; set the expected value to match your intended safety policy. OWASP's CSV injection guidance explains why text beginning like a spreadsheet formula needs deliberate treatment. Do not assume any CSV escaping choice is safe in every spreadsheet and workflow.

The mixed document also contains one LineString. Check the source and the converter's exclusion or partial-export message before accepting the two-row CSV. If the message is absent, the script cannot tell whether the line was intentionally excluded or silently lost. Treat that as an unresolved conversion result, not a successful full-map export.

Finally, import the CSV into Excel with the Site code column explicitly set to Text. CSV does not specify column types, and Excel may strip leading zeros when it interprets 001 as a number. Microsoft's import guidance describes the Text/CSV import path and the text-type choice. Validate the file before spreadsheet import, then compare what the spreadsheet displays.

Optional reproducible files: I work on TimeToTime, which publishes the synthetic KML and expected-CSV fixture pack used for these checks. It includes both KML inputs, expected CSVs and reuse instructions. You can copy or adapt the original sample files without attribution or a backlink. The method above also works with your own fixtures and exporter once you specify its intended columns and exclusions.

Disclosure: This article was prepared with AI assistance. Its assertions were run against the synthetic files in the project repository.