2. 海洋多站点数据来源与获取

多站点融合的第一步不是算法，而是把不同来源的数据“拿对、读懂、对齐”。海洋观测数据分散在各国数据中心与观测计划中，各自的数据组织方式、时间基准、变量命名和缺测标记都不相同。本节围绕三个主流平台（NOAA、Copernicus Marine、Argo）、两类获取方式（网页下载与API调用）以及三种常见格式（NetCDF、CSV、JSON）展开，重点讲清“从哪里取、怎么取、取回来怎么读”。

一、三个主流平台各自提供什么

NOAA（美国国家海洋和大气管理局）是覆盖面最广的公共数据源之一。其国家环境信息中心（NCEI）提供全球浮标、船测、卫星反演海表温度、验潮站水位等数据；ERDDAP 服务则把大量数据集统一成可查询的表格接口。对多站点融合而言，NOAA 的价值在于“站点级观测”丰富，例如 NDBC 浮标提供逐小时的风速、有效波高、海表温度，适合作为近岸站点的实测基准。

Copernicus Marine Service（CMEMS）以再分析产品和业务化预报产品为主，典型如全球海洋物理再分析 GLORYS12V1，提供 0.083° 分辨率、逐日的三维温度、盐度、流场。它的优势是空间连续、变量齐全、时间序列长，适合作为融合中的“背景场”或网格化产品，用来约束站点之间的空间插值。

Argo是全球约 4000 个自动剖面浮标组成的观测网，每个浮标约 10 天完成一次 2000 米深度的温盐剖面。Argo 数据经 GDAC（全球数据汇编中心）汇总，按“实时（R）—延时（D）”两级质量控制发布。融合中 Argo 提供的是深层、大范围的垂向剖面，弥补浮标和卫星只能观测表层的不足。

二、下载与API调用：从手工到可复现

小批量数据可直接在平台网页按区域、时间、变量筛选后下载。但多站点融合往往需要多年、多变量、多站点的批量数据，手工下载不可复现，应优先使用 API。下面给出两个典型调用示例（参数为教学示例，实际使用时按需替换）。

# 示例1：用 ERDDAP 表格接口取 NDBC 浮标数据（tabledap）
# 站点 41001，取 2023-01-01 至 2023-01-31 的风速与海表温度
https://coastwatch.pfeg.noaa.gov/erddap/tabledap/
  ndbc_41001.csv?time,wind_speed,sea_surface_temperature
  &time>=2023-01-01T00:00:00Z&time<=2023-01-31T23:59:59Z

# 示例2：用 copernicusmarine 客户端下载 GLORYS 再分析子区域
copernicusmarine subset \
  --dataset-id cmems_mod_glo_phy_my_0.083deg_P1D-m \
  --variable thetao --variable so \
  --minimum-longitude 118 --maximum-longitude 124 \
  --minimum-latitude 20 --maximum-latitude 26 \
  --start-datetime 2023-01-01 --end-datetime 2023-01-31 \
  --output-directory ./data

调用时有三点必须核对：一是时间基准，ERDDAP 默认 UTC，Copernicus 产品时间通常为 UTC 正午或日均值，混用前要统一；二是坐标约定，经度有 0–360 与 −180–180 两种表示，跨 180° 经线时容易取错区域；三是缺测值，NetCDF 常用 _FillValue（如 9.969e36）标记无效，若不处理会被当成真实极值参与统计。建议每次下载后先打印数据集的维度、变量名、单位与缺测值，再进入解析环节。

三、三种格式的解析要点

NetCDF 是海洋网格与剖面数据的主流格式，本质是“维度 + 变量 + 属性”的自描述容器。读取时先看维度（time、depth、lat、lon），再看变量及其 scale_factor、add_offset——很多产品以整型存储，需按 真实值 = 原始值 × scale_factor + add_offset 还原。Python 中用 xarray 打开后可直接按标签切片，避免手工计算索引。

import xarray as xr
ds = xr.open_dataset("glorys_subset.nc")
print(ds.dims)            # 查看维度
print(ds["thetao"].attrs) # 查看单位、缺测值、缩放参数
sst = ds["thetao"].sel(depth=0.5, method="nearest")
sst = sst.where(sst < 1e30)   # 剔除缺测

CSV 多用于站点观测，结构简单但“陷阱”在表头与缺测标记：不同平台可能用 NaN、-999、空字符串表示无效值，时间列可能是字符串或 Unix 时间戳。解析时应显式指定时间解析与无效值集合，例如 pandas 的 na_values=["-999", "NaN", ""]，并统一转换为 UTC 的 datetime 索引。

JSON 常见于 API 返回的元数据或轻量观测记录，嵌套结构需要按路径取值。例如 ERDDAP 的 info 接口返回的变量单位藏在 variables 数组的 attributes 中。解析时建议先打印键结构，再写取值路径，避免硬编码层级。

四、元数据与数据字典：读懂“数据的说明书”

元数据回答“这份数据是什么、怎么来的、能不能用”。对融合而言，最需要关注四类字段：变量标准名与单位（如 sea_surface_temperature 单位为 K 还是 ℃）、时间覆盖与分辨率、空间参考与坐标约定、质量控制标记。Argo 的 DATA_MODE（R/D）和 POSITION_QC、PROFILE_QC 直接决定该剖面能否进入融合；Copernicus 产品的 status_flag 则标识网格点的质量等级。

数据字典是把“字段名”翻译成“业务含义”的对照表。建议在项目内维护一份统一字典，至少包含：原始字段名、标准变量名、单位、有效范围、缺测标记、来源平台。下表为教学示例，展示三个平台同一物理量的字段差异：

把上表落到代码里，就是融合前的“标准化层”：统一变量名、统一单位（如全部转 K 或全部转 ℃）、统一时间到 UTC、统一缺测为 NaN、保留质量标记列。完成这一步，后续的站点匹配、时空插值和误差评估才有可靠输入。

上图把本节的关键关系串成一条链路：三个平台提供不同形态的原始数据，经各自接口下载后进入格式解析，再经过标准化层统一口径，最终形成可融合的数据集。实际工作中最常见的返工，恰恰发生在“格式解析”和“标准化”之间——例如把 _FillValue 当成真实温度、把本地时间当成 UTC、把 K 与 ℃ 混算。养成“下载后先查元数据、解析后先做标准化”的习惯，能显著降低后续融合评估中的系统性偏差。