基于Python的城市内涝积涝监测数据可视化分析系统

基于Python的城市内涝积涝监测数据可视化分析系统毕业论文

毕业设计

一、项目名称：

基于Python的城市内涝积涝监测数据可视化分析系统

【摘要】

城市内涝是汛期公共安全与市政排水管理的重要议题。积水深度、小时降雨、预警等级等指标相互关联，但原始数据往往分散在气象接口、易涝点名录与水务监测平台中，存在口径不一、难以横向对比、缺少趋势研判等问题。本文设计并实现了基于 Python 与 Django 的城市内涝积涝监测数据可视化分析系统，面向教学与课题演示场景，将多源数据汇聚、清洗入库后，以交互式图表支撑汛情态势研判与结构分析。

系统采用 B/S 架构，后端基于 Django 3.1.14，管理端集成 SimpleUI；数据库使用 MySQL（库名 waterlog）；前台基于 Bootstrap 5 与 ECharts 5 完成可视化。业务数据以 FloodRecord 为核心，覆盖深圳市 40 个易涝测站、2024 年 5---9 月汛期小时级记录，总量约 2.4 万条，字段包含测站编码/名称、行政区/街道、经纬度、监测时间、水位、预警水位、小时/日降雨、预警等级及是否积水等。小时降雨来自 Open-Meteo Archive API 真实数据；积水水位基于真实降雨与点位排水敏感度估算（论文正文已说明，不代表水务局实测传感器读数）。数据采集通过 scripts/fetch_flood_data.py 生成 CSV，再经管理命令 import_flood 入库；系统未提供 Web 数据采集页，无独立大屏，无 Flask 组件。分析层以 pandas、NumPy 聚合，采用 Spearman/Pearson 相关、IQR 异常检测，以及线性外推与滑动平均对水位进行示意性预测。系统入口为 manage.py，默认运行端口 8070 ；前台登录路径为 /app/login/，后台为 /admin/，默认账号分别为 admin/123456（前台 app.User）与 admin/admin123（Django 后台）。侧栏涵盖数据总览、水位分析、降雨分析、行政区对比、预警分析、时序分析、相关性分析、水位预测、异常检测、数据列表/导出及个人信息维护等模块。utils 层封装 waterlog_core、waterlog_charts、waterlog_constants，分析结果经 Bundle API 一次返回多图数据，本地内存缓存 WATERLOG_CACHE_TTL=120 秒。

测试与运行结果表明，系统能够完成登录鉴权、多维筛选分析、图表联动与 CSV 导出闭环，界面清晰、响应稳定，可为城市内涝监测课题研究与教学演示提供可用的可视化分析支撑。

【关键词】 Django；城市内涝；数据可视化；ECharts；Spearman 相关

【Abstract】

Urban waterlogging is a critical issue for public safety and municipal drainage during flood seasons. Indicators such as water depth, hourly rainfall and warning grades are interrelated, yet raw data are often scattered across weather APIs, flood-prone site catalogs and water-authority platforms, which makes cross-site comparison and trend analysis difficult. This thesis designs and implements a Python- and Django-based urban waterlogging monitoring data visualization and analysis system for teaching and demonstration. Multi-source data are collected, cleaned and stored, then explored through interactive charts for situational awareness and structural analysis.

The system follows a B/S architecture. The backend is built with Django 3.1.14 and SimpleUI for administration; MySQL is used with database name waterlog; the frontend adopts Bootstrap 5 and ECharts 5. The core entity FloodRecord covers 40 monitoring stations in Shenzhen from May to September 2024 at hourly granularity (approximately 24,000 records), including station attributes, location, observation time, water level, warning threshold, rainfall, warning grade and flood flag. Hourly rainfall comes from the real Open-Meteo Archive API; water levels are estimated from rainfall and site sensitivity (not official sensor readings). Data are produced by scripts/fetch_flood_data.py and imported via import_flood; there is no web-based data-fetch page, no standalone big screen and no Flask stack. Analysis relies on pandas and NumPy, with Spearman/Pearson correlation, IQR outlier detection, and linear extrapolation plus moving average for illustrative forecasting. Entry point is manage.py, default port 8070 ; frontend login is /app/login/, admin is /admin/, default accounts admin/123456 and admin/admin123. Sidebar modules include overview, water level, rainfall, district comparison, warning analysis, time series, correlation, prediction, anomaly detection, list/export and profile settings. Utils packages waterlog_core, waterlog_charts and waterlog_constants; Bundle APIs return multi-chart payloads with local cache TTL of 120 seconds.

Results show that authentication, multi-dimensional filtering, chart interaction and CSV export workflows work stably, providing practical support for urban waterlogging analysis courses and research demos.

【Keywords】 Django; Urban Waterlogging; Data Visualization; ECharts; Spearman Correlation

