简介：Google Earth中文使用手册是一份面向地理爱好者、旅游规划者及初学者的详细操作指南，全面讲解这款虚拟地球仪软件的核心功能与使用技巧。内容涵盖主界面各类工具、地标绘制、路线漫游、三维地形观察与4.3版新增特性，并针对Windows、Mac和Linux平台列出系统配置要求，帮助读者快速上手并解决实际应用中可能遇到的性能与兼容问题。资源为单个doc文档，压缩包总大小1.94MB，便于直接阅读与检索。目前已有351人学习使用，适合希望系统掌握Google Earth操作、进行地点查找、路线规划或三维地形探索的用户。文档从入门界面逐项展开，再到具体场景操作，图文配合清晰，能让读者按章节循序渐进，获得从基础浏览到高阶功能的完整认知。

1. Google Earth中文使用手册：影像、测量和KML，真正能落地的三块拼图

拿到一份 Google Earth 中文使用手册，多数人第一反应是“卫星图谁不会看”，但真正把 Google Earth 用成生产工具的人，十有八九卡在三件事上：影像和实测坐标对不上、历史影像不知道怎么看、画好的点位和范围导不进 CAD。这篇手册要把这三块拼图拆开讲透。它面向的不是泛泛的看图用户，而是测绘、规划、土木、农林和环境评估方向的从业者——你要用影像做地块核对、做区域调研、给客户汇报，还要把成果导出成 KML 继续流转。看完你可以按章节直接操作，也能避开那些让新手反复返工的隐形坑。

2. 中文界面下从安装到出图的完整链路：选项、地标与测量工具

2.1 安装后的语言、缓存与图形模式：先定这三个选项再开工

安装包从官方渠道获取后，第一件事不是急着找地点，而是把界面语言、缓存目录、图形模式和单位这四项设好。界面语言在“工具 - 选项 - 常规 - 语言”下拉里切换，选“中文（简体）”即可。需要注意，部分版本的菜单在第一次启动时仍显示英文，切换语言后需要完全重启程序才会生效；还有少数专业选项即使切换后仍是英文，这类词集中在“3D 视图”和“网络链接”面板里，不影响主流程。

缓存目录的设置在“工具 - 选项 - 缓存”里。默认缓存会写在系统用户目录下，如果工作区偏大、历史影像看得多，建议把缓存位置挪到剩余空间充足的硬盘分区，并把缓存上限调高。这个动作的作用在浏览历史影像时尤其明显——没有足够缓存，时间滑块每次拖动都要重新拉取影像瓦片，体验会非常卡。另一个高频影响体验的选项是“3D 视图 - 图形模式”，旧电脑或核显机器上出现画面白屏、花屏，多半是图形模式与显卡驱动不匹配，改成 DirectX 或 OpenGL 再重启即可。

单位设置也在这里一并完成。“工具 - 选项 - 3D 视图 - 显示单位”里把单位切换到公制（米、公里），否则测量结果默认跟着系统区域走，可能显示成英尺和英里。做工程的人如果拿到的测距结果是英尺，整个换算过程非常容易翻车。四个选项设完以后，无论后边是量距离、画范围还是导出图像，底层的显示逻辑都是统一且可预期的。

2.2 地标与文件夹：用分层文件夹把零散点位管成项目数据

大部分人在 Google Earth 里标记点位的方式是直接点“添加地标”，然后在地图上扔一个图钉。这个做法在点位少于十个时没问题，一旦涉及多区域、多批次的外业点位，图钉很快就会变成一团无法管理的彩色点。我一般会从一开始就建立文件夹层级：先添加一个文件夹，命名成项目名称；项目下面按区域或按日期再建子文件夹；地标只放在最末层。

添加文件夹的路径是“添加 - 文件夹”，也可以在地图左侧的“位置”面板里右键选择“新建 - 文件夹”。地标可以拖拽进文件夹里，拖拽后层级关系会保留在保存出的 KMZ 中。地标的属性设置里能改图标样式、颜色和不透明度，建议把不同状态的点用颜色区分，比如“待核实”用黄色、“已核实”用绿色、“存在争议”用红色。这个习惯能让你在后续批量导出和汇报时少走很多回头路。

