Open-Meteo 本地部署3 步快速自建免费气象数据 API【免费下载链接】open-meteoFree Weather Forecast API for non-commercial use项目地址: https://gitcode.com/GitHub_Trending/op/open-meteoOpen-Meteo 是一个开源的气象数据平台把 NOAA GFS、DWD ICON、ECMWF IFS 等气象机构发布的公开预报统一成一套无需 API key 的 REST 接口。跑在自己的服务器上就等于自建气象服务数据落在自己机器接口随业务改不用向第三方按量付费。先跑起来3 条命令完成 Open-Meteo 本地部署 结论先说不用写代码也不用 clone 源码编译——官方镜像可以直接从公开数据库取数第一次请求就能出结果。先看硬件底线x86-64 或 Arm 服务器、至少 8GB 内存推荐 16GB、100GB 以上磁盘NVMe SSD 更好存储同时兼任缓存。详见 启动文档。创建数据卷存放气象数据和缓存docker volume create --name open-meteo-data启动 API 容器REMOTE_DATA_DIRECTORY指定公开数据库来源端口默认只绑定本机docker run -d --rm --name open-meteo \ -v open-meteo-data:/app/data \ -e REMOTE_DATA_DIRECTORYhttps://openmeteo.s3.amazonaws.com/data/ \ -e CACHE_SIZE8GB \ -p 127.0.0.1:8080:8080 \ ghcr.io/open-meteo/open-meteo发一条查询第一次会慢几秒要取数并写缓存之后就近坐标会明显变快curl http://127.0.0.1:8080/v1/forecast?latitude47.1longitude8.4modelsecmwf_ifs025hourlytemperature_2m如何确认跑成功响应是一段 JSON里面temperature_2m字段有完整的小时时间序列time 和 values说明本地气象服务已经可用。一句实话自托管实例是按需从公开数据库取数 本地缓存的模式响应通常比官方公网 API 慢适合有稳定、重复查询量的场景不适合只查一次。它是怎么工作的数据从哪来、怎么存、怎么查 打个比方各国气象机构是出厂的原料商Open-Meteo 是超市你的查询是直接从货架上拿一袋已经分装好的商品。数据从哪来各国气象机构公开发布的数值预报NOAA GFS、DWD ICON、ECMWF IFS、MeteoFrance 等免费可下载但原始格式是二进制 GRIB 文件直接用的话要懂网格、投影、二进制定制格式这些专业内容——这正是 Open-Meteo 替你做的事。怎么存下载后统一转换成它自研、开源的压缩二进制格式OM 文件存在./data目录。这个格式专为查某个地点一段时间序列优化比如取柏林未来 7 天的温度只需读很少的数据块。API 大约每 2 分钟检查一次公开数据库的预报更新并预加载本地数据则保留在CACHE_SIZE控制的 LRU 缓存里。对外怎么查标准的/v1/forecast这类 REST 接口参数就是经纬度、模型、变量返回 JSON。整个链路源码都在仓库里比如 预报 API 路由、数据读取层想改什么都能翻到出处。长期用得稳按需同步、控制存储、管住访问 跑起来之后真正花心思的是这三件事。1. 按需同步而不是全量下载默认配置下 API 已经会按需从公开数据库取数并缓存什么也不用做。想让数据完全落盘在自己机器上就另起一个容器跑sync命令只拉模型 变量组合源码见 SyncCommand.swiftdocker run -d --name open-meteo-sync \ -v open-meteo-data:/app/data \ ghcr.io/open-meteo/open-meteo \ sync dwd_icon temperature_2m --repeat-interval 5它每 5 分钟对账一次只下载缺失或新增的文件。官方 cronjob 示例列了直连各气象机构的全量时间表但官方明确提醒全量下载每天产生 4~8TB 流量务必只选业务需要的变量。2. 用定时任务压住存储占用存储占用 ≈ 变量数 × 时间深度历史数据只增不减必须定期清理。官方给出的做法是find按文件年龄分层删除例如删掉 30 天前的预报数据sync 文档里的例子用的是 Ubuntu 包路径Docker 部署对应到数据卷里的/app/datafind /app/data -type f -name chunk_* -mtime 30 -delete机器多时不必每台都下载指定一台机器跑下载其余 API 节点按 多节点同步方案 拉取现成数据库。3. 管住访问盯住指标默认端口只绑 127.0.0.1不要直接暴露公网对外开放就前置 nginx 反向代理顺带解决 TLS。多人共用可以启用内置的 API key 机制把 key 和限额写进文件、设置API_APIKEYS_PATH每个 key 有独立调用配额内置限流。/metrics接口输出 Prometheus 格式仅本机可访问请求数、错误数、缓存占用都有现成指标可直接接进已有监控实现在 MetricsController.swift。两个真实使用场景场景一给 App 加天气功能不想被第三方免费 API 卡脖子问题调用第三方免费 API 有每日请求量上限网络延迟也取决于别人的服务。做法在用户所在区域部署一个 Open-Meteo 本地部署节点App 后端改为调用本地 API热查坐标自动进缓存。效果接口与公网版完全一致业务代码不用改天气请求走内网配额和数据都归自己。场景二内部系统批量查天气农业、物流、户外排班问题系统每小时要对几百个坐标取天气反复走公网 API 费带宽、也费配额。做法自建节点用sync只拉业务用到的变量温度、降水、风速保留天数按业务设定。效果盘里只存真正要用的数据系统从此有了自己的气象服务数据还能离线分析和回测。怎么选Open-Meteo 自建 vs 其他方案对比项Open-Meteo 自建商业气象 API公网免费 Open-Meteo API费用免费只承担服务器成本按调用量或档位收费非商业用途免费数据掌控数据存本机完全自主数据在第三方不可控定制能力开源AGPL-3.0源码可改有限不可修改部署复杂度中等容器一键启动低无性能取决于自有机器和缓存依赖服务商公网延迟通常很快商用允许商用自托管数据为 CC-BY-4.0需署名可商用商用需另行联系适合谁需要持续、批量获取气象数据的开发者和团队——App 天气功能、智慧农业、物流与户外排班、能源预测这类场景。如果这个气象 API 就该跑在你自己的机器上不妨先把上面那 3 条命令跑一遍。【免费下载链接】open-meteoFree Weather Forecast API for non-commercial use项目地址: https://gitcode.com/GitHub_Trending/op/open-meteo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Open-Meteo 本地部署：3 步快速自建免费气象数据 API
Open-Meteo 本地部署3 步快速自建免费气象数据 API【免费下载链接】open-meteoFree Weather Forecast API for non-commercial use项目地址: https://gitcode.com/GitHub_Trending/op/open-meteoOpen-Meteo 是一个开源的气象数据平台把 NOAA GFS、DWD ICON、ECMWF IFS 等气象机构发布的公开预报统一成一套无需 API key 的 REST 接口。跑在自己的服务器上就等于自建气象服务数据落在自己机器接口随业务改不用向第三方按量付费。先跑起来3 条命令完成 Open-Meteo 本地部署 结论先说不用写代码也不用 clone 源码编译——官方镜像可以直接从公开数据库取数第一次请求就能出结果。先看硬件底线x86-64 或 Arm 服务器、至少 8GB 内存推荐 16GB、100GB 以上磁盘NVMe SSD 更好存储同时兼任缓存。详见 启动文档。创建数据卷存放气象数据和缓存docker volume create --name open-meteo-data启动 API 容器REMOTE_DATA_DIRECTORY指定公开数据库来源端口默认只绑定本机docker run -d --rm --name open-meteo \ -v open-meteo-data:/app/data \ -e REMOTE_DATA_DIRECTORYhttps://openmeteo.s3.amazonaws.com/data/ \ -e CACHE_SIZE8GB \ -p 127.0.0.1:8080:8080 \ ghcr.io/open-meteo/open-meteo发一条查询第一次会慢几秒要取数并写缓存之后就近坐标会明显变快curl http://127.0.0.1:8080/v1/forecast?latitude47.1longitude8.4modelsecmwf_ifs025hourlytemperature_2m如何确认跑成功响应是一段 JSON里面temperature_2m字段有完整的小时时间序列time 和 values说明本地气象服务已经可用。一句实话自托管实例是按需从公开数据库取数 本地缓存的模式响应通常比官方公网 API 慢适合有稳定、重复查询量的场景不适合只查一次。它是怎么工作的数据从哪来、怎么存、怎么查 打个比方各国气象机构是出厂的原料商Open-Meteo 是超市你的查询是直接从货架上拿一袋已经分装好的商品。数据从哪来各国气象机构公开发布的数值预报NOAA GFS、DWD ICON、ECMWF IFS、MeteoFrance 等免费可下载但原始格式是二进制 GRIB 文件直接用的话要懂网格、投影、二进制定制格式这些专业内容——这正是 Open-Meteo 替你做的事。怎么存下载后统一转换成它自研、开源的压缩二进制格式OM 文件存在./data目录。这个格式专为查某个地点一段时间序列优化比如取柏林未来 7 天的温度只需读很少的数据块。API 大约每 2 分钟检查一次公开数据库的预报更新并预加载本地数据则保留在CACHE_SIZE控制的 LRU 缓存里。对外怎么查标准的/v1/forecast这类 REST 接口参数就是经纬度、模型、变量返回 JSON。整个链路源码都在仓库里比如 预报 API 路由、数据读取层想改什么都能翻到出处。长期用得稳按需同步、控制存储、管住访问 跑起来之后真正花心思的是这三件事。1. 按需同步而不是全量下载默认配置下 API 已经会按需从公开数据库取数并缓存什么也不用做。想让数据完全落盘在自己机器上就另起一个容器跑sync命令只拉模型 变量组合源码见 SyncCommand.swiftdocker run -d --name open-meteo-sync \ -v open-meteo-data:/app/data \ ghcr.io/open-meteo/open-meteo \ sync dwd_icon temperature_2m --repeat-interval 5它每 5 分钟对账一次只下载缺失或新增的文件。官方 cronjob 示例列了直连各气象机构的全量时间表但官方明确提醒全量下载每天产生 4~8TB 流量务必只选业务需要的变量。2. 用定时任务压住存储占用存储占用 ≈ 变量数 × 时间深度历史数据只增不减必须定期清理。官方给出的做法是find按文件年龄分层删除例如删掉 30 天前的预报数据sync 文档里的例子用的是 Ubuntu 包路径Docker 部署对应到数据卷里的/app/datafind /app/data -type f -name chunk_* -mtime 30 -delete机器多时不必每台都下载指定一台机器跑下载其余 API 节点按 多节点同步方案 拉取现成数据库。3. 管住访问盯住指标默认端口只绑 127.0.0.1不要直接暴露公网对外开放就前置 nginx 反向代理顺带解决 TLS。多人共用可以启用内置的 API key 机制把 key 和限额写进文件、设置API_APIKEYS_PATH每个 key 有独立调用配额内置限流。/metrics接口输出 Prometheus 格式仅本机可访问请求数、错误数、缓存占用都有现成指标可直接接进已有监控实现在 MetricsController.swift。两个真实使用场景场景一给 App 加天气功能不想被第三方免费 API 卡脖子问题调用第三方免费 API 有每日请求量上限网络延迟也取决于别人的服务。做法在用户所在区域部署一个 Open-Meteo 本地部署节点App 后端改为调用本地 API热查坐标自动进缓存。效果接口与公网版完全一致业务代码不用改天气请求走内网配额和数据都归自己。场景二内部系统批量查天气农业、物流、户外排班问题系统每小时要对几百个坐标取天气反复走公网 API 费带宽、也费配额。做法自建节点用sync只拉业务用到的变量温度、降水、风速保留天数按业务设定。效果盘里只存真正要用的数据系统从此有了自己的气象服务数据还能离线分析和回测。怎么选Open-Meteo 自建 vs 其他方案对比项Open-Meteo 自建商业气象 API公网免费 Open-Meteo API费用免费只承担服务器成本按调用量或档位收费非商业用途免费数据掌控数据存本机完全自主数据在第三方不可控定制能力开源AGPL-3.0源码可改有限不可修改部署复杂度中等容器一键启动低无性能取决于自有机器和缓存依赖服务商公网延迟通常很快商用允许商用自托管数据为 CC-BY-4.0需署名可商用商用需另行联系适合谁需要持续、批量获取气象数据的开发者和团队——App 天气功能、智慧农业、物流与户外排班、能源预测这类场景。如果这个气象 API 就该跑在你自己的机器上不妨先把上面那 3 条命令跑一遍。【免费下载链接】open-meteoFree Weather Forecast API for non-commercial use项目地址: https://gitcode.com/GitHub_Trending/op/open-meteo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
