信息速览
HydroLAKES 是一份把全世界的湖画成多边形的图集。一个湖一行，一行 21 列，一个岸线一个几何。它不记录水位，不记录水温，不记录任何随时间变化的东西：同一片水，在表里只有一次出现的机会。
这件事决定了它的全部用法。它不是湖泊监测网，也不是湖泊清单的权威版本，而是一张底图——回答「这片水在哪、有多大、岸线有多曲折、水从哪个口子出去」这四个问题，并把答案固定成可以被 GIS 直接吞下的矢量。
它被引用得极多，被误读得也极多。误读几乎都集中在同一处：以为那 21 列里装着观测。实际上，面积来自影像与水系图的边界描摹，体积与深度来自回归外推，流量来自全球水文模型的降尺度结果。整张表里唯一接近「观测」的，是岸线的位置。
| 项目 | 数值 | 依据 |
|---|---|---|
| 多边形数 | 1,427,688 | 技术文档正文与点图层记录数 |
| 最小纳入面积 | 10 公顷（0.10 平方公里） | 技术文档，全表面积最小值 |
| 属性列 | 21 列 | 点图层 dbf 头部字段表 |
| 合计水面 | 267 万平方公里（自然湖） | 技术文档，约合全球陆地 1.8% |
| 合计岸线 | 720 万公里 | 技术文档，约为全球海岸线四倍 |
| 合计蓄水 | 181,900 立方公里 | 技术文档，约为全球非冻陆地水 0.8% |
| 体积来源 | 推算 1,420,699 条、水库报告 6,723 条、湖泊文献 266 条 | Vol_src 字段计数 |
| 水体类型 | 湖 1,420,891、水库 6,687、受调控湖 110 | Lake_type 字段计数 |
| 挂上 GRanD | 6,796 条 | Grand_id 非零计数 |
| 有名字 | 3,022 条 | Lake_name 非空计数 |
| 坐标参考 | WGS84 经纬度，未投影 | 技术文档与 .prj |
| 许可 | CC-BY 4.0 International | 官方产品页原文 |
| 主引用 | 10.1038/ncomms13603 | 官方产品页参考文献 |
§1 速览：它是什么，也不是什么
1.1 一句话定义
HydroLAKES 是一份全球湖泊与水库的岸线多边形矢量库，由 HydroSHEDS 体系在 2016 年发布，覆盖面积不小于 10 公顷的全部水体，每个水体一个多边形、一行属性。
它的定位可以用一句话说清：把「世界上有哪些湖、它们长什么样」这件事，做成一张可以叠加、可以切分、可以挂到河网上的矢量底图。
1.2 三层身份
第一层是几何。142 万个多边形，WGS84 经纬度，没有投影。这意味着面积不能直接从几何算，必须读 Lake_area 列；也意味着跨高纬度做缓冲区时，一度经度对应的距离会缩水，任何基于几何的距离运算都要先转投影。
第二层是属性表。21 列里，七列是身份与归属（编号、名字、国家、洲、多边形来源、水体类型、GRanD 编号），五列是几何与地形（面积、岸线长、岸线发育度、高程、周边坡度），剩下九列是水文推算（体积、库容、体积来源标记、平均深度、流量、停留时间、流域面积、出水口经度与纬度）。
第三层是拓扑接口。每个湖有一个出水口，出水口落在 HydroSHEDS 河网的某个像元上；这个像元的上游汇流累积量被算成流域面积，出水口的流量被算成 Dis_avg。湖因此不是一个孤岛，而是河网上一个带面积的节点。
三层身份里，最容易被忽略的是第三层。多数人把它当一张湖泊分布图用，实际上它真正的设计目的是给全球水文模型提供「湖」这个对象——让水从上游流到湖里、在湖里停一段时间、再从出水口流出去这条链路，能在全球尺度上算得下去。
1.3 三十秒决策卡
| 你的处境 | 它能给你什么 | 你要自己补什么 |
|---|---|---|
| 要在流域模型里放湖泊的调蓄作用 | 每个湖的位置、面积、体积、停留时间、出水口坐标 | 水位—面积—库容曲线，它没有 |
| 要统计某国或某流域的湖泊数量与总面积 | 现成的多边形，按国家、洲、流域面积切分 | 阈值敏感性分析，10 公顷以下没有 |
| 要给河网模型标注「这段河上有湖」 | 出水口坐标，可以空间挂到河段上 | 河段编号要自己做空间相交 |
| 要做湖泊水质或富营养化建模 | 湖的几何与流域面积，作为分层与负荷的底数 | 营养盐、土地利用、人口，全部没有 |
| 要找水库做调度研究 | 被标为水库的记录，以及挂上 GRanD 编号的那一批 | 坝高、装机、调度规则，去 GRanD 取 |
| 要研究湖泊数量随时间的增减 | 无。只有一版 | 整个时间序列，得换数据源 |
| 要一份「全球有多少湖」的权威答案 | 一个特定门槛下的计数 | 门槛之外的答案，它给不了 |
1.4 不适合谁
不适合拿它做湖泊变化监测的人。它没有第二个时相，也没有任何一列带日期。想回答「这个湖十年里缩了多少」，这份数据只能提供起点的一半，终点要去别处找。
不适合需要单个湖的精确深度的人。表里那一列平均深度，对绝大多数湖是回归外推值，官方文档自己写着：单个湖的误差与不确定性可能很大，解读时应当谨慎。做航运、取水、水库设计这类需要真实水下地形的活，它顶多提供一个数量级。
不适合把湖泊数量当成自然事实的人。142 万这个数字是「10 公顷以上、被这八套源数据画出来、并通过了人工剔除」的水体数，不是地球上水体的总数。换一个门槛，数字会换一个量级。
1.5 贯穿本文的案例：乍得湖那 0.1 米
打开属性表，第 15 行是乍得湖。面积 18,751.52 平方公里，体积 2,400（单位是百万立方米，即 2.4 立方公里），平均深度 0.1 米，停留时间 25.6 天，流域面积 980,211.9 平方公里，出水口流量 1,085.078 立方米每秒。
三个数字放在一起，算式是自洽的：2.4 立方公里除以 18,751 平方公里，等于 0.000128 公里，也就是 0.13 米，四舍五入进一位小数就是 0.1 米。体积除以流量，2.4 立方公里除以 1,085 立方米每秒，约 25.6 天。每一步都对。
错的是这三步的输入不在同一个状态上。面积来自多边形，这个多边形是 2000 年前后某一次制图时的水面轮廓，而且它的来源标记是 Other，即团队自己描的，不是从国家水系图里拿的；体积来自文献报告值，报告的是一个水浅、面积小的年份。一个按丰水期画的边界，配一个按枯水期量的体积，商出来就是一个物理上不成立的平均深度：18,751 平方公里的水面只有 0.1 米深，等于一片 1.9 万平方公里的浅碟。
这个案例会在后面反复出现，因为它是这份数据全部陷阱的浓缩：几何是快照，属性是拼装，派生量忠实放大了拼装的裂缝。凡是要用 HydroLAKES 的体积、深度、停留时间做定量分析的人，都会在某一处遇到自己的乍得湖。
§2 数据构成：142 万个多边形是怎么拼出来的
2.1 两个图层，四种打包
产品以两个 GIS 图层发布。HydroLAKES_polys_v10 是多边形，HydroLAKES_points_v10 是出水口点。两者属性完全相同，只是几何一个是面、一个是点。官方把这层意思写在技术文档里：所有版本含有相同的属性信息，面与点的属性表列一致。
打包成四个压缩包：多边形 geodatabase 763 MB，多边形 shapefile 820 MB，出水口点 geodatabase 81 MB，出水口点 shapefile 79 MB。多出来的 57 MB 是两种容器对几何的存储方式不同——同一批坐标，geodatabase 的二进制块比 shapefile 的定长记录更省空间；点图层恰好相反，shapefile 版反而小两兆。
四个包里都夹了一份技术文档 PDF。这一点值得记一笔：数据包自带说明书，不需要再去网站上找。文件时间戳是 2016 年 12 月 13 日，与文档封面的 2016 年 12 月对得上。
2.2 八个来源拼成的一张图
| 源数据 | 覆盖区 | 原格式与比例尺 | 贡献多边形数 |
|---|---|---|---|
| CanVec | 加拿大全境 | 矢量，1:50,000 | 863,550 |
| SWBD | 56°S 至 60°N | 栅格，1 弧秒（赤道约 30 米），矢量化后平滑 | 282,571 |
| MODIS MOD44W | 60°N 以北的俄罗斯 | 栅格，250 米，矢量化后平滑 | 167,435 |
| 美国 NHD | 阿拉斯加全境 | 矢量，1:24,000 | 58,496 |
| ECRINS | 60°N 以北的欧洲与挪威全境 | 矢量，约 1:250,000 | 50,699 |
| GLWD | 全球 | 矢量，1:100 万 | 3,023 |
| GRanD | 全球 | 矢量，1:100 万或更精 | 1,133 |
| 团队自绘 | 全球 | 矢量，1:100 万或更精 | 781 |
| 合计 | 1,427,688 |
这张表解释了一件反直觉的事：全球湖泊数里，六成来自加拿大的一个国家水系图。加拿大有世界上最多的湖，也有少数几个把全国水体按 1:5 万画完的国家测绘项目，两个条件叠在一起，就把这份全球数据的重心压到了北美。
表里还有一处容易忽略的结构：SWBD 覆盖的是 56°S 到 60°N，不是全球。60°N 以北的俄罗斯用 MODIS 的 250 米掩膜补，欧洲北部用 ECRINS 补，加拿大整国用 CanVec 覆盖（包括 60°N 以北的部分）。所以「这份数据的分辨率」不是一个数，而是随经度纬度变化的一个谱。
2.3 十公顷这条线
10 公顷是 0.1 平方公里，相当于一个边长 316 米的正方形。这是纳入门槛，也是这份数据最硬的一条边界。
门槛的执行很彻底。全表面积最小值恰好是 0.10 平方公里，没有一条比它更小。而面积恰好写成 0.10 的记录有 106,083 条，占全表的 7.4%——这不是巧合，是截断造成的堆积：所有真实面积落在 0.095 到 0.105 平方公里之间的水体，四舍五入到两位小数之后都落在这一格上。
这条线决定的不是精度，是本体。小于 10 公顷的水体不叫「没画准」，叫「不在定义里」。一个 8 公顷的池塘，无论多重要，在这份数据里不存在；而一个刚好 10.2 公顷的水库，会以完整的多边形和全套属性出现。跨这条线做任何比较，比如「某地 1990 年有多少湖、2020 年有多少湖」，只要两期数据的门槛不同，结论就一半是水体变化、一半是门槛变化。
还有一条更细的线：湖内小于 3 公顷的岛屿在制图时被移除。所以一个多岛湖的岸线长度，是不含小岛的岸线长度；岸线发育度这个指标，也因此系统性地偏低。
2.4 三种比例尺共存
技术文档承认，最终分辨率无法严格定义——因为源数据比例尺从 1:24,000 到 1:100 万不等，中间又经过栅格化、缝隙清理、平滑、简化。
团队给出的最佳近似是：加拿大与阿拉斯加约 1:100,000（两地合计占全球湖泊数的三分之二）；欧洲与 60°N 以南的其余地区约 1:250,000；北俄罗斯与格陵兰约 1:100 万。
这个梯度对使用者有直接后果。同一个 1 平方公里的湖，在加拿大可能被画成一个带十几个弯的轮廓，在北俄罗斯可能被画成一个近似椭圆。算岸线长度、算岸线发育度、算周长面积比，跨国比较得到的差异里有相当一部分是制图比例尺的差异，不是水体的差异。
2.5 密歇根与休伦为什么算两个湖
密歇根湖与休伦湖在水体上是连通的，中间只隔着一道宽而浅的咽喉。按水文连通性，它们可以算一个湖；按这份数据的约定，它们是两个。
技术文档把这件事专门写了出来：为了符合把两者当作独立单元的一般惯例，它们被拆成两个多边形。表里也能看到这个处理——密歇根的编号是 6，休伦是 8，中间夹着 7 号安大略湖。
这个细节的意义不在两个湖本身，而在它揭示的判据：这份数据的「一个湖」不是水文学定义，是制图惯例加人工判断。同样的模糊地带还有牛轭湖（洪水期变成河道）、季节性湿地（旱季变成草滩）、潟湖（与海隔一道沙嘴）。文档承认，湖、河、湿地的过渡带在任何数据集里都是高不确定区，这份数据只是选择了跟随源数据的既有分类，没有自己去做过程判别。
2.6 只有三千个湖有名字
142 万条记录里，Lake_name 非空的只有 3,022 条，占千分之二。
填充规则写在字段说明里：面积不小于 500 平方公里的湖；GRanD 里有名字的大型水库；GLWD 里有名字的较小湖泊。三条规则之外，一律留空。
于是出现一个使用上的硬约束：你不能靠名字找湖。想定位一个小湖，只能靠坐标、靠行政单元、靠与别的水体数据的空间相交。反过来，名字也不是可靠的唯一键——表里叫 Victoria 的至少有乌干达的维多利亚湖、加拿大的一处水库、澳大利亚的一处水库，三行同名不同湖。
2.7 一个湖一个多边形：溶解的代价
源数据里，一个湖常常被切成好几块：SWBD 按 1 度见方的瓦片分发，湖跨瓦片就被切断；CanVec 的部分省份把湖泊与连接河道画成一个大多边形。
以 SWBD 为主的那一部分，处理办法是先栅格化到 30 米，再在区域尺度上拼接成无缝栅格，用膨胀收缩把瓦片错位造成的细缝补上，最后重新矢量化并做简化平滑。跨瓦片的同一个湖因此被溶解成一个多边形。
代价是岸线被重新采样了两次。一次是栅格化，一次是矢量化。30 米像元的边界不可能比 30 米更精细，简化平滑又会削掉小尺度的曲折。这解释了为什么这份数据的岸线看起来「圆润」——它不是天然的圆润，是处理流程留下的手感。
§3 结构层：21 列属性怎么读
3.1 三组列
把 21 列按用途分组，比按文档顺序读更有用。
第一组是身份与归属：Hylak_id、Lake_name、Country、Continent、Poly_src、Lake_type、Grand_id。这七列回答「这是哪个湖、在哪、谁画的、什么类型、有没有对应的坝」。
第二组是几何：Lake_area、Shore_len、Shore_dev、Elevation、Slope_100。这五列描述形状与位置，其中前三列是纯几何量，后两列是地形量。
第三组是水文推算：Vol_total、Vol_res、Vol_src、Depth_avg、Dis_avg、Res_time、Wshd_area、Pour_long、Pour_lat。这九列是从几何加外部模型推出来的，全部带条件、全部有哨兵值。
分组的意义在于：第一组可以直接用，第二组可以用但要清楚它的制图来源，第三组每用一次都要先看来源标记。
3.2 Hylak_id 是行号，不是编码
Hylak_id 从 1 连续排到全表末号，无缺号。它不是按国家分段的编码，也不是哈希，就是行号。
编号靠前的若干行是人工编排的世界大湖：1 号里海，2 号大熊湖，3 号大奴湖，4 号温尼伯湖，5 号苏必利尔湖，6 号密歇根湖，7 号安大略湖，8 号休伦湖，9 号伊利湖，10 号拉多加湖，11 号贝加尔湖，12 号巴尔喀什湖，13 号大咸海，14 号卡拉博加兹戈尔湾，15 号乍得湖，16 号维多利亚湖，17 号坦噶尼喀湖，18 号马拉维湖。
这十八个编号看起来像按面积排序，实际上不是：7 号安大略湖面积 19,347 平方公里，排在 8 号休伦湖的 59,399 平方公里前面。更像是先按大洲与知名度人工列了一批，之后交给程序批量填。
对使用者来说，这意味着一件事：不要用 Hylak_id 的大小推断任何属性。它只是主键。19 号之后就是普通湖泊，编号大小与面积无关。
3.3 几何三列与岸线发育度
Lake_area 是多边形面积，单位平方公里，两位小数。它是团队在制图流程里算好写进表里的，不是 GIS 打开文件时现算的。这一点很要紧：同一个湖，用工具自带的面积字段量一遍，得到的是按经纬度当平面坐标算出来的平方度，两者不能混用。全球加总用这一列，得到的就是官方那个 267 万平方公里。
Shore_len 是岸线长度，单位公里，同样受制图比例尺影响。
Shore_dev 是岸线发育度，定义为岸线长度与同面积圆周长之比。正圆是 1，越曲折越大。这个指标的设计意图是剥离面积影响，让不同大小的湖可以比较形状复杂度。它有一个已知的性质：对同一片水，观测分辨率越高，量出来的岸线越长，发育度越大。所以跨数据源比较发育度，比的其实是分辨率。
Elevation 是湖面高程，单位米，取湖范围内出现次数最多的像元高程。Slope_100 是湖外 100 米缓冲带的平均坡度，单位度。
3.4 体积列的单位
Vol_total 的单位是百万立方米，一列注释写得很清楚：1 mcm 等于 0.001 立方公里。这是整张表最贵的一个坑。
一条记录的 Vol_total 写着 23,615,000，读成立方公里就是两千三百万立方公里，比全球淡水总量还多；除以一千得到 23,615 立方公里，才是贝加尔湖。
校验的办法很简单：拿面积乘深度，看能不能对上同一行的体积。贝加尔湖 31,967.85 平方公里乘以 738.7 米，得 23,614 立方公里，与 23,615,000 除以 1000 的结果一致。里海 377,001.91 平方公里乘以 200.5 米，得 75,589 立方公里，与 75,600,000 除以 1000 的 75,600 一致。
三列之间这种自洽性是一把好尺子：它能验证单位，但不能验证真值。§1.5 的案例就是自洽但失真的典型。
3.5 深度是商，不是观测量
Depth_avg 的定义写在字段说明第一句：平均水深等于总体积除以湖泊面积。
这句话很短，后果很长。它意味着深度不是独立测量，而是体积的派生量。体积错一千倍，深度跟着错一千倍；面积偏 5%，深度就偏 5%。任何对深度的怀疑，本质上都是对体积与面积的怀疑。
第二层后果是：深度不携带任何形状信息。一个碗形的湖和一个平底锅形的湖，只要体积与面积相同，平均深度就相同。做水温分层、做溶解氧模拟、做沉积物分布，真正需要的是水深分布，而这列只有一个数。
第三层后果与 §1.5 的案例直接相关：当面积与体积来自不同年份、不同来源时，它们的商没有物理意义。乍得湖那 0.1 米不是「湖很浅」，是「两个数不是同一时刻的」。
3.6 Lake_type 只有三档
类型字段的取值只有三个：1 是湖，2 是水库，3 是受调控的天然湖（有调节建筑物的天然湖）。
全表计数：1 有 1,420,891 条，2 有 6,687 条，3 只有 110 条。
这里有两个必须说清的点。
第一，没有盐湖这一类。数据里确实包含咸水湖，里海、咸海、大盐湖、乌尔米耶湖都在，但它们的类型标记都是 1，与淡水湖无法区分。靠 Lake_type 筛盐湖会得到空集，靠名字筛只能筛到有名字的那三千个。
第二，默认值是 1，而且文档明确说：只有被明确识别为其他类型的水体才有别的值，所以「湖」这一类同时兜住了所有未被识别的小型人工水库与调节湖。换言之，6,687 这个水库数是一个下界，不是总数。
第三，110 条受调控湖少得刺眼，但里面包含贝加尔湖、温尼伯湖、维多利亚湖、安大略湖、奥涅加湖。判断依据主要来自 GRanD 的比对，也就是说，只有被 GRanD 收录或有明确文献的调节湖才被标出来。
3.7 Grand_id：唯一的外键
21 列里，唯一一个指向另一份数据的字段是 Grand_id：对应的 GRanD 水库编号，没有对应记录时填 0。
非零的记录有 6,796 条。这个数字与技术文档里「6,796 个多边形与 GRanD 对应并被赋了 GRanD 编号」完全一致。
它的用法很直接：按 Grand_id 把 GRanD 的坝高、装机容量、建成年代、用途、灌溉面积 join 进来，就从一个纯几何库变成了一个带工程属性的水库库。这也是这份数据里唯一不需要做空间运算就能完成的外部连接。
需要注意它的方向性：Grand_id 只覆盖水库，天然湖一律是 0。非零记录与「类型为水库」的记录不是同一个集合，前者还包含一部分被标为受调控湖的水体。
3.8 两种哨兵值
水文列用两种哨兵值表示「没有」。
-1 表示算不出来。Res_time 等于 -1 的有 30,628 条，原因是 Dis_avg 为 0，体积除以零没有定义。Slope_100 等于 -1 的是面积不小于 500 平方公里的湖，坡度没有算。
-9999 表示位置不在有效范围内。Dis_avg 与 Res_time 各有 793 条是 -9999，Wshd_area 同样，原因是出水口落到了 HydroSHEDS 陆表掩膜之外——通常是河口、潟湖、或者多边形本身画到了水上。
这两种值的处理方式不同。-1 是「有湖但算不出」，做统计时应当剔除而不是补零；-9999 是「位置无效」，往往提示这个多边形本身有问题，值得单独看一眼。把两者一起当缺失值处理，会丢掉这个信号。
§4 边界层：哪些数字能信，信到什么程度
4.1 Vol_src 四态：数字的户口
体积这一列不是一个来源，是三个来源按优先级拼起来的。Vol_src 记录的就是优先级。
取 1 的有 266 条：体积是文献报告的湖泊体积。贝加尔湖那 23,615 立方公里、里海那 75,600 立方公里、坦噶尼喀湖那 18,940 立方公里，都属于这一类。这类值最接近「真值」，因为它们来自测深记录或权威汇编。
取 2 的有 6,723 条：体积是 GRanD 或文献报告的水库库容。这一类描述的是「设计库容」或「总库容」，不是某一天的水量。水库的库容随调度常年变化，一个数代表不了它。
取 3 的有 1,420,699 条：体积是模型推算值，占全表的 99.5%。这是绝大多数湖的处境——没有测深，没有文献，只有一个从面积和周边坡度推出来的数。
三者合起来正好是全表条数，一条不多一条不少。这条恒等式本身就是一次质检：它说明 Vol_src 没有空值，也没有第四种状态。
一处对不上的地方值得记下：技术文档说，6797 个大水库或调节湖的库容被并入，主要来自 GRanD；而属性表里 Vol_src 取 2 的只有 6,723 条，差 74 条。差额最可能落在那些被报告了湖泊体积、同时又受调控的水体上——文档说这类湖取「报告库容与湖泊体积中的较大者」，取值最终落在 1 而不是 2。文档没有明写，这里只把它当作一个对账时的已知缺口。
4.2 五百平方公里这条暗线
体积的处理在 500 平方公里处换了一次手。
面积在 0.1 到 500 平方公里之间：深度由回归模型给出，体积等于深度乘面积。
面积大于 500 平方公里：深度改从文献取，来源是 170 份文献，主源是 1982 年那份全球大湖汇编。
这条线的存在有充分理由。大湖的湖盆形状复杂，面积与周边坡度的关系解释不了它们的深度——贝加尔湖的深度来自一条裂谷，坦噶尼喀湖也来自裂谷，这两个湖的周边坡度与深度之间没有稳定关系。对小湖，周边地形能大致反映湖盆的深浅，因为湖盆往往就是地形的最低处；对大湖，这个关系断了。
但它带来一个结构性后果：跨 500 平方公里这条线比较深度，比的是方法不是水体。一个 480 平方公里的湖，深度是回归值；一个 520 平方公里的湖，深度是文献值。两者放在一张散点图上，500 附近会出现一个不连续。
4.3 回归模型长什么样
模型的自变量只有两个：湖泊面积，以及湖外 100 米缓冲带的平均坡度。因变量是平均深度。形式是按规模分组的多元回归方程。
训练数据是七千多个湖的测深记录，验证数据是另外五千多个湖。文档对验证结论的表述是：区域性结果令人满意，但单个湖的体积解读需谨慎，个体误差与不确定性可能很大。
这句话要按字面读。「区域性结果令人满意」说的是把一片区域的湖加总，总量大致对得上；「个体误差可能很大」说的是单个湖可能差好几倍。两者不矛盾：一批高估和一批低估在求和时互相抵消，剩下的偏差就小了。
这解释了为什么这份数据的全球合计看起来合理（181,900 立方公里，量级与通行的全球湖泊蓄水估算一致），而单个湖的数字经常离谱。§1.5 的案例是极端情形，但绝不是孤例——乌尔米耶湖 4,932.76 平方公里配 1,800 百万立方米体积，平均深度 0.4 米；大咸海 23,865.91 平方公里配 26,800 百万立方米，平均深度 1.1 米。前者是萎缩中的盐湖，文献值对应的是接近干涸的状态；后者是 2000 年前后已经分裂的残湖。数值都「对」，只是对的是另一个时刻的水体。
还有一种是输入本身就错。14 号卡拉博加兹戈尔湾，面积 18,666.80 平方公里，体积 1,885,347 百万立方米，平均深度 101.0 米。三个数互相自洽——面积乘深度正好等于体积——所以错不在算式。这个湾是一片与里海隔着一道沙嘴的浅水潟湖，101 米这个量级与它的实际形态不符，更可能是输入表在录入或单位换算时出了偏差。它提醒一件事：文献值不等于正确值，Vol_src 取 1 只是说「这个数有出处」，没说「这个数经过复核」。
4.4 流量从哪来
Dis_avg 的来源是全球水文模型 WaterGAP 的长时间平均径流与流量，时段是 1971 到 2000 年，模型版本 2.2（2014 年状态）。
原始分辨率是 0.5 度，约 50 公里一格。这个尺度对湖泊出水口太粗，所以先用地质统计方法降尺度到 15 弧秒，约 500 米，与 HydroSHEDS 河网对齐，再在出水口位置取值。
文档对这一步的验证说得很实在：与全球径流数据中心约三千个水文站的多年平均流量比对，总体相关性良好，但个体不确定性可能很高，尤其是流量很小的时候。
小流量的问题在于相对误差。一个出水口模型给 0.08 立方米每秒，真值可能是 0.02，也可能是 0.3，绝对误差不大，相对误差三四倍。而停留时间等于体积除以流量，流量在分母上，相对误差直接搬进结果。
4.5 停留时间是三个估算的商
Res_time 的定义：体积除以平均流量，单位天。
分子是估算（99.5% 的记录），分母是模型降尺度值，商是两个误差的叠加。文档还加了一条人为规则：算出来小于 0.1 天的，一律抬到 0.1，理由是更短的停留时间不合常理、多半是模型错误。
这条规则说明团队自己知道尾部不可靠。全表最大的停留时间是 13,203,790 天，约三万六千年；最小值被规则钉在 0.1 天。这个跨度里，中位数比均值更值得引用——文档给的全球均值是 1,834 天，中位数是 451 天，均值是中位数的四倍，说明分布被少数极长停留的大湖拉长了。
对一个具体的湖，停留时间的可用性取决于它的规模。大湖的流量与体积都相对可靠，商也相对可靠；小湖的两项都在误差里，商的意义接近于零。
4.6 高程与坡度也是推的
Elevation 取湖范围内出现次数最多的像元高程，底图是 90 米的 EarthEnv-DEM90。60°N 以北出现的负高程，被换成 1 公里 GTOPO30 的结果，以免出现「北纬七十度的湖面在海平面以下」这种地形伪影。60°N 以南沿海仍有少量小负值，文档说明这些值可能对也可能错。
Slope_100 同样来自 EarthEnv-DEM90，取湖外 100 米缓冲带的平均坡度，做了纬度改正。面积不小于 500 平方公里的湖，这一列是 -1，因为大湖的缓冲带会跨越多条地形带，平均值没有意义。
这两列的重要性被低估了：Slope_100 不只是一个描述，它还是体积模型的输入之一。改坡度就改深度，改深度就改体积。所以当有人问「能不能用更好的 DEM 重算这份数据的湖深」，答案是能，但那已经是一份新数据，不是这份。
4.7 完整性边界：三十五公顷
10 公顷是纳入门槛，35 公顷是完整性门槛。
文档引用了一篇统计外推：35 公顷以上的湖泊，这份数据基本收全；10 到 35 公顷之间，接近收全。
这两个词的区别很重要。「收全」意味着与现实对得上；「接近收全」意味着有系统性的漏画，且漏画集中在某个面积段。把 10 到 35 公顷这一段单独拿出来做数量分析，得到的密度图会反映源数据的覆盖差异，不是水体的真实密度。
更麻烦的是跨版本比较。如果将来出现一份门槛不同、或者源数据不同的新版，同一片地物会在两个版本里忽隐忽现——一个 12 公顷的水塘，在这一版里可能因为源图没画而缺席，在下一版里因为换了源图而出现。这种「出现」不是新建，是补画。
§5 怎么拿到：四个包与三条路
5.1 四个包的体积账
| 包 | 内容 | 官方标注 |
|---|---|---|
| HydroLAKES_polys_v10.gdb.zip | 全部湖面多边形与属性 | 763 MB |
| HydroLAKES_polys_v10_shp.zip | 同上，shapefile | 820 MB |
| HydroLAKES_points_v10.gdb.zip | 全部出水口点与属性 | 81 MB |
| HydroLAKES_points_v10_shp.zip | 同上，shapefile | 79 MB |
解压后，点图层的 dbf 是 376 MB，shp 是 40 MB，shx 是 11 MB，加上一个 219 字节的 .prj。多边形图层解压后更大，因为几何复杂——边界的坐标对数量比点多了几个数量级。
只想要属性、不需要几何的人，下 79 MB 那个包就够：dbf 里有全部 21 列，其中已经包含出水口的经纬度两列，可以在任何能读一百多万行的表格软件里打开。
5.2 不用注册、不用申请
四个包都是直链，点开就下。没有登录墙，没有申请表，没有使用协议弹窗，没有任何速率限制的迹象。
这在全球水文数据里是罕见的。同领域的不少产品要么要求填表说明用途，要么把下载放在需要机构账号的门户后面。HydroSHEDS 体系选择了最开放的一种：CC-BY 4.0，署个名就能用，商用也可以。
许可页面还附了一句请求：请不要把数据以原始格式整体转发到其他网站上，除非得到作者书面许可。这句话不构成许可限制——CC-BY 4.0 本身允许再分发——它是作者的请求，不是条款。判断时可以这样区分：转载整套原始压缩包，最好先问一句；把数据用在产品里、发表结果、做二次加工，许可明确允许。
5.3 geodatabase 与 shapefile 的取舍
两种格式装的是同一份东西，选哪个取决于工具链。
geodatabase 需要 ArcGIS 或兼容的驱动才能打开，好处是字段名不被截断、编码不乱、没有 2 GB 的单文件上限。它还会自动加三个字段：OBJECTID、Shape_Length、Shape_Area。
这三个字段是坑。它们由软件按图层坐标系的单位计算，而图层的坐标系是经纬度。所以 Shape_Area 的单位是「平方度」，Shape_Length 的单位是「度」，数值没有任何物理意义。看到 Shape_Area 写着 0.03 就以为湖是 0.03 平方公里，会错得很远——真实的面积在 Lake_area 列里。
shapefile 由一个主文件加五个伴生文件组成：.shp 存几何，.shx 存索引，.dbf 存属性，.prj 存投影，.sbn 与 .sbx 存空间索引。开源工具链对它的支持最好。它的毛病是字段名最长 10 个字符、字符串编码经常要手动指定、单文件不能超过 2 GB——这份数据刚好没撞上上限。
5.4 没有 GIS 也能读
技术文档专门提示了一条路：出水口的 dbf 是 dBASE IV 格式，可以直接用能读 142 万行的电子表格或数据库程序打开，然后用 Pour_long 与 Pour_lat 两列把点画出来。
这条路对只做统计分析的人很实用：不需要装 GDAL，不需要处理几何，拿到表就能跑。代价是没有多边形，一切基于面积的计算只能用 Lake_area 列。
5.5 读进 Python
import geopandas as gpd
pts = gpd.read_file("HydroLAKES_points_v10_shp/HydroLAKES_points_v10.shp")
print(len(pts), pts.crs)
print(pts[["Hylak_id", "Lake_name", "Lake_area", "Vol_total", "Depth_avg"]].head())
读进来第一件事是确认行数与坐标参考。行数应当是 1,427,688；crs 应当是 EPSG:4326。
第二件事是换算单位、复算深度，看三列能不能对上：
import geopandas as gpd
p = gpd.read_file("HydroLAKES_points_v10_shp/HydroLAKES_points_v10.shp")
p["vol_km3"] = p["Vol_total"] / 1000.0
p["vol_m3"] = p["vol_km3"] * 1e9
p["area_m2"] = p["Lake_area"] * 1e6
p["depth_recalc"] = p["vol_m3"] / p["area_m2"]
diff = (p["depth_recalc"] - p["Depth_avg"]).abs()
print(diff.max(), (diff > 0.15).sum())
这段跑完会看到绝大多数记录的复算深度与原列只差舍入误差，因为 Depth_avg 本来就是这么算出来的。少数差值大的，通常是舍入或单位录入的个例，值得单独看一眼。
第三件事是按来源分层，别把三种体积混在一起统计：
import geopandas as gpd
p = gpd.read_file("HydroLAKES_points_v10_shp/HydroLAKES_points_v10.shp")
p["vol_km3"] = p["Vol_total"] / 1000.0
for src, g in p.groupby("Vol_src"):
print(src, len(g), round(g["vol_km3"].sum(), 1))
按 Vol_src 分组求和，得到的三个数加起来应当接近官方给的 181,900 立方公里。如果差得远，多半是单位没换。
5.6 投影与 .prj
坐标系是地理坐标，WGS84 基准，ESRI 里叫 GCS_WGS_1984。.prj 文件只有 219 字节，内容就是一行地理坐标系定义。
没有投影意味着三件事：面积要读列不能从几何算；缓冲区、距离、邻接这些运算必须先转成等积或等距投影；跨 180 度经线的多边形会在平面上裂开，做全球镶嵌时要特别处理。
5.7 与 HydroATLAS 的关系
官方产品页有一句容易被略过的话：HydroATLAS 完整包含了 HydroLAKES 的全部湖泊，并在其上增补了大量水文环境特征。
这句话的实际含义是：HydroLAKES 是一个子集，不是另一个平行产品。HydroATLAS 分三块——BasinATLAS 是子流域面，RiverATLAS 是河段线，LakeATLAS 是湖岸线。三块合起来是 100 万个子流域、850 万条河段、140 万个湖，每块 56 个变量、281 个属性。
所以选型问题变成：只要几何，下 HydroLAKES（763 MB）；要几何加几十个环境属性，下 LakeATLAS（1.43 GB geodatabase）。后者才是做湖泊生态、气候响应、人类活动压力这类分析的正确入口。
§6 拓扑：湖、河、流域怎么接
6.1 官方那句话与表里的现实
产品页写着：每个湖都与 HydroRIVERS 的一条河段、HydroBASINS 的一个子流域做了共注册，方式是通过共享 ID。
翻开属性表，21 列里找不到 HYRIV_ID，也找不到 HYBAS_ID。唯一的外键是 Grand_id。
这两件事不矛盾，但需要分清层次。技术文档描述的共注册方式是：把每个湖连到「排干这个湖的最下游河网像元」上，这个像元就是出水口；再从出水口位置提取上游汇流面积与模型流量。这是空间位置上的共注册，靠的是坐标，不是列里的编号。产品页那句「通过共享 ID」描述的是整个 HydroSHEDS 家族的谱系——HydroRIVERS 的每条河段确实带子流域编号，LakeATLAS 的每个湖也确实带流域与河段属性——但在 HydroLAKES 这一层的原始文件里，这两列没有随数据发出。
实践含义很直接：想给湖挂上流域号或河段号，得自己做一次空间相交；或者干脆换 LakeATLAS。
6.2 出水口是怎么选出来的
每个湖只给一个点。选法是：在湖的范围内，找出 HydroSHEDS 汇流累积量最大的那个像元；如果有多个并列，取模型流量最大的；如果还并列，随机选一个。然后把该像元与湖多边形的交集取质心，作为出水口坐标。
交集质心这一步是为了保证点一定落在自己的多边形内部——如果直接取像元中心，点在湖边时可能落到湖外。
这个选法有一个隐含假设：湖只有一个出口。对多数湖泊成立，对分汊湖、多口出流的三角洲湖、以及季节性改变出口的湖不成立。这类湖在表里被强行压成一个点，拓扑上就等于被简化成单出口。
另一个后果是终端湖的处理。内陆盆地的湖没有出口，最下游的像元就在湖心，所以出水口会落在多边形中央。这时 Dis_avg 描述的不是出流，是「流出湖面的那部分水量」，物理含义已经变了。
6.3 用空间相交补编号
给湖挂流域号，标准做法是把出水口点落到子流域多边形里：
import geopandas as gpd
basins = gpd.read_file("hybas_na_lev06_v1c.shp")
pts = gpd.read_file("HydroLAKES_points_v10_shp/HydroLAKES_points_v10.shp").to_crs(basins.crs)
pts = pts[["Hylak_id", "Lake_area", "Pour_long", "Pour_lat", "geometry"]]
joined = gpd.sjoin(pts, basins[["HYBAS_ID", "geometry"]], how="left", predicate="within")
print(joined["HYBAS_ID"].isna().sum())
要注意三点。第一，出水口必须用点，不能用多边形质心——质心可能落在流域之外，尤其是形状不规则的湖。第二，落在边界上的点会同时命中两个子流域，sjoin 会产生重复行，需要去重。第三，within 严格不含边界，换个谓词结果会变，做批量处理时要固定下来。
挂河段号的做法类似，但对象是线：把出水口在河段上做最近邻，取距离最小的那条，同时记下距离——距离大于一个像元（约 500 米）的匹配要人工看一眼，很可能是湖画错了位置，或者河网在这一段有断点。
6.4 一个湖只有一个出口，一条河可以有多个湖
拓扑的方向性值得说清：湖到河是多对一（多个湖可以汇入同一条河段），湖到流域是一对一（一个湖的出水口只落在一个子流域里，边界情况除外）。
这个结构决定了上游下游关系的算法。要判断两个湖是否在同一条水系上，不能靠属性 join，要靠流量与流域面积的大小关系，加上河网连通性。
6.5 三条产品线的分工
HydroLAKES 是水面，HydroRIVERS 是河线，HydroBASINS 是流域面。三者的口径不同，混用时必须对齐。
HydroRIVERS 收录的门槛是集水面积不小于 10 平方公里，或平均流量不小于 0.1 立方米每秒，两者满足其一即入。结果 850 万条河段，平均长 4.2 公里，总长 3,590 万公里。
HydroBASINS 是子流域面，按 Pfafstetter 编码分层，从大洲级一路细分到十几级。
对准的方式只有一个：空间。湖的出水口落在哪条河段上、哪个子流域里，就是它在这两套体系里的位置。三套数据的编号互不相通，任何「按 ID 直接 join」的想法都会失败。
6.6 一个常被忽略的错配
湖多边形的边界来自影像与水系图，河网的边界来自 15 弧秒（约 500 米）的栅格水文推导。两者的几何精度不在一个量级：湖岸线可能是 30 米像元级的，河网是 500 米像元级的。
后果是：一个窄长的水库，在河网里可能只对应一条穿过它的单线，出水口落在湖的一侧，而实际出流在另一侧。做水量平衡时这点误差会被放大，因为流量是在那个错位的像元上取的。
793 条记录的出水口落在陆表掩膜之外，多半就是这类错配的结果：湖多边形画到了河网认为不是水体的地方，取值失败，只好记 -9999。
§7 阅读本节前：三种评价错位
7.0 先摆正评价框架
用之前要先确认一件事：你手里的标准，是不是这份数据承诺过的东西。三件事最常被批评，而它们恰好是设计上就放弃了的。
7.1 错位一：拿测深数据验证体积
拿几十个有测深资料的湖，比对 Vol_total，算相对误差，然后宣布模型不行——这个流程本身有问题。
问题在抽样。有测深资料的湖是被选中的湖：城市水源地、通航湖泊、富营养化治理对象、深水湖。这些湖在成因上与无测深的湖不同，深度分布也不同。用它们做验证集，等于用一群特例去评价一个面向全体外推的模型。
更根本的问题是：对一个从来没有被量过深度的湖，你没有任何办法知道它错多少。这不是数据的缺陷，是问题的性质。全球绝大多数湖泊没有测深记录，任何全球湖深产品都只能是外推，区别只在外推的方法与透明度。
合理的验证设计是分规模、分区域做，并且明确区分「总量误差」与「个体误差」。前者可以做，后者在没有真值的地方做不了。
§1.5 的案例提供了另一种可操作的检验：不看绝对值，看内部一致性。面积、体积、深度三列必须互相自洽，不自洽的记录一定有问题；自洽的记录仍可能错，但至少错在输入而不是算式。
7.2 错位二：拿今天的水面质疑 2000 年的多边形
「这个湖现在比数据里小了一半」——这句话成立，但它不是错误，是时间差。
主体区域的岸线对应 2000 年 2 月。二十多年里，咸海萎缩、乌尔米耶湖退缩、乍得湖反复涨落、大量水库新建。这些变化都不在这份数据里。
判断某个湖的边界是否过时，要看的不是年份，是这个水体有没有发生过显著的面积变化。封闭盆地的盐湖、干旱区的尾闾湖、大城市边缘的调蓄水库，这三类最可能过时；构造湖、高山冰蚀湖、深水大湖，边界基本稳定。
7.3 错位三：拿湖泊数当「世界有多少湖」
142 万这个数常被引用成「全球湖泊总数」。它不是。它是「10 公顷以上、被这八套源数据画出来、通过人工剔除、并且落在某个特定制图年份」的水体数。
换门槛就换量级：把门槛降到 1 公顷，数量会上一个数量级；把门槛提到 100 公顷，会掉到几万个。
换定义也换结果：湿地算不算湖、季节性水体算不算湖、水库算不算湖，三个问题的答案都会改变计数。这份数据的选择是：水库算，湿地不算，季节性水体按源数据的分类走，不额外判断。
7.4 DAIMS 简表
| 维度 | 情况 | 说明 |
|---|---|---|
| 来源可溯 | 强 | 八个源数据逐一点名，附引用 |
| 方法透明 | 强 | 回归模型、训练与验证规模、文献来源都写明 |
| 版本可辨 | 中 | 只有 version 1，但文档封面写 1.0、许可章节写 1.a、文件名写 v10 |
| 更新节奏 | 弱 | 2016 年后无新版，事实冻结 |
| 不确定度 | 弱 | 无逐条误差，只在文档里做定性提示 |
| 空间完整度 | 中 | 全球陆地，但比例尺从 1:2.4 万到 1:100 万不等 |
| 时间信息 | 无 | 单快照，无时间维 |
| 许可清晰度 | 强 | CC-BY 4.0，产品页与技术文档双处写明 |
| 访问稳定性 | 强 | 直链静态文件，十年未变 |
| 文档完备度 | 强 | 十六页技术文档随包分发，字段逐列解释 |
§8 常见误读与避坑清单
| 常见说法 | 实际情况 | 证据 |
|---|---|---|
| 「体积单位是立方公里」 | 是百万立方米，1 百万立方米等于 0.001 立方公里，读错放大约一千倍 | 技术文档表 2 的 Vol_total 字段说明 |
| 「贝加尔湖体积 2361.5 万立方公里」 | 除以一千得 23,615 立方公里，与面积乘深度对得上 | 同一行 Lake_area 与 Depth_avg 复算 |
| 「平均深度是测出来的」 | 是体积除以面积，派生量；体积本身 99.5% 由回归外推 | Depth_avg 字段定义；Vol_src 计数 |
| 「Lake_type 里有盐湖」 | 只有湖、水库、受调控湖三档，盐湖一律标 1 | 技术文档表 2 与全表计数 |
| 「Lake_type 等于 1 就是天然湖」 | 默认值兜住了所有未识别的小型人工水库 | 技术文档对默认值的说明 |
| 「水库有 6,796 个」 | 6,796 是挂上 GRanD 编号的记录数；类型标为水库的是 6,687 条 | Grand_id 与 Lake_type 分别计数 |
| 「有名字的湖能按名字查」 | 只有 3,022 条有名字，规则是 500 平方公里以上、GRanD 有名水库、GLWD 有名小湖 | Lake_name 非空计数与字段说明 |
| 「Hylak_id 按面积排序」 | 前十八号是人工编排，7 号安大略湖面积小于 8 号休伦湖 | 两条记录的 Lake_area |
| 「Shape_Area 就是湖泊面积」 | 那是软件按经纬度算的平方度，物理上无意义，真实值在 Lake_area | 技术文档对 gdb 附加字段的说明 |
| 「湖和河段能按 ID 直接 join」 | 属性表里没有 HYRIV_ID 与 HYBAS_ID，只能按出水口做空间相交 | 点图层 dbf 的 21 个字段清单 |
| 「这是一个湖泊时间序列」 | 单快照，无时间维，主体区域对应 2000 年 2 月 | 技术文档关于 SWBD 采集时点的说明 |
| 「140 万个湖就是全球湖泊总数」 | 是 10 公顷以上、被八套源数据画出、经过人工剔除的水体数 | 门槛与源数据表 |
| 「岸线长度可以直接比跨国差异」 | 加拿大与阿拉斯加约 1:10 万，北俄罗斯约 1:100 万，比例尺差异会进岸线 | 技术文档第 2.2 节比例尺段落 |
| 「停留时间 -1 说明湖很浅」 | -1 表示流量为 0、算不出来；-9999 表示出水口不在陆表掩膜内 | Res_time 字段的取值说明 |
| 「出水口一定在湖边」 | 终端湖的出水口落在湖心；算法取的是汇流累积量最大像元与多边形的交集质心 | 技术文档第 2.2 节共注册段落 |
| 「这是一份湖泊监测产品」 | 它是矢量底图，不含任何观测序列 | 全表 21 列无时间字段 |
表里最贵的一条是第一条。它不只是一个单位错，它会连锁：体积错一千倍，深度错一千倍，停留时间错一千倍，然后再被写进模型、写进论文、写进政策文件，一路上没有人会回头检查那一列的单位注释。
第二贵的是关于 ID 的那条。很多人先在 HydroRIVERS 里筛出目标河段，再想「按编号把湖 join 上来」，写了几行代码之后才发现两边的编号体系根本不通用。§1.5 的案例里，那一步本来是想按河段找湖，最后改成按出水口做空间相交，代码量从三行变成了三十行——但结果是可用的。
还有一类误读不在表里，因为它不涉及事实，涉及期望：把这份数据当成「湖泊的权威名录」。它不是名录，它是某个团队在某个时段，用某几套源数据，按某个门槛画出来的一张图。名录要的是穷尽与准确，图要的是可用与一致，两者是不同的东西。
§9 它在本库里的位置
9.1 与土壤、气象三条线的分工
SoilGrids 给的是地表以下的介质，ERA5 给的是大气状态，GHCNd 给的是站点观测，HydroLAKES 给的是地表水体的几何。
四者的时间性质完全不同：ERA5 逐小时、GHCNd 逐日、SoilGrids 无时间维但是一版预测、HydroLAKES 无时间维且是一版快照。做流域模型时，前两者是驱动，后两者是参数与几何。混用最多的错误是把 HydroLAKES 也当成可以逐年更新的变量。
一个具体的接法：用 HydroLAKES 的湖泊面积与流域面积做汇流单元，用 ERA5 的降水与蒸散做驱动，用 SoilGrids 的质地与容重做下渗参数，最后用 GHCNd 的站点径流或水位做校验。这条链上，只有 HydroLAKES 那一环是「一次画好、永不再变」的。
9.2 与遥感两条线的关系
Landsat 提供的是像元级的观测序列，可以用来提取水面范围随时间的变化；HydroLAKES 提供的是矢量的静态边界。两者结合的标准做法是：用 HydroLAKES 的多边形做感兴趣区，在 Landsat 序列里统计水体像元比例，得到每个湖的水面面积时间序列。
OISST 给的是海表温度，看起来无关，但做湖温研究时常被拿来当对照——淡水湖的夏季表层温度变化幅度通常大于同纬度海面，这个差异本身就是一个信号。HydroLAKES 提供湖的位置与面积，OISST 提供邻近海面的基准。
9.3 与物种、浮标、地图数据的连接
GBIF 的物种出现记录带经纬度，落到湖多边形里就能分出「水域记录」与「陆域记录」——这一步在多边形数据缺失时很难做准，因为缓冲区半径是拍的。有湖岸线之后，判断变成一次空间包含运算。
Argo 浮标是海洋的，看似无关；但它的剖面数据常被用作湖泊模型的边界条件参照，尤其是深水湖的热结构模拟。
Overture Maps 提供的是道路、建筑、土地利用的矢量底图。把湖多边形与建成区叠起来，就能算出湖岸带的城市压力——这是湖泊富营养化研究里最常用的一个代理变量。
9.4 检索路径
要找「全球尺度的水体几何」，本库里目前只有这一条。要找「地表覆盖分类基准」，去 EuroSAT；要找「逐日地表温度或海温」，去 OISST；要找「逐年影像」，去 Landsat。
湖泊这个方向在库内是空白，HydroLAKES 是第一块砖。后续可以补的方向有三个：HydroATLAS 的 LakeATLAS（同一批湖，加几十个环境属性）、HydroRIVERS（河段线，做上下游拓扑必需）、GRanD（坝与库容的原始表）。
§10 为什么它能持续，以及 AI 使用声明
10.1 生存逻辑
这份数据活了十年，靠的不是精度，是三件事。
第一是可引用。它有一篇发在 Nature Communications 的方法论文，有 DOI，有明确的作者与机构，方法写得足够复现。它在学术引用体系里是一个合法节点，这让它成为「全球湖泊」这个题目下绕不开的默认引用。
第二是可下载。四个静态压缩包，直链，无注册，十年没变过地址。这种稳定性在学术数据里比精度更稀缺——一个每年换一次门户、每两年改一次接口的产品，用起来的隐性成本远高于它的精度收益。
第三是可组合。它与同一家族的河网、流域产品共享同一套出水口逻辑，与 GRanD 共享一个外键，与 HydroATLAS 是包含关系。一个湖可以被放进河网、放进流域、放进水库清单，而不需要重新数字化。
10.2 撑不住的地方
没有第二版。2016 年之后没有整版更新，没有勘误表，没有 changelog。这意味着所有已知问题都是永久性的：乍得湖那 0.1 米、卡拉博加兹戈尔湾那 101 米、密歇根与休伦的拆分约定，都不会被修正。
没有误差列。逐条记录没有不确定度，只有文档里一句定性的提示。这让下游无法做加权，也无法做敏感性分析——只能整体接受或整体怀疑。
比例尺不均。同一份数据里，不同大洲的有效分辨率差四倍，跨国比较的任何几何指标都掺着这个差异。
这三条里，第一条最要紧。一份冻结的数据在方法上并不过时——地形没变，湖盆没变——但在状态上会越来越旧。用它做 2026 年的水面统计，必须自己补上这二十六年的变化。
10.3 用它的三条纪律
第一，先分层再统计。按 Vol_src 分组，把推算值与报告值分开算，别混在一起求平均。混算的结果既不是观测统计，也不是模型统计，是一个没有名字的东西。
第二，别信单条记录的深度。要单个湖的深度，去查测深资料；要一批湖的总量，用这份数据可以，但要接受几条离谱记录带来的偏差，必要时按分位数截尾。
第三，把出水口当接口，不当事实。它是河网上的一次采样位置，不是水文站。用它挂流域、挂河段都可以，用它做流量分析要先看 Dis_avg 是不是 -9999。
10.4 AI 使用声明
本文的文本由 AI 辅助撰写，事实核验基于 HydroLAKES 官方产品页、随包分发的十六页技术文档、以及实际下载的出水口点图层属性表。文中所有字段名、字段类型、类别计数、极值、示例记录的具体数值，均来自 dbf 文件的直接解析；总量与来源说明来自技术文档；许可与下载体积来自官方产品页。未下载多边形图层，未做几何运算，未对湖深模型做独立复算。
附录 A 属性速查
| 列名 | 类型 | 含义 | 单位 | 陷阱 |
|---|---|---|---|---|
| Hylak_id | 整数 | 湖泊唯一标识 | 无 | 是行号，不按面积排序 |
| Lake_name | 文本 40 | 湖名 | 无 | 仅千分之二有值；同名不同湖 |
| Country | 文本 35 | 所在国 | 无 | 跨国湖归到出水口所在国 |
| Continent | 文本 15 | 所在洲 | 无 | 六档，澳洲与太平洋岛屿合为 Oceania |
| Poly_src | 文本 10 | 多边形来源 | 无 | 八种取值，决定了几何精度 |
| Lake_type | 整数 | 水体类型 | 无 | 只有 1/2/3，无盐湖 |
| Grand_id | 整数 | GRanD 水库编号 | 无 | 0 表示无对应；唯一可用外键 |
| Lake_area | 小数 13,2 | 多边形面积 | 平方公里 | 二维小数，0.10 处有阈值堆积 |
| Shore_len | 小数 13,2 | 岸线长度 | 公里 | 受制图比例尺影响 |
| Shore_dev | 小数 7,2 | 岸线发育度 | 无量纲 | 与面积圆周长比；分辨率越高越大 |
| Vol_total | 小数 13,2 | 总体积 | 百万立方米 | 不是立方公里，差一千倍 |
| Vol_res | 小数 13,2 | 水库库容 | 百万立方米 | 0 表示无库容 |
| Vol_src | 整数 | 体积来源 | 无 | 1 文献湖、2 报告库容、3 模型 |
| Depth_avg | 小数 7,1 | 平均水深 | 米 | 等于体积除面积，派生量 |
| Dis_avg | 小数 13,3 | 出水平均流量 | 立方米每秒 | -9999 表示出水口不在陆表掩膜 |
| Res_time | 小数 13,1 | 停留时间 | 天 | -1 表示流量为零；小于 0.1 被抬高 |
| Elevation | 整数 | 湖面高程 | 米 | 北纬 60 度以上换过 DEM |
| Slope_100 | 小数 7,2 | 湖外百米缓冲带坡度 | 度 | 面积 500 平方公里以上为 -1 |
| Wshd_area | 小数 13,1 | 流域面积 | 平方公里 | -9999 表示出水口不在掩膜 |
| Pour_long | 小数 13,6 | 出水口经度 | 十进制度 | 保证落在多边形内部 |
| Pour_lat | 小数 13,6 | 出水口纬度 | 十进制度 | 终端湖落在湖心 |
附录 B 术语表
| 术语 | 含义 |
|---|---|
| SWBD | SRTM 水体数据，随航天飞机雷达地形任务生成的水体掩膜，覆盖 56°S 至 60°N |
| CanVec | 加拿大自然资源部的国家水系矢量库，1:5 万，本数据六成多边形出自此处 |
| 岸线发育度 | 岸线长度与同面积圆周长的比值，正圆为 1 |
| 出水口（pour point） | 湖的排水出口，取湖内汇流累积量最大像元与多边形的交集质心 |
| 汇流累积量 | 一个像元上游的像元总数，用作流域面积的代理 |
| 终端湖 | 没有地表出口的湖，位于内流盆地最低处，出水口落在湖心 |
| 归一化停留时间 | 体积除以出流量，反映水体更新一次所需时间 |
| Vol_src | 体积来源标记，区分文献值、库容报告值与模型推算值 |
| GRanD | 全球水库与坝数据库，提供库容、坝高、建成年代等工程属性 |
| HydroSHEDS | 基于航天飞机雷达地形数据的全球水文派生体系，本数据的母体 |
| HydroRIVERS | 同体系的河段矢量产品，850 万条河段，门槛为集水面积 10 平方公里或流量 0.1 立方米每秒 |
| HydroBASINS | 同体系的子流域面产品，按 Pfafstetter 编码分层 |
| LakeATLAS | HydroATLAS 的湖泊分册，包含本数据全部湖泊并增补环境属性 |
| 溶解（dissolve） | 把空间上相邻、属性相同的多个多边形合并成一个的运算 |
| 哨兵值 | 用特定数字表示缺失或无效，本数据用 -1 与 -9999 |
| Pfafstetter 编码 | 一种按水系拓扑给流域编号的规则，支流编号为偶数、干流为奇数 |
附录 C 常见误读 FAQ
问：我能用它算一个湖的蓄水量变化吗？
不能，除非你自己补第二个时相。这份数据只有一版岸线，体积是同一版属性的推算值，没有时间维。
问：为什么有些大湖的深度看起来完全不合理？
因为面积与体积来自不同来源、不同年份。§1.5 的案例是典型：多边形按丰水期画，体积按枯水期报，商出来就是 0.1 米。
问：能不能只要水库？
可以，筛 Lake_type 等于 2 的那一类。但要清楚这是下界——大量小型人工水库被默认标成了湖。
问：能不能按湖名匹配别的数据集？
很难。只有三千个湖有名字，而且同名极多。稳妥的做法是按坐标做空间匹配。
问：出水口落在湖心是什么意思？
说明这是一个终端湖，没有地表出口。这时 Dis_avg 描述的不是出流，解读时要当心。
问：为什么不提供投影版本？
原始发布就是经纬度。需要投影的话自己转，选什么投影取决于研究区纬度与用途，官方没有替使用者做这个决定。
问：这份数据还会更新吗？
截至核验时官方只发布 version 1，2016 年 12 月，之后无新版。是否会有第二版，官方页面没有给出计划。
问：能不能用它训练语义分割模型？
可以拿它做水体掩膜的真值，但要注意三件事：它比影像晚，边界可能过时；它是矢量不是栅格，栅格化时分辨率选择会改变标签；它只覆盖 10 公顷以上的水体，小水塘全是负样本。
编辑说明
核验时间 2026-10-29。方法：打开 HydroSHEDS 官方 HydroLAKES 产品页与 HydroATLAS、HydroRIVERS 两个同族产品页，逐句核对总量、门槛、许可与引用；下载技术文档 PDF 并通读十六页，逐列核对属性表定义；下载出水口点图层的 shapefile 压缩包，解析 dbf 头部得到 21 个字段的名称、类型、长度与小数位，并对 1,427,688 条记录做全量扫描，统计类别计数、外键覆盖、极值与哨兵值分布，抽取里海、贝加尔湖、乍得湖、大咸海、乌尔米耶湖、卡拉博加兹戈尔湾等记录作为示例。
与常见转述不一致处已在正文逐条更正，主要有四处：体积列的单位是百万立方米而非立方公里；Lake_type 只有三档、不含盐湖；属性表里没有流域号与河段号，官方所说的共注册是空间位置的共注册，在 LakeATLAS 里才以共享 ID 的形式落到列上；技术文档给出的大水库库容并入数 6,797 与属性表里 Vol_src 取 2 的 6,723 条相差 74 条，正文只记录差额，不推断去向。
未下载多边形图层（820 MB），因此未核验面要素的几何质量、拓扑错误与环数；未做任何几何运算与面积复算；未对湖深回归模型做独立验证。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- hydrobasins — 共享标签：公共卫生与流行病学 / 全球健康 / 调查数据
- dhs-program — 共享标签：公共卫生与流行病学 / 全球健康 / 调查数据
- ghdx — 共享标签：公共卫生与流行病学 / 全球健康 / 调查数据
- world-health-survey — 共享标签：公共卫生与流行病学 / 全球健康 / 调查数据
- gho-steps — 共享标签：公共卫生与流行病学 / 全球健康 / 调查数据
- global-burden-of-disease — 共享标签：公共卫生与流行病学 / 全球健康
- wuenic-immunization — 共享标签：公共卫生与流行病学 / 全球健康 / 调查数据
- share — 共享标签：公共卫生与流行病学 / 全球健康 / 调查数据
- sage-survey — 共享标签：公共卫生与流行病学 / 全球健康 / 调查数据
- lasi — 共享标签：公共卫生与流行病学 / 全球健康 / 调查数据
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