地标还有一个容易被忽略的属性页——“视图”。勾选“将当前视图设为主体”后，双击这个地标时，画面会精确回到你记录的视角高度和朝向。对外业数据整理来说，这个功能相当于给每个点位存了一张“当时是怎么看这个位置的”快照，比单纯记经纬度有用得多。

2.3 标尺测量：测距、测面积与地形剖面，哪些数据能直接写进报告

工具栏里的“标尺”是日常使用频率最高的测量入口。它提供了直线、路径、多边形、圆、3D 路径和 3D 多边形六种测量方式。测量完成后结果会显示在对话框底部，同时地图上会留下一条临时的测量线。需要特别注意一个细节：默认测量的是“在地面上的距离”，也就是顺着地形起伏的路径长度；如果你需要的是两点间的平距，要在标尺面板里切换计算方式。这个区别在山区项目里可能带来百分之几的差距，写报告时要注明采用的是哪种距离。

多边形测量在界面上是逐点点击形成闭合范围，闭合后会直接给出面积和周长。这个数据我一般当作概算值使用——手绘点多、影像分辨率有限，面积精度只能到“量级正确”。地形剖面则是沿着你画出的路径，在面板下方生成一条高程曲线，能直观看到沿途的高低起伏。对线路踏勘来说，这个剖面图可以提前判断哪些路段有较大的爬升，减少外业时的盲目跑路。

测量结果如果要写进报告，建议同时截图保存标尺面板和地图视图。截图里需要包含比例尺和图例，这样别人回看时才知道这张图基于什么影像、大概多大范围。比例尺的显示可以在“视图 - 比例图例”里打开，导出图片前确认它已经在画面上。

3. 历史影像与时间滑块：多期比对的操作流程和判读依据

3.1 打开时间滑块：先判断这个区域到底有哪些年份可用

历史影像功能藏在“视图 - 历史影像”菜单里，开启后地图上方会出现一个时间滑块和一个时钟图标。滑块上会标注出当前区域可用的影像年份范围，但这里有一个常见的理解偏差：时间轴上标出的日期是“影像发布/合成日期”，不代表这一整年都是那个画面。很多区域一年只有一两期可用影像，还有的区域只有特定月份的图，拖动滑块时画面往往在几个时间点之间跳变，而不是连续变化。

我的习惯是先把时间滑块拉到最早，然后再拖到最晚，快速过一遍看看这个区域到底有几期图、覆盖的年份是否连续。这一步能直接判断后续“多期对比”有没有可操作性。部分区域只有一期影像，时间滑块甚至不会出现；这时候强行做历史对比没有意义，应该换数据源而不是在软件里耗时间。

时间轴的用法不难，但有几个操作细节值得记住：滑块两端的“<”和“>”按钮可以逐期切换；直接拖动滑块会连续预览；点击时间段左侧的日历图标可以从全年日期里精确选择某一天。对工程场景来说，逐期切换比拖动更实用，因为你能明确知道当前画面属于哪一期，而不是在滑块移动过程中丢失位置感。

提示：时间滑块是否出现取决于该区域的影像历史数量。如果打开后没有任何反应，先放大到具体地块再尝试。

3.2 多期影像对比：三种常用办法，按需求选一种

多期对比这个需求，最常见的三种做法分别是时间滑块直接切换、双窗口截图对比和图像叠加层比对，前两者不需要额外数据，第三种适合把老地图或扫描件叠加到当前影像上。时间滑块直接切换适合快速口头汇报——你在一个点位上来回拖年份，观察建筑物或地表变化，直观但留不下可交付的对比成果。

双窗口对比是提交成果时更稳妥的做法：把视角固定在某地块正上方，记录下当前视角的经纬度和高度；切到历史年份，导出该年份截图；再切回最近年份，导出同视角截图；最后把两张图放进报告里左右排列。这里最关键的约束是视角完全一致，导出前务必确认画面正北朝上、无倾斜角度、关闭 3D 地形和 3D 建筑，否则两张图在视觉上会对不齐，判读时容易被误导。