[1.1 课题研究背景](#1.1 课题研究背景)
[1.2 课题研究的目的、意义](#1.2 课题研究的目的、意义)
[1.3 课题的国内外研究现状和发展动态](#1.3 课题的国内外研究现状和发展动态)
[1.4 研究内容](#1.4 研究内容)
[1.5 论文结构安排](#1.5 论文结构安排)

[2 关键技术](#2 关键技术)

[2.1 Django Web框架](#2.1 Django Web框架)
- [2.1.1 MTV模式与路由组织](#2.1.1 MTV模式与路由组织)
- [2.1.2 SimpleUI后台管理](#2.1.2 SimpleUI后台管理)
[2.2 MySQL数据库](#2.2 MySQL数据库)
- [2.2.1 ORM与索引设计](#2.2.1 ORM与索引设计)
- [2.2.2 PyMySQL驱动接入](#2.2.2 PyMySQL驱动接入)
[2.3 ECharts可视化技术](#2.3 ECharts可视化技术)
[2.4 数据分析与算法实现](#2.4 数据分析与算法实现)
[2.5 数据获取与水位估算](#2.5 数据获取与水位估算)
[2.6 技术特色与创新点](#2.6 技术特色与创新点)

[3 系统分析与设计](#3 系统分析与设计)

[3.1 系统总体设计](#3.1 系统总体设计)
- [3.1.1 系统架构设计](#3.1.1 系统架构设计)
- [3.1.2 系统数据流设计](#3.1.2 系统数据流设计)
- [3.1.3 系统功能模块设计](#3.1.3 系统功能模块设计)
[3.2 系统详细设计](#3.2 系统详细设计)
- [3.2.1 用户认证模块设计](#3.2.1 用户认证模块设计)
- [3.2.2 数据总览模块设计](#3.2.2 数据总览模块设计)
- [3.2.3 水位与降雨分析模块设计](#3.2.3 水位与降雨分析模块设计)
- [3.2.4 行政区与预警分析模块设计](#3.2.4 行政区与预警分析模块设计)
- [3.2.5 时序相关预测异常模块设计](#3.2.5 时序相关预测异常模块设计)
- [3.2.6 列表导出与后台模块设计](#3.2.6 列表导出与后台模块设计)
[3.3 数据库设计](#3.3 数据库设计)
- [3.3.1 数据库关系设计](#3.3.1 数据库关系设计)

[4 系统实现](#4 系统实现)

[4.0 系统整体实现流程](#4.0 系统整体实现流程)
[4.1 用户认证模块的实现](#4.1 用户认证模块的实现)
[4.2 数据总览模块的实现](#4.2 数据总览模块的实现)
[4.3 水位与降雨分析模块的实现](#4.3 水位与降雨分析模块的实现)
[4.4 行政区与预警分析模块的实现](#4.4 行政区与预警分析模块的实现)
[4.5 时序相关预测异常模块的实现](#4.5 时序相关预测异常模块的实现)
[4.6 列表导出与后台模块的实现](#4.6 列表导出与后台模块的实现)
[4.7 用户界面实现](#4.7 用户界面实现)
[4.8 系统集成与部署](#4.8 系统集成与部署)

[5 系统测试](#5 系统测试)

[5.1 系统功能测试](#5.1 系统功能测试)
- [5.1.1 用户认证功能测试用例](#5.1.1 用户认证功能测试用例)
- [5.1.2 数据管理功能测试用例](#5.1.2 数据管理功能测试用例)
- [5.1.3 核心业务功能测试用例](#5.1.3 核心业务功能测试用例)
- [5.1.4 数据分析功能测试用例](#5.1.4 数据分析功能测试用例)
- [5.1.5 系统集成功能测试用例](#5.1.5 系统集成功能测试用例)
- [5.1.6 用户界面功能测试用例](#5.1.6 用户界面功能测试用例)
[5.2 系统性能测试](#5.2 系统性能测试)
- [5.2.1 响应时间性能分析](#5.2.1 响应时间性能分析)
- [5.2.2 并发性能测试](#5.2.2 并发性能测试)
- [5.2.3 数据库性能测试](#5.2.3 数据库性能测试)
- [5.2.4 性能优化措施](#5.2.4 性能优化措施)

[6 总结与展望](#6 总结与展望)

[6.1 总结](#6.1 总结)
[6.2 展望](#6.2 展望)

参考文献

致谢

1 绪论

1.1 课题研究背景

极端天气频发背景下，城市低洼路段、下穿通道与地铁口等易涝点积水风险持续受到关注。管理部门、科研人员与教学实践在开展内涝分析时，通常需要同时查看积水深度、小时降雨、预警等级与空间分布等多类指标。然而，公开数据来源分散：气象小时降水、易涝点名录、水务局积涝水位接口往往分属不同平台，字段命名与时间粒度不一致，手工汇总成本高，也难以形成可复用的可视化分析流程。

深圳市作为沿海超大城市，汛期（通常为 5---9 月）短时强降水易引发道路积水。官方「市水务局积涝点水位」接口在深圳市政府数据开放平台发布，但批量调用需申请 appKey；在无密钥条件下，课题演示仍需可本地部署、可复现的数据样本。基于上述背景，本课题以 Django 为主框架，构建城市内涝积涝监测数据可视化分析系统：小时降雨采用 Open-Meteo 真实归档数据，积水水位在论文中明确标注为估算值，用于可视化与算法演示，不代表水务局实测传感器读数。

在教学与毕业设计场景中，还存在以下现实需求：一是需要一套可本地部署的 Web 系统，用统一库表承载测站小时级内涝样本；二是需要总览、水位、降雨、行政区、预警、时序、相关、预测与异常等常见分析视图，帮助快速理解"哪里易涝、雨峰与水位如何联动、预警结构如何"；三是需要脚本化数据获取与 CSV 导入闭环，形成"拉取---入库---分析---展示"流程。系统不提供独立大屏页面，也不采用 Flask 技术栈，聚焦常规 B/S 分析页的可解释表达。

1.2 课题研究的目的、意义

1.2.1 研究目的

本课题的主要目的包括：

建立以 FloodRecord 为核心的城市内涝监测数据模型，覆盖测站区位、水位、降雨、预警等级与是否积水等字段，支撑统一查询与聚合。
实现前台会话登录、侧栏导航与多分析页展示，路由统一挂载在 /app/ 前缀下，服务端口为 8070。
基于 pandas/NumPy 完成汇总、Spearman/Pearson 相关、IQR 异常检测，以及线性外推与滑动平均的示意性水位预测。
通过 scripts/fetch_flood_data.py 与 import_flood 管理命令完成数据初始化；后台 SimpleUI 维护监测记录与前台用户。
输出可运行、可演示的完整系统，默认前台账号 admin/123456、后台 admin/admin123，便于验收与二次扩展。

1.2.2 研究意义

理论意义：将 Web 开发、数据分析与可视化方法结合到城市内涝监测主题中，形成"数据模型---分析算法---图表表达"的可复用范式，有助于理解相关分析、异常检测与简单外推在时间序列演示中的适用边界。

实践意义：系统把测站属性、估算水位与真实降雨落到同一张业务表，降低手工处理成本；分析页通过 Bundle API 一次返回多图数据，便于前端快速渲染；缓存机制减轻重复聚合开销。

社会意义：可视化结果有助于直观认识行政区易涝差异、预警等级结构与降雨---水位联动关系，提升公众与学生对城市防汛议题的认知。

经济意义：本地化部署与开源技术栈降低课题演示成本；模块化 utils 设计便于后续替换数据源（如接入官方 appKey 真实水位）或扩展指标，减少重复开发投入。

1.3 课题的国内外研究现状和发展动态

1.3.1 国外研究现状

国外在城市水文、排水管网建模与气象再分析数据方面积累较早。Open-Meteo 等气象归档接口为研究提供了可程序化获取的历史降水、湿度等要素。可视化方面，D3.js、Plotly、ECharts 等库被广泛用于交互式地图与时间序列展示。内涝模拟常结合 SWMM 等水文模型，但教学演示场景仍大量使用可解释性强的统计相关、箱线分析与简单趋势外推。

1.3.2 国内研究现状

国内城市易涝点治理与气象灾害风险提示信息发布持续推进，公开报道与应急提示中可获取易积水路段名称。高校毕业设计中常见 Django + ECharts 的可视化系统，主题涵盖空气质量、交通流量与防汛监测等。部分系统侧重大屏展示，部分侧重后台 CRUD。本课题更强调"六大分析模块 + Bundle API + 脚本化入库"，并以 MySQL 持久化约 2.4 万条深圳汛期样本，兼顾可解释算法与可复现部署；无独立大屏路由。

1.3.3 发展趋势

未来城市内涝分析将更强调多源融合、近实时更新与可解释预警。可视化从静态报表走向可筛选、可下钻的交互分析；后端则更注重缓存、索引与版本化失效。对本系统而言，后续可接入深圳开放平台真实水位、扩展更多预测模型与权限分级，但仍应保持教学场景下结构清晰、部署简单的特点。

1.4 研究内容

本课题主要研究内容如下：

需求分析与总体设计：明确用户角色（前台用户、后台管理员）、功能边界与非功能约束（端口 8070、库名 waterlog、无独立大屏、无 Web 采集页）。
数据模型与入库 ：设计 User、FloodRecord 两张核心业务表，完成迁移、CSV 导入与索引优化；说明 Open-Meteo 真实降雨与水位估算逻辑。
分析与可视化：实现数据总览、水位与降雨分析、行政区与预警分析、时序/相关/预测/异常分析，以及数据列表与 CSV 导出。
数据获取脚本 ：实现 fetch_flood_data.py 拉取降雨并生成估算水位 CSV，经 import_flood 批量入库；可选配置 SZ_OPENDATA_APPKEY 切换官方水位。
测试与总结：按功能与性能维度组织用例，量化模块规模与数据量级，给出改进方向。

1.5 论文结构安排

全文共六章。第1章介绍背景、意义、现状与研究内容；第2章说明 Django、MySQL、ECharts、pandas 缓存、数据获取与水位估算等关键技术；第3章给出架构、数据流、功能结构、六大模块详细设计与数据库 ER；第4章按模块阐述实现流程、关键代码、访问路径与界面图题；第5章给出功能与性能测试；第6章总结成果并展望后续工作。文末附参考文献与致谢。

2 关键技术

2.1 Django Web框架

本系统后端采用 Django 3.1.14。Django 提供成熟的 ORM、模板引擎、中间件与管理后台，适合快速构建以数据查询与页面渲染为主的分析型 Web 应用。项目入口为根目录 manage.py，配置位于 基于Django系统/settings.py，根路由在 基于Django系统/urls.py 中将 admin/ 与 app/ 分别挂载。

2.1.1 MTV模式与路由组织

Django 遵循 MTV（Model-Template-View）模式：app/models.py 定义 User 与 FloodRecord；app/views.py 处理页面渲染与用户操作；app/api_views.py 处理 JSON Bundle；模板位于 app/templates 与 templates。业务路由集中在 app/urls.py，统一由 /app/ 前缀引入，例如登录 /app/login/、总览 /app/home/、水位 /app/water_level/ 等。自定义中间件 middleware.auth.AuthMiddleware 用于会话鉴权，保护分析页访问。

2.1.2 SimpleUI后台管理

系统在 INSTALLED_APPS 中引入 simpleui，通过 SIMPLEUI_CONFIG 定制菜单，将"内涝监测数据"与"用户与权限"分组展示，后台入口为 /admin/。SimpleUI 在默认 Django Admin 之上提供更清晰的中文管理界面，便于对 FloodRecord 进行检索、筛选与维护；增删改后调用 invalidate_waterlog_cache() 使分析缓存失效，与前台分析共用同一数据库。

2.2 MySQL数据库

持久化层使用 MySQL，默认库名为 waterlog，连接参数可通过环境变量覆盖（用户、密码、主机、端口）。字符集配置为 utf8mb4，满足中文测站名、街道名与备注字段存储需求。

2.2.1 ORM与索引设计

FloodRecord 对 station_code、district、observe_time、warn_grade、is_flooded 等字段建立单列索引，并在 Meta 中声明组合索引 idx_flood_time_dist、idx_flood_time_warn，以加速按时间与行政区、预警等级过滤的聚合查询。分析模块大量使用 Count、Avg、Max、Sum 等聚合，再将结果转为 pandas DataFrame 进一步计算相关矩阵、IQR 边界与预测序列。

2.2.2 PyMySQL驱动接入

依赖清单 requirements.txt 包含 PyMySQL，作为 Django MySQL 后端的常用驱动方案，配合 django.db.backends.mysql 完成连接。开发环境默认密码与 README 中初始化流程一致，便于一键迁移与导入。

2.3 ECharts可视化技术

前台图表基于 ECharts 5，页面骨架使用 Bootstrap 5。分析页通过 AJAX 请求 /app/api/overview/、/app/api/water-level-bundle/、/app/api/rain-bundle/ 等接口获取 JSON，再在浏览器端初始化折线、柱状、饼图、箱线、热力、散点等组件。图表配置与公共辅助脚本位于 static/js/（如 waterlog_pages.js、chart_helpers.js），主题样式由 waterlog-theme.css 统一，采用深蓝侧栏与蓝黄橙红预警配色。系统不提供独立大屏路由，可视化集中在侧栏各分析页内完成。

2.4 数据分析与算法实现

数据处理依赖 pandas、NumPy。核心逻辑封装在 app/utils/waterlog_core.py 与 app/utils/waterlog_charts.py：

相关分析 ：对水位、预警水位、小时/日降雨、是否积水等变量，优先计算 Spearman 秩相关矩阵，失败时回退 Pearson 线性相关（correlation_bundle）。
异常检测 ：采用 IQR（四分位距）法，计算 Q1、Q3 与 1.5×IQR 上下界，标记超出区间的水位记录（iqr_outliers）。
示意性预测 ：对全网小时平均水位序列做一元线性拟合（np.polyfit），外推未来 24 小时，并叠加滑动平均（窗口 6）作为平滑参考；强调其为课题演示用途，不可替代正式防汛预报。
缓存：cached_analysis_df 与 _cache_bundle 结合 WATERLOG_CACHE_TTL=120 秒及 waterlog:cache_version 版本号，在筛选条件不变时复用 DataFrame 与 Bundle 结果。

图表说明与 KPI 组装位于 waterlog_charts.py，常量与 CSV 列映射位于 waterlog_constants.py，保证前后台字段中文名与计算口径一致。

2.5 数据获取与水位估算

数据采集由命令行脚本 scripts/fetch_flood_data.py 执行，非 Web 页面触发。脚本从 Open-Meteo Archive API 拉取深圳坐标附近的小时降水（真实数据，原始缓存于 data/raw/open_meteo/），结合 data/raw/stations_sz_flood.csv 中的 40 个易涝测站字典，按公式估算积水水位：

复制代码

水位cm ≈ 底噪 + 小时降雨 × 敏感度 × 系数 + 日累计超额项 + 噪声
预警等级 = 水位相对预警水位cm的分档
是否积水 = 水位接近或超过预警水位时记为 1

论文与 data/DATA_SOURCES.md 均明确：默认交付的 waterlog_data.csv 约 2.4 万行，时间范围 2024-05-01 ~ 2024-09-30；小时降雨为真实，水位为估算。若在深圳开放平台申请 appKey 并设置环境变量 SZ_OPENDATA_APPKEY，可重新执行脚本尝试切换官方积涝水位接口。入库命令为 python manage.py import_flood --path waterlog_data.csv --truncate。

2.6 技术特色与创新点

算法方面：在同一系统中集成 Spearman/Pearson 相关、IQR 异常与线性外推+滑动平均预测，并附算法说明卡片，便于答辩时解释"怎么算、算什么、边界在哪"。

数据处理方面 ：以 filtered_queryset + 本地内存缓存（WATERLOG_CACHE_TTL=120）降低重复聚合开销；脚本拉取与 CSV 导入并存，兼顾离线初始化与可选官方数据源切换。

可视化特色：分析页采用 Bundle API 一次返回多图数据，减少请求次数；图表类型覆盖 KPI 总览、分布、箱线、热力、相关矩阵与预测对比等常见防汛分析视角。

架构优势：views 负责页面，api_views 负责 JSON，utils 分层（core / charts / constants / data_analysis），职责清晰，便于维护。

体验方面：Bootstrap 响应式布局 + SimpleUI 中文后台，侧栏分组明确；登录后即可按模块浏览，无独立大屏依赖。

3 系统分析与设计

3.1 系统总体设计

3.1.1 系统架构设计

系统采用经典三层 B/S 结构：表现层为登录页、首页与各分析模板；业务层包含认证、分析聚合、相关/异常/预测计算与 CSV 导出；数据层为 MySQL waterlog 库及原始缓存目录 data/raw/。浏览器通过 HTTP 访问 8070 端口，Django 处理页面与 API，分析计算在服务端完成后再以 JSON 驱动 ECharts 渲染。

图3.1 系统架构图

复制代码

数据访问层

业务逻辑层

表现层

MySQL: waterlog

waterlog_data.csv

data/raw Open-Meteo/测站字典

fetch_flood_data.py

会话认证 AuthMiddleware

views 页面视图

api_views JSON接口

waterlog_core 筛选缓存

waterlog_charts 聚合算法

waterlog_constants 常量映射

数据总览首页

分析模块页

数据列表/导出

SimpleUI后台

3.1.2 系统数据流设计

从外部看，前台用户提交账号口令进入系统，管理员通过后台维护记录，Open-Meteo 与测站字典向脚本层提供原始数据。系统内部完成鉴权、查询过滤、分析计算、图表输出与入库。

图3.2 顶层数据流图

复制代码

账号/筛选条件

CRUD操作

原始JSON/CSV

页面与图表

管理反馈

缓存原始文件

业务记录

前台用户

城市内涝监测可视化分析系统

后台管理员

外部数据源

Open-Meteo / 测站字典

可选深圳开放平台

本地 data/raw

MySQL waterlog

图3.3 0层数据流图

复制代码

前台用户

1.0 用户认证

2.0 筛选与查询

3.0 分析聚合与算法

4.0 图表渲染支持

5.0 列表与导出

管理员

6.0 后台管理

运维/初始化

7.0 脚本拉取与导入

User表

FloodRecord表

外部数据源

CSV/原始缓存

3.1.3 系统功能模块设计

结合侧栏实际菜单与 thesis_diagram_config 划分，系统功能划分为六大模块：（1）用户认证；（2）数据总览；（3）水位与降雨分析；（4）行政区与预警分析；（5）时序相关预测异常；（6）列表导出与后台。各模块对应独立页面路由与 Bundle API，个人信息维护（修改资料、密码）挂载于认证模块延伸功能。

图3.4 系统功能结构图

复制代码

城市内涝积涝监测数据可视化分析系统

用户认证

数据总览

水位与降雨分析

行政区与预警分析

时序相关预测异常

列表导出与后台

登录注册退出

修改信息与密码

首页KPI

总览图表接口

水位分析

降雨分析

行政区对比

预警分析

时序分析

3.2 系统详细设计

3.2.1 用户认证模块设计

模块负责前台注册、登录、退出及会话保持。用户信息存储于自定义 User 表；登录成功后将 username 写入 request.session，后续页面通过 _user(request) 读取。中间件对未登录访问进行拦截并引导至登录页。前台默认账号 admin/123456；Django 内置后台管理员账号 admin/admin123，与前台用户表分离。

3.2.1.1 用户认证流程设计

图3.5 用户认证模块流程图

复制代码

GET

POST

匹配

不匹配

通过

失败

访问 /app/login/

请求方法

渲染登录页

读取用户名密码

User表校验

写入 session.username

跳转 /app/home/

返回错误提示

访问 /app/register/

注册校验

创建 User 记录

跳转登录页

提示空值/重复/密码不一致

3.2.2 数据总览模块设计

数据总览页面路由为 /app/home/，前端调用 /app/api/overview/ 获取 KPI 卡片、行政区积水柱图、预警等级饼图与全网小时平均水位时序等 Bundle 数据。服务端在过滤后的 FloodRecord 上聚合记录数、测站数、积水率、平均水位、最大小时降雨与时间范围，供首页级汛情研判使用。服务端 home 视图另调用 FloodDataAnalysis.get_summary_stats() 渲染首屏 KPI。

3.2.2.1 数据总览流程设计

图3.6 数据总览模块流程图

复制代码

进入 /app/home/

读取筛选参数 month/district/warn_grade

filtered_queryset / cached_analysis_df

overview_bundle 聚合 KPI

区积水柱图/预警饼图/水位时序

返回 JSON

ECharts 与 KPI 卡片渲染

结束

3.2.3 水位与降雨分析模块设计

水位分析页 /app/water_level/ 依赖 /app/api/water-level-bundle/，展示水位频率分布、Top 测站均水位与分行政区箱线图。降雨分析页 /app/rain/ 依赖 /app/api/rain-bundle/，展示小时降雨与水位双轴时序、降雨---水位散点。两页共享月份/行政区/预警等级筛选与缓存机制。

3.2.3.1 水位与降雨分析流程设计

图3.7 水位与降雨分析模块流程图

复制代码

水位

降雨

进入水位或降雨页

携带筛选条件请求 Bundle

cached_analysis_df

页面类型

直方分布/Top测站/箱线

小时时序/散点抽样

JSON 返回

多图联动渲染

3.2.4 行政区与预警分析模块设计

行政区对比页 /app/district/ 调用 /app/api/district-bundle/，按行政区聚合平均水位、平均降雨与积水率，并以测站经纬度生成空间散点。预警分析页 /app/warning/ 调用 /app/api/warning-bundle/，展示预警等级占比与各等级内积水率对比，检验高等级预警是否对应更高积水概率。

3.2.4.1 行政区与预警分析流程设计

图3.8 行政区与预警分析模块流程图

复制代码

行政区

预警

进入行政区或预警页

请求 district/warning bundle

按筛选条件取数

模块分支

分组聚合 + 经纬度散点

等级占比 + 等级积水率

返回 JSON

柱状/散点/饼图渲染

3.2.5 时序相关预测异常模块设计

时序分析页 /app/time_series/ 展示日均水位与星期×小时热力矩阵。相关性页 /app/correlation/ 展示 Spearman/Pearson 相关矩阵及降雨---水位系数。预测页 /app/prediction/ 对小时平均水位做线性外推 24 小时并叠加滑动平均。异常页 /app/anomaly/ 基于 IQR 标记异常水位并在时序上高亮。四页分别对应 time-series、correlation、prediction、anomaly 四个 Bundle API。

3.2.5.1 时序相关预测异常流程设计

图3.9 时序相关预测异常模块流程图

复制代码

时序

3.2.6 列表导出与后台模块设计

数据列表页 /app/flood_list/ 对 FloodRecord 分页展示，支持月份、行政区、预警等级筛选，并统计列表内记录数、测站数、平均水位、最大降雨与积水率。导出接口 /app/api/export/ 按当前筛选条件流式输出 UTF-8 BOM 的 CSV。后台 /admin/ 基于 SimpleUI 维护内涝监测记录与前台用户，增删改后刷新分析缓存。数据初始化由 fetch_flood_data.py + import_flood 完成，无 Web 采集页。

3.2.6.1 列表导出与后台流程设计

图3.10 列表导出与后台模块流程图

复制代码

翻页/筛选

导出

打开 /app/flood_list/

filtered_queryset 分页

展示记录与列表统计

用户操作

GET /app/api/export/

iterator 流式写 CSV

浏览器下载 waterlog_export.csv

管理员登录 /admin/

CRUD FloodRecord/User

invalidate_waterlog_cache

初始化

fetch_flood_data.py

import_flood 入库

3.3 数据库设计

3.3.1 数据库关系设计

系统业务库为 MySQL 中的 waterlog。核心实体为前台用户表 User 与内涝监测记录表 FloodRecord。二者无强制外键关联：登录态通过 Session 绑定用户名；内涝分析直接查询 FloodRecord。后台 Django 内置权限表由框架维护，业务论文重点描述上述两张自定义表。

图3.11 数据库表关系图

复制代码

USERintidPK主键varcharusername用户名varcharpassword密码varcharsex性别varcharaddress地址varcharavatar头像路径varchartextarea个人简介datetimecreateTime创建时间FLOOD_RECORDbigintidPK主键varcharstation_code测站编码varcharstation_name测站名称varchardistrict行政区varcharstreet街道floatlongitude站点经度floatlatitude站点纬度datetimeobserve_time监测时间floatwater_level_cm水位(cm)floatwarn_level_cm预警水位(cm)floatrain_hour_mm小时降雨(mm)floatrain_day_mm日累计降雨(mm)varcharwarn_grade预警等级intis_flooded是否积水会话用户可查询分析

表3.1 USER（前台用户）表结构

字段名称	字段类型	字段说明	是否主键	是否为空
id	int	唯一标识	是	否
username	varchar(255)	用户名	否	否
password	varchar(255)	密码	否	否
sex	varchar(255)	性别	否	是
address	varchar(255)	地址	否	是
avatar	varchar/文件路径	头像	否	是
textarea	varchar(255)	个人简介	否	是
createTime	datetime	创建时间	否	否

表3.2 FLOOD_RECORD（内涝监测记录）表结构

字段名称	字段类型	字段说明	是否主键	是否为空
id	bigint	唯一标识	是	否
station_code	varchar(64)	测站编码	否	否
station_name	varchar(128)	测站名称	否	否
district	varchar(64)	行政区	否	否
street	varchar(64)	街道	否	否
longitude	float	站点经度	否	否
latitude	float	站点纬度	否	否
observe_time	datetime	监测时间	否	否
water_level_cm	float	水位(cm)，默认估算	否	否
warn_level_cm	float	预警水位(cm)	否	否
rain_hour_mm	float	小时降雨(mm)，Open-Meteo真实	否	否
rain_day_mm	float	日累计降雨(mm)	否	否
warn_grade	varchar(32)	预警等级	否	否
is_flooded	int	是否积水(0/1)	否	否

4 系统实现

4.0 系统整体实现流程

系统实现按"环境与库表 → 脚本拉取与导入 → 认证与总览 → 分析 Bundle API → 各分析页 → 列表导出 → 后台配置 → 联调测试"推进。开发入口为 manage.py，配置库名 waterlog，迁移后导入约 2.4 万条样本，再以 runserver 8070 启动服务。

图4.0 系统整体实现流程图

复制代码

项目初始化与依赖安装

配置 MySQL waterlog

migrate 建表

fetch_flood_data.py 生成 CSV

import_flood 导入约2.4万条

seed_admin 初始化账号

实现用户认证

实现数据总览 home + overview API

实现水位/降雨/行政区/预警 Bundle

实现时序/相关/预测/异常 Bundle

实现列表分页与 CSV 导出

配置 SimpleUI 后台

联调与功能测试

端口8070部署演示

4.1 用户认证模块的实现

用户认证实现于 app/views.py。GET 请求渲染登录模板；POST 请求校验 User 表用户名与密码，成功则写入 Session 并跳转首页，失败则返回错误提示。注册流程校验空值、两次密码一致性与账号唯一性。

功能实现流程设计

图4.1 用户认证模块实现流程图

复制代码

GET

POST

成功

失败

打开登录页

GET还是POST

render login.html

读取 username/password

User.objects.get 校验

session 保存用户名

redirect /app/home/

errorResponse 提示

核心代码实现

复制代码

# 来源：app/views.py — 前台登录
def login(request):
    if request.method == "GET":
        return render(request, "login.html")
    username = request.POST.get("username")
    password = request.POST.get("password")
    try:
        User.objects.get(username=username, password=password)
        request.session["username"] = username
        return redirect("/app/home/")
    except User.DoesNotExist:
        return errorResponse.errorResponse(request, "用户名或密码错误")

复制代码

# 来源：app/urls.py — 认证相关路由（节选）
path("login/", views.login, name="login"),
path("register/", views.register, name="register"),
path("logOut/", views.logOut, name="logOut"),
path("changeSelfInfo/", views.changeSelfInfo, name="changeSelfInfo"),
path("changePassword/", views.changePassword, name="changePassword"),

实现效果展示

访问路径 ：http://127.0.0.1:8070/app/login/（默认账号 admin / 123456）

图4.7 用户登录界面

登录页采用水利监测主题背景与居中表单，用户输入账号密码后提交，成功进入数据总览首页。

4.2 数据总览模块的实现

数据总览页面由 home 视图渲染模板并注入服务端 KPI，前端再请求 api_overview 调用 overview_bundle 补全图表。overview_bundle 对过滤后的查询集计算记录数、测站数、积水率、平均水位、最大小时降雨，并生成行政区积水柱图、预警饼图与抽样后的水位时序。

功能实现流程设计

图4.2 数据总览模块实现流程图

复制代码

访问 /app/home/

home 视图注入 stats

请求 /app/api/overview/

cached_analysis_df

overview_bundle 聚合 KPI

组装柱图/饼图/时序

前端 ECharts 渲染

结束

核心代码实现

复制代码

# 来源：app/utils/waterlog_charts.py — 总览汇总（节选）
def overview_bundle(request):
    def build():
        df = cached_analysis_df(request)
        if df.empty:
            return _empty_bundle()
        n = len(df)
        station_n = int(df["station_code"].nunique())
        flood_rate = _num(df["is_flooded"].mean() * 100, 1)
        # ... 行政区积水柱图、预警饼图、水位时序 ...
    return _cache_bundle("overview", request, build)

复制代码

# 来源：app/api_views.py — 总览 API
@require_GET
def api_overview(request):
    return json_ok(overview_bundle(request))

实现效果展示

访问路径 ：http://127.0.0.1:8070/app/home/

图4.8 数据总览界面

首页展示 KPI 卡片、行政区积水次数柱图、预警等级饼图与全网平均水位时序，支持月份/行政区/预警等级筛选联动。

4.3 水位与降雨分析模块的实现

水位分析通过 water_level_bundle 输出分布直方、Top 测站均水位与分行政区箱线；降雨分析通过 rain_bundle 输出小时降雨与水位双轴时序及降雨---水位散点。页面路由分别为 /app/water_level/ 与 /app/rain/，对应 module_water_level 与 module_rain 视图。

功能实现流程设计

图4.3 水位与降雨分析模块实现流程图

复制代码

水位

降雨

访问 water_level 或 rain

请求对应 bundle API

cached_analysis_df

模块分支

_hist_bins / box_by_district

hourly agg / scatter sample

json_ok 返回

分布/箱线/时序/散点渲染

核心代码实现

复制代码

# 来源：app/views.py — 页面入口
def module_water_level(request):
    return _module_page(request, "modules/water_level.html")

def module_rain(request):
    return _module_page(request, "modules/rain.html")

复制代码

# 来源：app/urls.py — 水位/降雨路由与 API（节选）
path("water_level/", views.module_water_level, name="module_water_level"),
path("rain/", views.module_rain, name="module_rain"),
path("api/water-level-bundle/", api_views.api_water_level_bundle, name="api_water_level_bundle"),
path("api/rain-bundle/", api_views.api_rain_bundle, name="api_rain_bundle"),

实现效果展示

访问路径：

水位分析：http://127.0.0.1:8070/app/water_level/
降雨分析：http://127.0.0.1:8070/app/rain/

图4.9 水位分析界面

水位页展示积水深度频率分布、平均水位 Top 测站排行及分行政区箱线图，便于对比区域差异。

图4.10 降雨分析界面

降雨页展示小时降雨与水位联动时序及降雨---水位散点，用于观察雨峰与水位抬升关系。

4.4 行政区与预警分析模块的实现

行政区模块通过 district_bundle 按区分组聚合平均水位、降雨与积水率，并以测站经纬度生成空间散点。预警模块通过 warning_bundle 统计预警等级占比与各等级积水率。页面路由分别为 /app/district/ 与 /app/warning/。

功能实现流程设计

图4.4 行政区与预警分析模块实现流程图

复制代码

行政区

预警

访问 district 或 warning

请求 district/warning bundle

cached_analysis_df

模块分支

groupby district + map_scatter

warn_share + flood_by_grade

返回 JSON

对比柱图/散点/饼图渲染

核心代码实现

复制代码

# 来源：app/api_views.py — 行政区/预警 Bundle
@require_GET
def api_district_bundle(request):
    return _bundle(district_bundle, request)

@require_GET
def api_warning_bundle(request):
    return _bundle(warning_bundle, request)

复制代码

# 来源：app/utils/waterlog_constants.py — 预警等级顺序
WARN_GRADES = ["正常", "蓝色预警", "黄色预警", "橙色预警", "红色预警"]

实现效果展示

访问路径：

行政区对比：http://127.0.0.1:8070/app/district/
预警分析：http://127.0.0.1:8070/app/warning/

图4.11 行政区对比界面

行政区页展示各辖区平均水位、降雨与积水率对比柱图，以及测站经纬度散点，便于空间巡检。

图4.12 预警分析界面

预警页展示预警等级占比饼图与各等级积水率对比，用于检验预警结构与实际积水关联。

4.5 时序相关预测异常模块的实现

时序模块输出日均水位与星期×小时热力；相关模块优先 Spearman 矩阵；预测模块对小时均水位线性外推 24 小时并叠加滑动平均；异常模块以 IQR 标记离群水位。四页路由为 /app/time_series/、/app/correlation/、/app/prediction/、/app/anomaly/。

功能实现流程设计

图4.5 时序相关预测异常模块实现流程图

复制代码

时序

核心代码实现

复制代码

# 来源：app/utils/waterlog_core.py — IQR 异常检测
def iqr_outliers(values):
    arr = np.asarray(values, dtype=float)
    arr = arr[~np.isnan(arr)]
    if len(arr) < 4:
        return np.zeros(len(arr), dtype=bool), {}
    q1, q3 = np.percentile(arr, [25, 75])
    iqr = q3 - q1
    low, high = q1 - 1.5 * iqr, q3 + 1.5 * iqr
    mask = (arr < low) | (arr > high)
    return mask, {"q1": _num(q1), "q3": _num(q3), "iqr": _num(iqr), "low": _num(low), "high": _num(high)}

复制代码

# 来源：app/utils/waterlog_charts.py — 相关与预测（节选）
method = "spearman"
try:
    corr = sub.corr(method="spearman")
except Exception:
    method = "pearson"
    corr = sub.corr(method="pearson")
# 预测：coef = np.polyfit(x, y, 1)，外推 horizon=24 小时

复制代码

# 来源：app/urls.py — 时序/相关/预测/异常路由（节选）
path("time_series/", views.module_time_series, name="module_time_series"),
path("correlation/", views.module_correlation, name="module_correlation"),
path("prediction/", views.module_prediction, name="module_prediction"),
path("anomaly/", views.module_anomaly, name="module_anomaly"),
path("api/correlation-bundle/", api_views.api_correlation_bundle, name="api_correlation_bundle"),
path("api/prediction-bundle/", api_views.api_prediction_bundle, name="api_prediction_bundle"),
path("api/anomaly-bundle/", api_views.api_anomaly_bundle, name="api_anomaly_bundle"),

实现效果展示

访问路径：

时序分析：http://127.0.0.1:8070/app/time_series/
相关性分析：http://127.0.0.1:8070/app/correlation/
水位预测：http://127.0.0.1:8070/app/prediction/
异常检测：http://127.0.0.1:8070/app/anomaly/

图4.13 时序分析界面

时序页展示日均水位折线与星期×小时热力矩阵，用于发现周内与日内易涝时段。

图4.14 相关性分析界面

相关页展示变量相关矩阵热力图及降雨---水位系数说明，强调相关不等于因果。

图4.15 水位预测界面

预测页对比历史水位、线性拟合、滑动平均与未来 24 小时外推曲线，并附算法说明卡片。

图4.16 异常检测界面

异常页在时序上标注 IQR 离群点，并列出异常样本表（测站、时间、水位、预警等级）。

4.6 列表导出与后台模块的实现

数据列表页对 FloodRecord 分页展示并统计列表 KPI；导出接口按筛选条件流式输出 CSV。后台通过 SimpleUI 管理监测记录，增删改后调用 invalidate_waterlog_cache。数据初始化由脚本与管理命令完成，系统不提供 Web 数据采集页。

功能实现流程设计

图4.6 列表导出与后台模块实现流程图

复制代码

是

否

访问 /app/flood_list/

filtered_queryset + Paginator

渲染分页表格与 list_stats

导出?

api_export iterator 写 CSV

继续浏览/筛选

访问 /admin/

FloodRecordAdmin CRUD

invalidate_waterlog_cache

fetch_flood_data.py

import_flood --truncate

约2.4万条入库

核心代码实现

复制代码

# 来源：app/views.py — CSV 导出（节选）
@require_GET
def api_export(request):
    if not request.session.get("username"):
        return redirect("/app/login/")
    qs = filtered_queryset(request)
    buf = io.StringIO()
    buf.write("\ufeff")
    writer = csv.writer(buf)
    writer.writerow([field_label(f, with_unit=True) for f in EXPORT_FIELDS])
    for row in qs.values_list(*EXPORT_FIELDS).iterator(chunk_size=2000):
        writer.writerow(row)
    resp = HttpResponse(buf.getvalue(), content_type="text/csv; charset=utf-8")
    resp["Content-Disposition"] = 'attachment; filename="waterlog_export.csv"'
    return resp

复制代码

# 来源：app/admin.py — 后台缓存失效
def save_model(self, request, obj, form, change):
    super().save_model(request, obj, form, change)
    invalidate_waterlog_cache()

复制代码

# 来源：基于Django系统/settings.py — 数据库与缓存（节选）
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.mysql",
        "NAME": os.environ.get("MYSQL_DATABASE", "waterlog"),
        ...
    }
}
WATERLOG_CACHE_TTL = 120

实现效果展示

访问路径：

数据列表：http://127.0.0.1:8070/app/flood_list/
CSV 导出：http://127.0.0.1:8070/app/api/export/
后台管理：http://127.0.0.1:8070/admin/（admin / admin123）

图4.17 数据列表界面

列表页分页展示监测记录，支持月份/行政区/预警等级筛选，并提供导出按钮与列表内统计摘要。

图4.18 后台管理界面

SimpleUI 后台提供内涝监测记录与前台用户的检索、筛选与维护，菜单分组清晰。

4.7 用户界面实现

界面采用 Bootstrap 5 布局，侧栏按"数据总览 / 水位与降雨 / 行政区与预警 / 时序相关预测异常 / 数据列表 / 个人信息"分组。主题样式由 waterlog-theme.css 统一，登录背景使用 waterlog-bg.jpg。各分析页复用 chart_base.html 骨架与 waterlog_pages.js 请求 Bundle API，筛选条通过 /app/api/options/ 获取行政区、月份与预警等级下拉。系统无独立大屏路由，所有可视化均在常规页面内完成；无 Flask 组件。

4.8 系统集成与部署

部署步骤概要如下：

安装 requirements.txt 依赖（Django 3.1.14、django-simpleui、PyMySQL、pandas、numpy、scipy、pillow、requests 等）。
创建 MySQL 库 waterlog，配置连接账号。
执行 python manage.py migrate。
执行 python scripts/fetch_flood_data.py 生成 waterlog_data.csv。
执行 python manage.py import_flood --path waterlog_data.csv --truncate 写入约 2.4 万条记录。
python manage.py seed_admin 初始化前台用户 admin/123456 与后台 admin/admin123。
python manage.py runserver 8070。

根 URL 将空路径重定向到 /app/login/，静态与媒体资源由 Django 开发服务器挂载。课题演示以 8070 端口本地运行为准。可选：配置 SZ_OPENDATA_APPKEY 后重新拉取以尝试官方真实水位。

5 系统测试

5.1 系统功能测试

测试环境：Windows 10，Python 3.11，Django 3.1.14，MySQL（库 waterlog），浏览器访问 http://127.0.0.1:8070。前台默认账号 admin/123456，后台 admin/admin123。

5.1.1 用户认证功能测试用例

编号	说明	条件	操作步骤	预期结果	实际结果
TC-A01	正确登录	库中存在 admin	打开 `/app/login/`，输入 admin/123456 提交	跳转 `/app/home/`，侧栏可见	通过
TC-A02	错误密码	账号存在	输入错误密码提交	提示用户名或密码错误	通过
TC-A03	注册新用户	用户名未占用	`/app/register/` 填写一致密码	注册成功并回到登录页	通过
TC-A04	退出登录	已登录	执行 `/app/logOut/`	Session 清空，回到登录页	通过

5.1.2 数据管理功能测试用例

编号	说明	条件	操作步骤	预期结果	实际结果
TC-B01	数据列表浏览	已导入样本	打开 `/app/flood_list/`	分页展示内涝监测记录	通过
TC-B02	后台查看记录	管理员可进 Admin	登录 `/admin/` 打开内涝监测记录	可检索测站/行政区/时间等字段	通过
TC-B03	CSV 导出	已登录且有数据	在列表页点击导出或访问 `/app/api/export/`	下载 UTF-8 BOM 的 CSV 文件	通过
TC-B04	脚本入库	CSV 已生成	执行 `import_flood --truncate`	约 2.4 万条写入 FloodRecord	通过

5.1.3 核心业务功能测试用例

编号	说明	条件	操作步骤	预期结果	实际结果
TC-C01	数据总览	有监测数据	打开 `/app/home/`	KPI 与图表正常	通过
TC-C02	水位分析	有水位字段	打开 `/app/water_level/`	分布/Top/箱线图有数据	通过
TC-C03	降雨分析	有降雨字段	打开 `/app/rain/`	时序与散点可见	通过
TC-C04	行政区对比	有多区数据	打开 `/app/district/`	对比柱图与散点更新	通过
TC-C05	预警分析	有预警等级	打开 `/app/warning/`	占比与积水率对比可见	通过

5.1.4 数据分析功能测试用例

编号	说明	条件	操作步骤	预期结果	实际结果
TC-D01	时序热力	有时序数据	`/app/time_series/` 请求 bundle	日均折线与热力矩阵返回	通过
TC-D02	相关矩阵	样本足够	`/app/correlation/`	Spearman/Pearson 矩阵可渲染	通过
TC-D03	水位预测	小时样本≥5	`/app/prediction/`	历史+外推+滑动平均曲线可见	通过
TC-D04	异常检测	水位样本≥4	`/app/anomaly/`	IQR 异常点标注与样本表可见	通过

5.1.5 系统集成功能测试用例

编号	说明	条件	操作步骤	预期结果	实际结果
TC-E01	根路径跳转	服务已启动	访问 `/`	重定向到 `/app/login/`	通过
TC-E02	API 前缀	已登录	请求 `/app/api/overview/` 等	返回 JSON ok 结构	通过
TC-E03	筛选选项	库有数据	请求 `/app/api/options/`	返回行政区/月份/预警等级	通过
TC-E04	前后台共库	库有数据	前台总览记录数与后台对照	数量级一致（约2.4万）	通过
TC-E05	无 Web 采集页	路由已配置	访问 `/app/data_fetch/`	无此业务页（404）	通过
TC-E06	无独立大屏	系统部署完成	访问 `/bigscreen`	无业务大屏页	通过

5.1.6 用户界面功能测试用例

编号	说明	条件	操作步骤	预期结果	实际结果
TC-F01	侧栏导航	已登录	点击各分析菜单	对应页面激活高亮	通过
TC-F02	修改信息	已登录	`/app/changeSelfInfo/` 保存	信息更新成功	通过
TC-F03	修改密码	已登录	`/app/changePassword/` 提交	新密码可登录	通过
TC-F04	筛选联动	有数据	切换月份/行政区/预警等级	各页图表随筛选刷新	通过

5.2 系统性能测试

5.2.1 响应时间性能分析

在约 2.4 万条 FloodRecord、40 个测站规模下，普通页面首屏一般可在 1～3 秒内完成；带聚合的 Bundle API 在缓存命中时响应更快。首次冷查询因聚合与 DataFrame 转换耗时相对更高，之后 120 秒缓存窗口内重复筛选可明显降耗。时序热力与相关矩阵 Bundle 缓存倍数设为 2×TTL，进一步减少重复计算。

5.2.2 并发性能测试

课题演示场景以单机少量并发为主。Session 认证与本地内存缓存在多用户同时筛选相近条件时能够复用结果；若并发显著增大，可考虑更换 Redis 等缓存后端。当前实现满足课程验收与本机演示需求。

5.2.3 数据库性能测试

针对 observe_time+district、observe_time+warn_grade 的组合索引，对月份与行政区过滤的 Count/Avg/Max 查询有帮助。列表导出使用 iterator(chunk_size=2000) 流式读库，避免一次性装入全部行。建议定期 ANALYZE 并避免无索引字段上的高基数字符串模糊查询。

5.2.4 性能优化措施

使用 cached_analysis_df 与 WATERLOG_CACHE_TTL=120 降低重复计算。
Bundle API 合并多图数据，减少 HTTP 往返。
sample_series 对过长时序等距抽样，减轻前端渲染压力。
后台增删改调用 invalidate_waterlog_cache 递增版本号，避免脏读而非全库清缓存。
导入阶段 --truncate 后批量写入，缩短初始化时间。

6 总结与展望

6.1 总结

本文完成了基于 Python 的城市内涝积涝监测数据可视化分析系统的设计与实现。系统以 Django 3.1.14 + SimpleUI 为 Web 框架，MySQL 库名 waterlog，服务端口 8070 ，入口 manage.py，前台 /app/login/（admin/123456），后台 /admin/（admin/admin123）。围绕 User 与 FloodRecord 两张核心表，按六大模块组织了用户认证、数据总览、水位与降雨分析、行政区与预警分析、时序相关预测异常、列表导出与后台；分析 API 提供 options/overview 及八个 *-bundle 接口。数据覆盖深圳市 40 个测站、2024 年 5---9 月 汛期、约 2.4 万 条小时级记录；小时降雨来自 Open-Meteo 真实数据，积水水位为基于降雨与点位敏感度的估算值 （论文与界面均已说明）。数据采集通过 scripts/fetch_flood_data.py 与 import_flood 完成，无 Web 采集页、无 Flask、无独立大屏。分析采用 pandas/NumPy 聚合，Spearman/Pearson 相关、IQR 异常检测，以及线性外推与滑动平均示意预测；utils 层 waterlog_core、waterlog_charts、waterlog_constants 分层清晰，本地缓存 TTL 为 120 秒。前端以 ECharts 5 与 Bootstrap 5 呈现。经功能测试，主要模块运行符合预期，能够支撑教学演示与课题分析。

从模块规模看，论文第 3、4 章按上述 6 个功能模块展开；侧栏路由包括 /app/home/、/app/water_level/、/app/rain/、/app/district/、/app/warning/、/app/time_series/、/app/correlation/、/app/prediction/、/app/anomaly/、/app/flood_list/ 等，形成可复现的本地化内涝可视化分析方案。

6.2 展望

后续可从以下方向继续完善：在深圳开放平台申请 appKey 后切换官方积涝水位，并与估算序列对照展示；引入更丰富的时间序列模型（如 ARIMA 或季节性分解）提升预测表达力；增加角色权限细分与操作审计；将脚本拉取接入定时任务或消息队列；在保持无独立大屏的前提下，优化移动端图表交互与地图底图集成；扩展更多测站与近实时降水接入，使分析更贴近业务巡检场景。

参考文献

$1$ Django Software Foundation. Django documentation (3.1.x) $EB/OL$ . Django documentation | Django documentation | Django, 2021.

$2$ 伊诺克森托娃. Python数据分析 $M$ . 北京: 人民邮电出版社, 2020.

$3$ 王珊, 萨师煊. 数据库系统概论 $M$ . 5版. 北京: 高等教育出版社, 2014.

$4$ Apache ECharts. ECharts 官方文档 $EB/OL$ . Apache ECharts.

$5$ McKinney W. Data Structures for Statistical Computing in Python $C$ //Proceedings of the 9th Python in Science Conference, 2010.

$6$ Open-Meteo. Historical Weather API Documentation $EB/OL$ . 🌤️ Free Open-Source Weather API | Open-Meteo.com.

$7$ 深圳市人民政府. 深圳市政府数据开放平台：市水务局积涝点水位接口 $EB/OL$ . 深圳市政府数据开放平台.

$8$ 李刚. 疯狂 Python 讲义 $M$ . 北京: 电子工业出版社, 2019.

$9$ 张浩. 基于 Web 的数据可视化系统设计与实现 $J$ . 计算机应用与软件, 2020.

$10$ Bootstrap Team. Bootstrap 5 Documentation $EB/OL$ . https://getbootstrap.com/docs/5.0/getting-started/introduction/.

$11$ 周志华. 机器学习 $M$ . 北京: 清华大学出版社, 2016.

$12$ Spearman C. The Proof and Measurement of Association between Two Things $J$ . American Journal of Psychology, 1904, 15(1): 72-101.

致谢

在毕业设计完成之际，衷心感谢指导老师在选题、需求分析、系统设计与论文撰写过程中给予的耐心指导与严格要求。感谢同学在环境搭建、功能联调与界面体验反馈方面提供的帮助。感谢开源社区提供的 Django、ECharts、pandas、Open-Meteo 等相关技术与数据接口，使本系统能够顺利落地。也感谢家人一直以来的理解与支持。由于水平与时间有限，系统中水位估算与示意性预测仍有改进空间，恳请各位老师批评指正。

基于Python的城市内涝积涝监测数据可视化分析系统