如何自建免费 Open-Meteo 天气 API新手三步部署完整指南【免费下载链接】open-meteoFree Weather Forecast API for non-commercial use项目地址: https://gitcode.com/GitHub_Trending/op/open-meteoOpen-Meteo 是一个免费开源的气象数据平台用它几行命令就能自建专属天气 API 服务拉源码、起容器、同步数据8080 端口上就有可用的小时级预报接口。一、Open-Meteo 到底能帮你解决什么问题不再被第三方接口卡脖子如果你的项目里只要一个天气接口通常的路径是找商业 API 注册、付费、看配额脸色。Open-Meteo 把这条链路整个换掉上游数据来自各国气象机构公开发布的数值预报处理管线和 API 服务全部开源整套服务可以跑在你自己的机器上端点、变量、存储都归你管。一个容易落地的场景假设你运营几个温室大棚想每小时拿 2 米气温、相对湿度和降水量来决定通风机和遮阳网的开关。调公开 API 也能做但更新节奏、私有派生变量、内网设备访问这些需求就受制于人了。自建 Open-Meteo 之后接口就挂在你的内网里要什么变量自己定数据落在自己的磁盘上。开箱能拿到什么最长 16 天的小时级预报80 年历史天气基于 ERA5 再分析多模型集成全球 11 km 分辨率区域模型细到 2 kmICON D2个别模型可达 1.5 km除预报外还有海洋、空气质量、洪水、高程等 API以上能力以 README 中的描述为准。二、动手前环境清单 源码获取硬件最低要求与推荐配置API 服务器用 Swift 编写编译后是单个二进制文件运行环境非常干净你只需要 Docker。项目最低要求推荐配置操作系统任意装有 Docker 的 LinuxUbuntu 22.04 LTS官方 APT 包仅支持该系统Docker20.10 以上含 Compose v2最新版内存8 GB16 GB内存兼作数据缓存存储100 GBNVMe SSDCPU支持 SIMD 指令如 AVX2x86-64 或 Arm4 核及以上两个容易忽略的点磁盘就是缓存。每次请求只会读取压缩数据里的一小段最近访问的数据会留在本地盘上NVMe 和 SATA 在这里体验差距明显。内存也参与缓存。轻度自用 8 GB 足够变量多、还要查历史数据的场景16 GB 会从容很多。完整硬件要求见 入门指南。获取源码git clone https://gitcode.com/GitHub_Trending/op/open-meteo cd open-meteo仓库不大核心就是 Dockerfile把 Swift 源码编译成单个openmeteo-api二进制和 docker-compose.yml服务编排。三、三步跑起来容器化部署实操 以下就是完整的 Open-Meteo Docker 搭建流程。第一步一条命令启动服务docker compose up -ddocker-compose.yml 里定义了两个容器open-meteo-apiAPI 服务器监听8080端口--hostname 0.0.0.0 --port 8080open-meteo-sync数据同步 worker持续从数据分发源拉取dwd_icon模型的temperature_2m变量两者共享一个命名卷open_meteo_database挂载到容器内/app/data所有气象数据都存在这里。首次运行需要构建镜像Swift 编译约几分钟之后再启动只要几秒。第二步首次数据同步同步 worker 会自动启动你也可以手动触发一次直观看到发生了什么docker exec -it open-meteo-api sync dwd_icon temperature_2m --past-days 3 --repeat-interval 5命令格式是固定的sync 模型逗号分隔 变量逗号分隔。想多拿几个变量直接加docker exec -it open-meteo-api sync dwd_icon temperature_2m,relative_humidity_2m,precipitation --past-days 7常用选项完整参数见 同步命令源码--past-days往回同步多少天默认 7--repeat-interval N常驻运行每 N 分钟检查一次新文件--server数据源默认指向 Open-Meteo 开放数据 S3 分发源不用配置第三步验证接口是否可用curl http://localhost:8080/v1/forecast?latitude52.52longitude13.41hourlytemperature_2mmodelsicon_global返回包含time数组和temperature_2m数组的 JSON就说明部署成功了。注意第一次请求偏慢数据要从远端拉下来写入本地缓存之后同位置或邻近坐标的请求通常都在亚秒级。接口的完整定义在 openapi/forecast.yml。四、数据从哪来气象模型与变量解析 上游是国家气象机构的开放预报Open-Meteo 自己不做模型它把各国机构公开发布的数值天气预报拉下来统一格式后存入可查询的数据库。常见来源模型提供方分辨率ICONicon / icon-eu / icon-d2德国 DWD11 km / 7 km / 2 kmGFS HRRR美国 NOAA全球 北美高分辨率IFS欧洲中期天气预报中心 ECMWF0.25°AROME / ARPEGE法国 MeteoFrance区域高分辨率GEM加拿大北美区域模型域注册表 里列出了全部可用的域标识符sync命令里的dwd_icon指的就是 DWD ICON。变量名怎么读变量命名基本自解释几个高频的temperature_2m距地面 2 米气温后缀_2m表示高度dew_point_2m、relative_humidity_2m露点温度、相对湿度precipitation每小时降水量wind_speed_10m、wind_direction_10m10 米高度风速、风向weather_code整数天气码WMO 标准对应小雨多云这类文字描述想看某个模型支持哪些变量直接读源码最快例如 ICON 的完整变量清单在 IconVariable.swift。单点取数为什么快这是 Open-Meteo 最有工程味的一环。原始模型文件GRIB 之类体积很大每次查询都要在网格里定位经纬度再插值开销不小。Open-Meteo 把数据预先转成自研二进制格式按位置 × 变量 × 时间段拆成独立小文件查询时直接打开对应文件就行——类似图书馆按编号取书而不是每次翻遍整个书库。这也是它能在普通硬件上把平均响应时间压到毫秒级的原因。五、调优与生产化性能、成本、安全 只同步需要的变量这是省空间最直接的手段。ICON 全量变量体积可观只需要温度和湿度就只同步这两个docker exec -it open-meteo-api sync dwd_icon temperature_2m,relative_humidity_2m --past-days 7 --repeat-interval 5如果用 Ubuntu 包版本也可以写进配置文件SYNC_ENABLEDtrue、SYNC_DOMAINSdwd_icon、SYNC_VARIABLEStemperature_2m,dew_point_2m、SYNC_REPEAT_INTERVAL5然后重启同步服务。全部参数见 数据下载文档。8GB 内存够不够轻度使用够。记住前面的结论内存和磁盘都参与缓存。跑高频业务或大量查询历史数据时ERA5 一年大约 60 GB把CACHE_SIZE环境变量调大如 8GB内存给到 16 GB NVMe体验会明显更好。用 cron 自动清理过期数据预报数据时效性强老数据没多少价值。官方给出的清理模板是气压层数据 10 天后删除地表数据 90 天后删除照抄即可模板见 cronjobs.md。前置 nginxTLS 与限流compose 版默认监听 0.0.0.0:8080直接暴露公网不建议。生产环境挂一层反向代理做 TLS 最稳妥多节点同步文档 里有一份现成的 nginx 配置可以参考。服务端自带限流和 API key 管理实现RateLimiter.swift、ApiKeyManager.swift需要管控访问时可以用上。另外数据是 CC-BY-4.0展示数据时要保留来源署名。六、常见问题 FAQ 首次请求为什么很慢冷缓存。第一次请求某个变量需要从远端分发源取数单次可能涉及几 MB 数据之后同位置或邻近坐标的请求命中本地缓存通常亚秒返回。能不能不下载全量数据直接用能。API 可以直接读取远端开放数据源并本地缓存不需要先下完整个数据集。只有当你想完全离线、或者查询量很大时才需要用sync把数据完整拉到本地。想加一个新变量怎么办把变量追加到sync命令的变量列表即可。如果要走原始数据路线也可以让下载器按变量过滤例如download icon --run 00 --only-variables temperature_2m,weather_code。注意不是所有变量在所有模型上都提供。想绑域名对外提供怎么配nginx 反代到127.0.0.1:8080配上证书即可。Ubuntu 包版本默认只绑定 127.0.0.1外部不可访问天然安全直接加代理层就行。能商用吗自部署支持非商业与商业两种用途但注意两份协议源码是 AGPL-3.0修改后以服务形式对外提供需要开放你的修改版源码数据是 CC-BY-4.0必须署名。完整条款见 README。写在最后把主线再串一遍git clone→docker compose up -d→sync→curl验证这套 Open-Meteo 部署下来也就半小时的事。自建的最大价值不是省下几块钱接口费而是端点、变量、存储都在你手里可以按业务节奏改。如果你的项目涉及天气值得在服务器上给它留个位置。再往后延伸的空间也不小海洋 API、空气质量 API、80 年历史天气 API以及多节点分布式部署一台机器负责下载、多台机器共享查询——每个方向都值得单独展开。【免费下载链接】open-meteoFree Weather Forecast API for non-commercial use项目地址: https://gitcode.com/GitHub_Trending/op/open-meteo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何自建免费 Open-Meteo 天气 API：新手三步部署完整指南
如何自建免费 Open-Meteo 天气 API新手三步部署完整指南【免费下载链接】open-meteoFree Weather Forecast API for non-commercial use项目地址: https://gitcode.com/GitHub_Trending/op/open-meteoOpen-Meteo 是一个免费开源的气象数据平台用它几行命令就能自建专属天气 API 服务拉源码、起容器、同步数据8080 端口上就有可用的小时级预报接口。一、Open-Meteo 到底能帮你解决什么问题不再被第三方接口卡脖子如果你的项目里只要一个天气接口通常的路径是找商业 API 注册、付费、看配额脸色。Open-Meteo 把这条链路整个换掉上游数据来自各国气象机构公开发布的数值预报处理管线和 API 服务全部开源整套服务可以跑在你自己的机器上端点、变量、存储都归你管。一个容易落地的场景假设你运营几个温室大棚想每小时拿 2 米气温、相对湿度和降水量来决定通风机和遮阳网的开关。调公开 API 也能做但更新节奏、私有派生变量、内网设备访问这些需求就受制于人了。自建 Open-Meteo 之后接口就挂在你的内网里要什么变量自己定数据落在自己的磁盘上。开箱能拿到什么最长 16 天的小时级预报80 年历史天气基于 ERA5 再分析多模型集成全球 11 km 分辨率区域模型细到 2 kmICON D2个别模型可达 1.5 km除预报外还有海洋、空气质量、洪水、高程等 API以上能力以 README 中的描述为准。二、动手前环境清单 源码获取硬件最低要求与推荐配置API 服务器用 Swift 编写编译后是单个二进制文件运行环境非常干净你只需要 Docker。项目最低要求推荐配置操作系统任意装有 Docker 的 LinuxUbuntu 22.04 LTS官方 APT 包仅支持该系统Docker20.10 以上含 Compose v2最新版内存8 GB16 GB内存兼作数据缓存存储100 GBNVMe SSDCPU支持 SIMD 指令如 AVX2x86-64 或 Arm4 核及以上两个容易忽略的点磁盘就是缓存。每次请求只会读取压缩数据里的一小段最近访问的数据会留在本地盘上NVMe 和 SATA 在这里体验差距明显。内存也参与缓存。轻度自用 8 GB 足够变量多、还要查历史数据的场景16 GB 会从容很多。完整硬件要求见 入门指南。获取源码git clone https://gitcode.com/GitHub_Trending/op/open-meteo cd open-meteo仓库不大核心就是 Dockerfile把 Swift 源码编译成单个openmeteo-api二进制和 docker-compose.yml服务编排。三、三步跑起来容器化部署实操 以下就是完整的 Open-Meteo Docker 搭建流程。第一步一条命令启动服务docker compose up -ddocker-compose.yml 里定义了两个容器open-meteo-apiAPI 服务器监听8080端口--hostname 0.0.0.0 --port 8080open-meteo-sync数据同步 worker持续从数据分发源拉取dwd_icon模型的temperature_2m变量两者共享一个命名卷open_meteo_database挂载到容器内/app/data所有气象数据都存在这里。首次运行需要构建镜像Swift 编译约几分钟之后再启动只要几秒。第二步首次数据同步同步 worker 会自动启动你也可以手动触发一次直观看到发生了什么docker exec -it open-meteo-api sync dwd_icon temperature_2m --past-days 3 --repeat-interval 5命令格式是固定的sync 模型逗号分隔 变量逗号分隔。想多拿几个变量直接加docker exec -it open-meteo-api sync dwd_icon temperature_2m,relative_humidity_2m,precipitation --past-days 7常用选项完整参数见 同步命令源码--past-days往回同步多少天默认 7--repeat-interval N常驻运行每 N 分钟检查一次新文件--server数据源默认指向 Open-Meteo 开放数据 S3 分发源不用配置第三步验证接口是否可用curl http://localhost:8080/v1/forecast?latitude52.52longitude13.41hourlytemperature_2mmodelsicon_global返回包含time数组和temperature_2m数组的 JSON就说明部署成功了。注意第一次请求偏慢数据要从远端拉下来写入本地缓存之后同位置或邻近坐标的请求通常都在亚秒级。接口的完整定义在 openapi/forecast.yml。四、数据从哪来气象模型与变量解析 上游是国家气象机构的开放预报Open-Meteo 自己不做模型它把各国机构公开发布的数值天气预报拉下来统一格式后存入可查询的数据库。常见来源模型提供方分辨率ICONicon / icon-eu / icon-d2德国 DWD11 km / 7 km / 2 kmGFS HRRR美国 NOAA全球 北美高分辨率IFS欧洲中期天气预报中心 ECMWF0.25°AROME / ARPEGE法国 MeteoFrance区域高分辨率GEM加拿大北美区域模型域注册表 里列出了全部可用的域标识符sync命令里的dwd_icon指的就是 DWD ICON。变量名怎么读变量命名基本自解释几个高频的temperature_2m距地面 2 米气温后缀_2m表示高度dew_point_2m、relative_humidity_2m露点温度、相对湿度precipitation每小时降水量wind_speed_10m、wind_direction_10m10 米高度风速、风向weather_code整数天气码WMO 标准对应小雨多云这类文字描述想看某个模型支持哪些变量直接读源码最快例如 ICON 的完整变量清单在 IconVariable.swift。单点取数为什么快这是 Open-Meteo 最有工程味的一环。原始模型文件GRIB 之类体积很大每次查询都要在网格里定位经纬度再插值开销不小。Open-Meteo 把数据预先转成自研二进制格式按位置 × 变量 × 时间段拆成独立小文件查询时直接打开对应文件就行——类似图书馆按编号取书而不是每次翻遍整个书库。这也是它能在普通硬件上把平均响应时间压到毫秒级的原因。五、调优与生产化性能、成本、安全 只同步需要的变量这是省空间最直接的手段。ICON 全量变量体积可观只需要温度和湿度就只同步这两个docker exec -it open-meteo-api sync dwd_icon temperature_2m,relative_humidity_2m --past-days 7 --repeat-interval 5如果用 Ubuntu 包版本也可以写进配置文件SYNC_ENABLEDtrue、SYNC_DOMAINSdwd_icon、SYNC_VARIABLEStemperature_2m,dew_point_2m、SYNC_REPEAT_INTERVAL5然后重启同步服务。全部参数见 数据下载文档。8GB 内存够不够轻度使用够。记住前面的结论内存和磁盘都参与缓存。跑高频业务或大量查询历史数据时ERA5 一年大约 60 GB把CACHE_SIZE环境变量调大如 8GB内存给到 16 GB NVMe体验会明显更好。用 cron 自动清理过期数据预报数据时效性强老数据没多少价值。官方给出的清理模板是气压层数据 10 天后删除地表数据 90 天后删除照抄即可模板见 cronjobs.md。前置 nginxTLS 与限流compose 版默认监听 0.0.0.0:8080直接暴露公网不建议。生产环境挂一层反向代理做 TLS 最稳妥多节点同步文档 里有一份现成的 nginx 配置可以参考。服务端自带限流和 API key 管理实现RateLimiter.swift、ApiKeyManager.swift需要管控访问时可以用上。另外数据是 CC-BY-4.0展示数据时要保留来源署名。六、常见问题 FAQ 首次请求为什么很慢冷缓存。第一次请求某个变量需要从远端分发源取数单次可能涉及几 MB 数据之后同位置或邻近坐标的请求命中本地缓存通常亚秒返回。能不能不下载全量数据直接用能。API 可以直接读取远端开放数据源并本地缓存不需要先下完整个数据集。只有当你想完全离线、或者查询量很大时才需要用sync把数据完整拉到本地。想加一个新变量怎么办把变量追加到sync命令的变量列表即可。如果要走原始数据路线也可以让下载器按变量过滤例如download icon --run 00 --only-variables temperature_2m,weather_code。注意不是所有变量在所有模型上都提供。想绑域名对外提供怎么配nginx 反代到127.0.0.1:8080配上证书即可。Ubuntu 包版本默认只绑定 127.0.0.1外部不可访问天然安全直接加代理层就行。能商用吗自部署支持非商业与商业两种用途但注意两份协议源码是 AGPL-3.0修改后以服务形式对外提供需要开放你的修改版源码数据是 CC-BY-4.0必须署名。完整条款见 README。写在最后把主线再串一遍git clone→docker compose up -d→sync→curl验证这套 Open-Meteo 部署下来也就半小时的事。自建的最大价值不是省下几块钱接口费而是端点、变量、存储都在你手里可以按业务节奏改。如果你的项目涉及天气值得在服务器上给它留个位置。再往后延伸的空间也不小海洋 API、空气质量 API、80 年历史天气 API以及多节点分布式部署一台机器负责下载、多台机器共享查询——每个方向都值得单独展开。【免费下载链接】open-meteoFree Weather Forecast API for non-commercial use项目地址: https://gitcode.com/GitHub_Trending/op/open-meteo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考