图像叠加层是处理老图纸场景的利器。入口在“添加 - 图像叠加层”，选择本地图片后，通过拖拽四角把图片匹配到当前影像上，再调整透明度来查看吻合程度。我做区域边界核对时常用这个方法把 CAD 导出的范围线图叠到影像上，快速发现图纸和现状之间的偏差。透明度调节是比对的关键，初期透明度调到 50% 左右方便对齐位置，确认匹配后降到 20% 左右再细看差异。

3.3 变化判读的依据：哪些差异能作为专业证据，哪些只能算参考

判断影像变化能不能作为正式结论，核心看三点：影像日期明确、分辨率足够识别地物、变化特征清晰无歧义。建筑是否新建、道路是否贯通、水体范围是否扩大，这类容易被不同人一致判读的变化，可以作为佐证材料；而植被颜色深浅、地表纹理差异这类受季节和光照影响较大的变化，建议只在内部讨论时使用，不要直接写进对外报告。

判读时还有一个容易忽略的点：影像的侧视角。Google Earth 里大部分影像以近乎垂直的角度拍摄，但山区或城市高楼区域会有一定侧视倾斜，导致建筑顶部和底部的投影位置不一致。判读高度变化时，要选择同一时期的相邻区域影像做参照，而不是只看单张图。导出对比图的保存路径是“文件 - 保存图像”，保存对话框里可以勾选“图例”和“比例尺”，务必保持勾选状态，这是让截图“像正规报告配图”的最低要求。

历史影像做变化检测的完整工作流，我在实际项目里通常是：确认时间滑块可用日期→固定视角→导出早晚期截图→在报告里左右排布→每张图下方标注影像日期和判读结论。这套流程虽然朴素，但胜在可追溯、可复核；比临时截几张图堆在一起有效得多。

4. 把点位和范围变成KML：手绘、脚本批量生成与KMZ打包

4.1 在地图上画路径与多边形：从手绘到坐标粘贴的精修

手绘路径和多边形的入口在工具栏的“添加路径”和“添加多边形”。实际操作时，逐点点击地图形成折线或闭合区域，画完后可以在属性面板里继续编辑。路径的顶点可以拖动，也可以双击删除；更精确的做法是直接在属性面板里找到“坐标”选项卡，里面以文本形式列出了每一个顶点的经纬度。

这个坐标文本框是连接外部数据的桥梁。比如你在 CAD 里已经有一圈范围线，想把它叠加到 Google Earth 影像上核对，最常见的做法就是把 CAD 里的顶点坐标整理成“经度,纬度,0”格式，一行一个顶点，整体粘贴到路径的坐标文本框里。注意顺序必须是经度在前、纬度在后，高程写 0，这是 KML 坐标格式的第一个大坑，后面章节会专门说。

多边形属性里还可以调整填充色、边框颜色和透明度。用来表达地块范围时，我通常把填充透明度降到 30% 左右，边框用高对比度颜色，这样底下的影像细节不会被遮死。这类视觉参数不影响数据本身，但影响导出图片后的可读性，颜色设置还是要花一点时间调到位。

4.2 用脚本批量生成KML：从点位表到Placemark的自动化模板

点位多的时候，逐个在地图上点地标纯属浪费时间。常见做法是先用 Excel 或 CSV 管好点位表，再用脚本批量生成 KML。下面这个 Python 脚本是我常用的最小模板：读一个带“名称、经度、纬度”的 CSV，生成包含多个 Placemark 的 KML 文件。

#!/usr/bin/env python3 # -*- coding: utf-8 -*- """批量生成地标 KML：从 CSV 读取点位，输出 UTF-8 编码的 KML""" import csv from xml.sax.saxutils import escape KML_HEADER = """<?xml version="1.0" encoding="UTF-8"?> <kml xmlns="http://www.opengis.net/kml/2.2"> <Document> <name>{folder}</name> """ KML_FOOTER = "</Document></kml>" def placemark(name, lon, lat, desc=""): # 坐标顺序是经度,纬度,高程；高程可省略，但保留 0 更安全 return f""" <Placemark> <name>{escape(name)}</name> <description>{escape(desc)}</description> <Point> <coordinates>{lon},{lat},0</coordinates> </Point> </Placemark> """ output = [KML_HEADER.format(folder="外业点位")] with open("points.csv", encoding="utf-8") as f: for row in csv.DictReader(f): output.append(placemark( row["名称"], float(row["经度"]), float(row["纬度"]) )) output.append(KML_FOOTER) with open("points.kml", "w", encoding="utf-8") as f: f.write("\n".join(output)) print("已生成 points.kml，可直接拖入 Google Earth")

这段脚本的逻辑并不复杂：先拼接 KML 文件头和 Document 标签，然后逐行读取 CSV，把每个点位生成一个 Point 类型的 Placemark，最后收尾并写入文件。关键点在于三处：一是文件编码强制 UTF-8，二是对名称和描述做了 XML 转义，避免地名里出现“&”这类特殊字符导致 KML 解析失败，三是坐标格式严格按“经度,纬度,0”生成。

参数说明：CSV 文件必须包含“名称”和“经度、纬度”三列，如果表头不同，修改 DictReader 后面的字段名即可。经纬度使用 WGS84 坐标。生成后把 KML 文件直接拖入 Google Earth 左侧“位置”面板即可预览。后续如果要生成路径或多边形，只需把 Point 部分替换成 LineString 或 Polygon 的 coordinates 文本块，结构是一致的。

4.3 KMZ打包与分发：图片跟随、相对路径与文件自检

KMZ 本质上是一个 ZIP 压缩包，里面至少有一个 doc.kml，还可以包含地标描述里引用的图片、图标等资源。在 Google Earth 里，右键任意文件夹选择“导出为 KMZ”，系统会把该文件夹下的所有地标和引用资源一并打包。这个操作是分发项目数据的标准方式，比单独发 KML 文件更不容易丢图。

打包时最值得注意的问题是描述里的图片路径。如果地标描述里写了<img src="C:\照片\现场.jpg">这种绝对路径，别人拿到 KMZ 后图片一定显示不出来。正确的做法是把图片放在与 KML 同级的 images 目录下，描述里的路径写成相对路径，比如images/现场.jpg。分发前可以用解压工具打开 KMZ，检查 doc.kml 和资源文件的相对位置是否正确。

还有一类坑是图标资源缺失。自定义了地标图标后，如果图标文件没有被打包进 KMZ，对方打开时会看到默认图钉。导出的 KMZ 发出去之前，最稳妥的自检方式是在干净的机器上导入一次，确认地标名称、图标、描述图片都完整，再正式交付。这一步血泪经验告诉我，永远不要在本地看起来正常就默认别人打开也正常。

5. 中文使用场景避坑指南：坐标偏移、乱码与面积误差的排查办法

5.1 影像和实测坐标整体偏移：先做基准校核再谈精度

现象：手持设备或测量仪器记录的坐标轨迹导入 Google Earth 后，整体偏移了几十米，而且偏移方向基本一致，像是整张图被“推”了一下。

原因：Google Earth 的影像底图在不同地区可能采用不同的坐标基准；而国内常见的移动端地图数据为了兼容民用定位，会在 WGS84 基础上做一次加密偏移。两者叠加后，就会出现影像上的位置与实际坐标系统性偏差。

解决：先不要急着调整数据，找一个影像上清晰可辨、且已知准确坐标的公共点做基准校核。比如道路交叉口、桥梁端点或大型建筑的角点。取该点在影像上显示的位置和已知坐标的差值，算出平面偏移量，再把整份轨迹做整体平移。需要提醒的是，这个平移量只在局部范围内有效；跨越大范围区域时，偏移方向和大小可能变化，稳妥的做法是分区校核、分区平移。做完平移后再随机抽几个点复核，确认残差在可接受范围内再进入下一步。

5.2 中文名KML乱码与历史影像“发糊”：两个容易被忽略的显示层问题

现象：在 Google Earth 里正常显示的中文地标名称，发给别人后用其他 GIS 软件打开是乱码；另一个情况是历史影像拖到某一年，画面明显“发糊”或偏色。

原因：乱码几乎都是编码问题。Google Earth 对 KML 的解析以 UTF-8 为准，但很多文本编辑器默认用 GBK 或 ANSI 保存文件，导致 XML 声明和实际字节不一致。影像“发糊”则是因为时间轴标记的日期是“可用影像合成日期”，某些日期可用的原始影像质量较差，色彩和清晰度都不如邻近的其他年份。

解决：写 KML 时统一用 UTF-8 编码保存，不要用记事本的默认编码，也不要给文件加 BOM 头。检查办法是用支持编码切换的编辑器打开 KML，看中文是否正常；或者用浏览器的“开发者工具”直接请求本地文件，乱码会立即暴露。影像偏色的解决方法是换一个相邻日期：点时间滑块两侧的箭头逐期切换，找到画质最好且变化趋势符合预期的那个年份。不要把时间轴上的日期当成唯一的可用期，多切几次。

5.3 面积误差与导出白边：测量和出图环节的最后两道坎

现象：多边形工具量出的地块面积与实测面积相差明显，有时差出好几个百分点；导出高清图片时，画面周边出现一片没有影像的灰色或白色区域。

原因：面积误差有两个来源。一是手绘边界与真实地物边界的贴合程度，这是操作层面的误差；二是 Google Earth 在较大范围内显示的是球面投影下的概算面积，跨带或大范围区域时，与本地投影坐标系下计算出的面积存在系统性差异。导出白边则是视图中心与已加载影像区域不匹配造成的——你把视图缩得太远，附近区域还没有加载出影像就触发了导出。

解决：面积数据以概算对待，最终以本地投影坐标系下的计算为准。做法是把多边形导出成 KML，再由 GIS 软件转成正确的投影坐标系后计算面积，这部分在下一章展开。导出图片时，先把视图中心点放到目标区域，再适当放大到影像完整加载，确认整个画面没有灰色区域后再拉回需要的范围；关闭 3D 地形和大气层也能减少渲染不全的概率。导出后用看图工具放大检查一次边界，别让白边毁掉整张汇报图。

6. 进阶：用矢量导出做交叉验证，别让Google Earth的成果直接交付

6.1 用ogr2ogr做一次KML到GeoJSON的转换验证

KML 是 Google Earth 的原生格式，但它不是测绘交付的标准格式。我自己的习惯是：所有要从 Google Earth 里拿出去的量测成果，先转成 GeoJSON 或 Shapefile，再到 GIS 软件里叠加实测控制线做交叉验证，验证通过后才进入正式成果。转换工具有很多，命令行里最常用的是 ogr2ogr，它包含在 GDAL 工具集中。

ogr2ogr -f GeoJSON output.geojson input.kml \ -lco COORDINATE_PRECISION=6 \ -lco RFC7946=NO

这条命令把 input.kml 转换成 output.geojson。COORDINATE_PRECISION=6表示保留 6 位小数坐标，大约对应 0.1 米的精度，足够支撑大多数工程场景；RFC7946=NO是让输出坐标顺序保持“经度,纬度”的传统顺序，避免某些软件读入后经纬度颠倒。转换完成后，把 GeoJSON 拖入 GIS 软件，叠加你手头已有的实测道路线、控制点或影像底图，逐个检查边界与实测数据之间的偏差。

交叉验证的重点不是看“差多少米”，而是看“偏差是否有规律”。如果所有点位都朝同一个方向偏移，说明是坐标基准问题，回到第 5 章做平移校核；如果只有个别点位偏差大，说明那些地方的边界画得不准，需要回到 Google Earth 里重新编辑对应地标或多边形。这个流程走一遍，比直接拿 KML 交付省下的返工时间，远多于转换本身花掉的几分钟。

我遇到过的最深刻的教训，是一次直接把 KML 范围线发给了合作方，对方叠加到自己的影像底图上后，发现整条范围线偏移了几十米，险些导致现场放样全部返工。后来我养成了“凡输出必验证”的习惯——Google Earth 的影像再清晰，也只是参考底图；正式成果必须回到专业软件里，用受控数据交叉确认。即使只是自己核对用，花两分钟转一次格式，也比带着未知偏差交付要踏实。希望这套流程和踩坑记录能帮你把 Google Earth 真正用成顺手的生产工具，而不是一个看图的玩具。

本文还有配套的精品资源，点击获取