Posts

前言 此前提到微天气应用程序需要使用到行政区划数据，不过上一章所使用的数据来源于网络，或多或少都可以考虑一下是否还有其他获取的方式，所以也就有了本文的内容。 在这里，将基于全国1:100万基础地理信息数据进行行政区划数据的提取。本文用于记录使用程序实现全国1:100万基础地理信息数据合并的全过程。 当然，本文产生的最重要原因其实并不是受到微天气的启发，更多的是个人想试一试能不能用。 数据说明 全国1：100万公众版基础地理信息数据（2021）覆盖全国陆地范围和包括台湾岛、海南岛、钓鱼岛、南海诸岛在内的主要岛屿及其临近海域，共77幅1:100万图幅，该数据集整体现势性为2019年。数据采用2000国家大地坐标系，1985国家高程基准，经纬度坐标。 为满足广大社会群众对地理信息数据资源的需求，经自然资源部授权，全国地理信息资源目录服务系统提供全国1:100万全图层要素免费下载的服务。下载数据采用1：100万标准图幅分发，内容包括水系、居民地及设施、交通、管线、境界与政区、地貌与土质、植被、地名及注记9个数据集，且保存要素间空间关系和相关属性信息。 💡 提供下载的是矢量数据，不是最终地图，与符号化后的地图再可视化表达上存在一定差异。用户利用此数据编制地图，应当严格执行《地图管理条例》有关规定；编制的地图如需向社会公开的，还应当依法履行地图审核程序。 成果规格 分幅编号及范围 1：100万公众版基础地理信息数据（2021）的图幅总数为77幅，分幅数据按照GB/T 13989-2012《国家基本比例尺地形图分幅和编号》执行。空间存储单元为6°（经差）×4°（纬差）。 坐标系统 平面坐标系： 2000国家大地坐标系。 高程基准：1985国家高程基准。 地图投影：分幅数据采用地理坐标，坐标单位为度。 几何精度 更新后地物点对于附近野外控制点的平面位置和高程中误差符合下表的要求，以两倍中误差值为最大误差。 地物点误差 最小 最大 平面位置 100 500 高程 50 200 现势性 1:100万地形数据现势性与更新使用的数据源的现势性一致，数据整体现势性达到2019年。 成果数据组织 全国1：100万公众版地形数据（2021）内容包括水系、居民地及设施、交通、管线、境界与政区、地貌与土质、植被、地名及注记9个数据集。 数据分层的命名采用四个字符，第一个字符代表数据分类，第二三个字符是数据内容的缩写，第四个字符代表几何类型。 目标 实现分图层合并（处理图幅合并时接边问题） 水系（暂缓） 交通（暂缓） 境界与政区（国、省、市、县） 地名及注记 根据合并后的行政区划与地名注记，制作行政区划数据库 数据库使用PostgreSQL（PostGIS） 设计 图层解析程序 Java程序， 使用GDAL 读取GDB 逻辑 根据《国家基本比例尺地形图分幅和编号》规定可知网格范围，通过网格范围动态生成对应网格的分幅编号，并以该编号进行数据检索。如果命中则根据成果数据组织规格以及相关标准对数据进行解析，如果未命中则跳过，直至网格扫描完毕。 经度：72~138（E），43~53（11） 纬度：0~56（N），A~N（14） 即，网格范围:[43,53] x [A,N] 数据的处理流程可使用责任链模式进行，后续也方便加入其他的处理流程。即，整体的执行框架为策略模式+责任链模式。为统一策略选择模型，在此提出图层定义（LayerDefinition）的概念。 LayerDefinition由如下几个关键要素组成： 图层数据源（LayerSource） driver：驱动，参考java.sql.UnWrapper实现 instance name catalog： schema： table： commonDefinitionKey ：常规定义缓存的key fieldDefinitionKey ：字段定义缓存的key featureCarrierKey ：要素载体缓存的key origin：数据来源（分幅文件路径） scale：比例尺（如：1000000，表示1:1000000） sourceSpatialRef：源坐标系（表现形式可为标准ID、PROJ Text、WKT Text） sinkSpatialRef：目标坐标系（表现形式可为标准ID、PROJ Text、WKT Text） featureCode：要素分类码，对应成果数据组织中的要素分类（如：C、B） name：图层命名，也是图层分类码 layerCode：图层分类码 release：释放格式（比如：WMTS、Shapefile、GDB…） 描述字符为：比例尺:源坐标系:目标坐标系:要素分类码:图层名称:释放格式，在描述字符串中，坐标系仅使用标准ID表示...

前言 微天气程序中存在如下几个功能需要使用到行政区划数据： 城市列表，需要支持城市搜索 根据经纬度获区域（城市）的天气数据 地图坐标拾取并获取所处区域（城市）信息，同时获取天气数据 对于城市的天气数据，不使用和风天气的城市列表，而是自行维护，通过空间位置（经纬度）进行关联。对于城市位置的定义，本可以选择如行政中心或市中心，但我没有这样的数据，就直接用城市区划范围的中心点代替。不准确不重要，过程已经满足了，且后续是可以替换的。 其实完全可以使用官方提供的城市数据和GeoAPI覆盖这些功能，但既然我是做GIS开发的，而且手里也有可以用作研究学习的数据，为啥不用呢。 今天突然发现，其实我可以爬一下和风的数据，这样就可以拿到城市选择的经纬度数据了 @time 2023.10.10 About 行政区划解析程序，输入shape文件，写入Postgresql. 大体完整的四级行政区划数据组织 github link: fuyi-district-parse 数据情况 数据原源于网络，由于时间久远，我已经忘记了是如何获取到的 名词解释 省级行政区 中国的一级行政区，或称国家一级行政区或省级行政区，是指直属中央政府管辖的行政区划，在历史上曾有不同的称呼。如：省、自治区、直辖市、特别行政区。 地级行政区 地级行政区即“地区级别行政区”，是现行中华人民共和国行政区划中常规的第二级行政区划单位，包括地级市、地区、盟、自治州等。地级行政区隶属于省、自治区、直辖市等省级行政区之下；下辖若干个县、区、县级市、旗等县级行政区。作为特例，东莞市、中山市、嘉峪关市、儋州市等四个地级市下辖街道办事处与乡镇，不辖县、区，因此也称作“直筒子（地级）市”。地级行政区的级别为正厅级，所以非正厅级的省直辖的行政区划不算作地级行政区，例如：湖北省辖的仙桃市、天门市、潜江市；河南省辖的济源市等等。直辖市下辖的区，虽然是正厅级，但未列入地级行政区的统计。 县级行政区 县为中华人民共和国行政区划单位之一，县级行政区指行政地位与“县”相同的行政区划单位的总称，其管辖乡级行政区。为乡、镇的上一级行政区划单位。中华人民共和国成立后，随着行政督察区名称的变更，除各直辖市均隶属于专区（行政督察专区）、地区或地级行政区，现除各直辖市、海南省直管县外均为地级行政区的下一级行政区。 按省、县、乡三级行政区划制度划分，县级行政区属于第二级行政区，为直辖市的下级行政区划单位。 按省、地、县、乡四级行政区划制度划分，县级行政区属于第三级行政区，属于省、自治区所辖地级行政区的下级行政区划单位。 乡级行政区 乡，中华人民共和国现行基层行政区划单位，区划层次介于县与村之间。“乡”为县、县级市下的主要行政区划类型之一。中国行政区划史上，“乡”一直为县的行政区划单元，因此现行处同一层次的区划单位归入乡级行政区。中国自改革开放以来，由于城市的快速扩张，行政区划制度出现了大的变革。1980年代以后“乡改镇”、“乡改街道”的现象越来越普遍。 在乡级行政区划中，乡（包括镇）设有一级人民政府，属于基层政权；乡的行政区划单位为村（含民族村）。但很多乡设有社区，乡的区划单位设置与镇、街道看不出实质性差异。 目的 解析所有数据文件，实现最终入库 使用GeoTools实现 数据库表结构： 行政区划信息（district_info） id：自增Id（bigserial） name：行政区划名称 grade：行政区划等级（省级行政区：1， 地级行政区：2， 县级行政区：3，） code：行政区代码 center_point：中心点（geometry::point） bounds：行政区边界（geometry） 注： 数据入库前审查，保证行政区代码唯一 使用grade区分省、市、县、乡镇 对于省、市、县code列，统一进行前6位截取（不满6位字符所在数据，直接丢弃），对于乡镇则统一进行前9位进行截取（不满9位字符所在数据，直接丢弃） 省级行政区 存在错乱数据，可以使用行政区代码识别（adcode） 地级行政区 存在错乱数据，可以使用行政区代码识别（code），需要截取前6位 县级行政区 存在错乱数据，可以使用行政区代码识别（code），需要截取前6位 乡级行政区 成果 记录数：46652 点数据为各个行政区中心点 数据表 PostGIS CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public; 行政区划 -- -- Name: district_info_id_seq; Type: SEQUENCE; Schema: public; Owner: postgres -- CREATE SEQUENCE public....

前言 关于矢量瓦片（节选） 地图瓦片技术是在线地图服务常用的瓦片技术，瓦片就是地图瓦片的具体存储形态，提前切好的瓦片可以大大提高在线地图的访问效率。 栅格瓦片 以图片为介质的栅格瓦片使得在线地图得以迅速普及，优势在于显示效率高、方便传输。但是，随着地图的移动化和应用的逐渐深入，栅格瓦片占用带宽和存储都较大，不利于地图在移动设备的应用。 矢量瓦片 矢量瓦片的产生弥补了栅格瓦片的不足。矢量瓦片数据以矢量形式存在。矢量瓦片体积下，可高度压缩，占用的存储空间比栅格瓦片要小上千倍。数据传输体量小，地图更新的代价小 常见的矢量瓦片制作工具（节选） 目前开源的矢量切片工具还是非常多的，列出一些主流的阐述下： 基于GeoServer的矢量切片插件，适合熟悉GeoServer的用户，操作还比较简单，缺点是切片的行列号与一般的XYZ编号不同不容易单独部署。 基于tippecanoe的矢量切片工具方案，该工具提供了很多高级功能在数据定制化上有很强的优势，但只能部署在Linux，并不是跨平台，只能读取geojson文件，不能直连数据库，不是很好，如果有幸您是c++开发大神，可以改下库的编译绑定平台，使其支持windows，再更改下数据源底层，使其能支持空间数据库，那么该工具会有更多的应用空间。 基于PostGIS的矢量切片方案，该方案在熟悉PostGIS的用户中应该很受欢迎，优势是支持动态矢量切片，有PG社区的系统级加成。 总的来说，工具虽然很多，但是没有一款可以说覆盖一切场景的，具体应用还是看场景的，比如前两个方案都是做底图数据时比较有用，都是静态矢量切片方案，geoserver能直连数据库，tippecanoe有强数据定制性要求，那么如果用户侧重点是简单点的话geoserver够了，用户侧重点是希望对数据做很多高级过滤什么的操作用tippecanoe，但步骤麻烦点。这些矢量切片工具仅仅在处理很久不变的数据，就是切一次用很久的数据，如果数据频繁变化，这种静态数据切片工具就很不好用了。 与其他方案相比，PostGIS方案的好处主要有两大点： 资源开销低：空间数据一般存空间数据库中，传统工具会先从数据库中捞数据，这个数据通常很大，网络开销和服务器端内存都要很大，查询慢计算慢是肯定的。而PostGIS是在数据库中把数据处理完，只把结果传给后台转前台，可以很方便的使用数据库的索引，并行计算等，优化查询和处理速度。 动态矢量切片，数据时效性高：每当根据xyz请求时，数据库会动态查询范围内数据，裁剪简化并输出pbf格式的二进制数据出去，在数据变化频繁的场景下，可以保证用户看到的是最新的数据。 💡 GeoServer、Tippecanoe 皆为静态矢量切片方案，需提前准备切片数据，并进行持久化（GeoServer也可以在使用时进行切片，同时进行持久化）。PostGIS支持动态矢量切片方案，即实时计算生成切片，且不进行切片的持久化。 为什么要自己写一个服务 于我个人而言，我目前仅接触和使用到了GeoServer，且对其中的实现细节并不太清楚，所以想通过参考模仿的方式实现一个示例服务。其次，还想测试在没有如GeoWebcache此类的瓦片缓存的情况下，服务的性能如何。综上所述，其实也就是为了如下这几方面的目的： 学习，了解其中的实现细节 更好的适配 比如说，WMTS服务很明确存在缓存，WMS性能又不够好。如果使用WMTS服务确实可以提升服务的性能，但是对于源数据存在编辑的场景下，缓存问题还是会让人头疼。 那么是否存在动态的矢量瓦片服务？既能解决缓存的问题，同时还没有太大的性能问题。 你或许会提到基于PostGIS的动态矢量瓦片服务，但是有些历史的原因，短时间内没有变法变更数据库。当然也可以基于类如CDC这样的功能进行缓存的更新，但其实还是会存在缓存的问题，只是说可以通过一些手段降低缓存问题出现的概率，并无法从根本上解决问题 所以，基于此，既然PostGIS可以实现动态矢量瓦片服务，我们自然也可以。公瑾大佬曾发文说过，当下地图服务去服务化、数据不切片基本上已经是必然的趋势，那么我为什么还要去做一个服务化的东西。大概就是下面这几个原因了： 数据库技术，在某些特定的因素下，短时间内无法切换到PostGIS 数据量级 性能容忍度 小厂，我不思进取 🙄 后续知识储备 矢量瓦片标准 参见：矢量瓦片标准 在这里贴几个关键点（对于目前使用上来说）： 文件格式 矢量瓦片文件采用Google Protocol Buffers进行编码。Google Protocol Buffers是一种兼容多语言、多平台、易扩展的数据序列化格式。 投影和范围 矢量瓦片表示的是投影在正方形区块上的数据。矢量瓦片不应该包含范围和投影信息。解码方被假定知道矢量瓦片的范围和投影信息。 Web Mercator是默认的投影方式，Google tile scheme是默认的瓦片编号方式。两者一起完成了与任意范围、任意精度的地理区域的一一对应，例如https://example.com/17/65535/43602.mvt。 矢量瓦片可以用来表示任意投影方式、任意瓦片编号方案的数据。 内部结构 图层 每块矢量瓦片应该至少包含一个图层。每个图层应该至少包含一个要素。 几何图形编码 矢量瓦片中的几何数据被定义为屏幕坐标系。瓦片的左上角（显示默认如此）是坐标系的原点。X轴向右为正，Y轴向下为正。几何图形中的坐标必须为整数。 矢量瓦片服务构建 在这里，我选择抄GeoServer的作业。众所周知，PostGIS是开源的，那为什么没有选择抄PostGIS的作业呢？ 当下水平不够 想快速验证想法 想基于GeoServer做二次开发，或者说是基于现存的地图服务相关的实现，集各家之大成，合并成一个组在功能上可自由搭配的、较高性能服务端组件 接着说当前的事情。要实现一个动态矢量瓦片服务，我们需要先分析一下实现内容，在此先做出如下拆解： 动态矢量瓦片服务可以理解为没有瓦片缓存的，实时生成的矢量瓦片服务，所以核心还是矢量瓦片服务(@time 20210503: 动态矢量瓦片技术是相对矢量瓦片技术提出的，而矢量瓦片技术的大规模应用还是以预切为主，所以动态矢量瓦片要解决的是不再预切动态生成，同时避免一下子生成大规模瓦片文件的问题) 矢量瓦片服务也就是根据调用端传递的参数，从数据源获取对应的数据，并将其转换为矢量瓦片格式，最终返回给调用端 这里选择瓦片坐标作为检索参数，可以便于服务降级（缓存）和性能优化（瓦片坐标值相对来说更加准确和可固定，且便于降维） 需要实现瓦片坐标系到数据源坐标系下数据范围的相互转换 需要实现数据源的范围查询 需要实现矢量数据到矢量瓦片的编解码 那么大体的实现路径可归结于如下所示： 其中的核心要点总结如下：...

前言 本文用于记录GeoServer开发环境的搭建过程 通过GeoServer发布计划可以看到，在2.23.x版本开始，会移除对jdk1.8的支持。那么当前我们会选择2.22.x版本进行研究 环境 JAVA：1.8或11 Maven Git Action 获取源码 git clone git://github.com/geoserver/geoserver.git geoserver # or git clone https://github.com/geoserver/geoserver.git geoserver 代码库结构 Each branch has the following structure: build - release and continuous integration scripts doc - sources for the user and developer guides src - java sources for GeoServer itself data - a variety of GeoServer data directories / configurations 切换到2.22.x分支 # 查看分支 git branch -av # 切换分支 git checkout -b 2....

为什么需要深入研究GeoServer GeoServer是一个开源的、流行的、Java实现的可发布和共享地理信息数据的软件服务器，是WMS、WCS、WFS的标准实现，含WMTS GeoServer功能强大，但是我可能只会用到其中的一两个部分，比如坐标转换与WMTS服务。可以通过研究将其进行提取和重组，形成符合我要求的，更加精简方便的软件服务器 GIS后端开发绕不过去的知识点 如何进行研究 开发环境搭建 通过WMTS请求链接到源码 通过源码进行研究学习 … 未完待续…

前言 此为深入理解计算机系统（csapp）第一章的笔记，也算是一个开始了。 Hello程序 #include <studio.h> int main() { printf("hello world\n"); return 0; } 基本思想 系统中所有的信息——包括磁盘文件、内存中的程序、内存中存放的用户数据以及网络上传输的数据，都是由一串比特（bit）表示的。区分不同数据对象的唯一方法是我们读到这些数据对象时的上下文。比如，在不同的上下文中，一个同样的字节序列可能表示一个整数、浮点数、字符串或者机器指令。 要点 源程序实际上就是一个由0和1组成的位（或称为比特：bit）序列，8个位为一组，称为字节（byte）。 大部分的现代计算机系统都使用ASCII标准来表示文本字符，这种方式实际上就是用一个唯一的单字节大小的整数值来表示每个字符 hello.c程序是以字节序列的方式存储在文件中。每个字节都有一个整数值，对应于某些字符（注意：每个文本行都是以一个看不见的换行符“/n”来结束的） 只由ASCII字符构成的文件称为文本文件，所有其他文件都称为二进制文件 编译系统（compilation system）：编译的四个阶段 gcc -o hello hello.c hello.c（文本） —> 预处理器[cpp] —> hello.i（文本） —> 编译器[ccl] —> hello.s（文本） —> 汇编器[as] —> hello.o（二进制） —> 链接器[ld] —> hello（二进制） 预处理：预处理器处理#开头的命令，修改原始的C程序 编译：编译器将hello.i翻译为hello.s，即将源文件翻译为汇编语言。汇编语言是非常有用的，因为它为不同高级语言的不同编译器提供了通用的输出语言。例如，C编译器和Fortran编译器产生的输出文件用的都是一样的汇编语言 汇编：汇编器将hello.s翻译为机器语言指令，把这些指令打包成一种叫做可重定位目标程序（relocation object program）的格式，并将结果保存在目标文件hello.o中。hello.o是一个二进制文件（即将汇编内容翻译为机器语言指令，并将这些指令打包成一种叫做可重定位目标程序的格式） 链接：链接器用于处理合并。比如在hello程序中调用了printf函数，它是每个C编译器都提供的标准C库中的一个函数。printf函数存在于一个名为printf.o的单独的预编译好了的目标文件中，而这个文件必须以某种方式合并到hello.o程序中。链接器就负责处理这种合并。最终得到hello文件，它是一个可执行目标文件（或简称为可执行文件），可以被加载到内存中，由系统执行 shell是一个命令行解释器，它输出一个提示符，等待输入一个命令行，然后执行这个命令。如果该命令行的单词不是一个内置的命令，那么shell就会u假设这是一个可执行文件的名字，它将加载并运行这个文件。 系统的硬件组成 CPU：中央处理单元； ALU：算术/逻辑单元； PC：程序计数器； USB：通用串行总线 总线 贯穿整个系统的是一组电子管道，称做总线，它携带信息字节并负责在各个部件间传递。硬件之间进行信息交流需要有一个统一的标准，也就是二进制信息传递规则，为了高效考虑，通常总线被设计成传送定长的字节块，也就是字（word）。字中的字节数（即字长）是一个基本的系统参数，在各个系统中的情况都不尽相同。现在的大多数机器字长要么是4个字节（32位），要么是8个字节（64位）。 I/O设备 输入 / 输出（I/O）设备是系统与外部世界的联系通道。每个 I/O 设备都通过一个控制器或适配器与 I/O 总线相连。控制器与适配器之间的区别主要在于它们的封装方式。控制器是 I/O 设备本身或者系统的主印制电路板（通常称为主板）上的芯片组。而适配器则是一块插在主板插槽上的卡。无论如何，它们的功能都是在 I/O 总线和 I/O 设备之间传递信息。...

前言 I have a dream too! 开源技术赋予我们站在巨人的肩膀上做到更高更强的可能，我想通过开源技术来构建一个地理信息的世界（such as: one personal cloud gis），愿给地理信息数据带来更多的使用价值。当前主要关注空间数据库、数据处理与应用以及数据渲染，由内到外，逐步构建。既然都说人类活动所接触、产生的信息80%以上都与地理空间位置有关，那么这些空间数据就应该很容易的被使用，而不是仅被围困在专业领域内，不是吗？ Fuyi Atlas（拂衣志），取自 《侠客行》、Cloud Atlas以及Discovery Atlas。愿自己也能行此间小事，而非蹉跎岁月。 Fuyi Atlas Website将会使用Hugo + Github Pages进行构建，本文用于记录Fuyi Atlas的初始构建过程。 HUGO是什么 Hugo is one of the most popular open-source static site generators. With its amazing speed and flexibility, Hugo makes building websites fun again. Hugo是一个使用GO语言编写的，开源的，静态站点生成器。 也就是说，你可以使用Hugo来快速构建你自己的静态站点。比如个人博客、知识库、产品介绍、文档等等。 我此前使用vuepress来构建我的个人站点，接触Hugo之后，更愿意使用Hugo。那么我将使用Hugo代替vuepress来构建我的个人站点。理由有那么几个： Hugo是一个纯粹的生成器 Hugo没有过多的生态依赖 Hugo更轻 据说更快，其LiveReload可以实现近实时的内容刷新 挺多可选的开源主题 使用更加简单 我也不是很喜欢node_modules Fuyi Atlas Site Build Hugo Install Hugo is available in two editions: standard and extended....

前言 拖延症真的存在！！！ 今天是2023年2月13日晚，我在此时写下本文的第二行内容。其实从年前就开始计划写一篇关于2022年的年终总结，无奈受到拖延病毒的威胁，一直拖到现在才暂时摆脱控制。 如题，本文将对2022年进行简要总结，同时对2023年做一个初步的展望（仅作记录）。 2022年大事记 第一个在外过的春节 受新冠疫情影响，2022年的春节是在杭州过的。还记得当时附近好几个地方都被划为了高风险，对整个区进行了管控。如果选择回家的话，得到将是14天的隔离，还不确定能否回来上班。因此便没有回去了。 好在所在的区域情况并没有那么的严重，还是可以去买菜的。领了消费券，再加上公司发的年货，也没有想象中的那么糟糕。 拂衣天气 集地理信息与天气预报为一体的天气预报类小程序，界面精美，使用便捷。【致敬：和风天气】 2022年，是我工作的第四个年头。受多方面的信息影响，我也想看看验证自己是否有进入全栈开发的能力。该项目从2022年1月12号正式启动，于2022年3月19日发布一阶段最终版本（1.1.9），总体耗时2个月零7天。从内容完整度以及界面友好程度来说，我给自己70分。 其实最开始是想基于webview来实现更多的地图方面的特性的，但webview对个人认证不开放。 在完成之后，本来计划是将拂衣天气完整的开发过程通过文章的方式记录下来，并将该项目开源出去，甚至还想将该项目提交给和风天气。但最后的结果就是：文章就完整了四篇，也就是一个开头，没啥实际内容。 那么原因是什么呢？经过深深的反思过后，主要的原因有那么几点： 拂衣天气的实现太乱了，本想借着文章梳理重构之后再开源 同阶段想要做的事情太多了 拖延症后期患者 对，都是借口，就是懒 WebGIS项目开发 我是2021年5月份进入的现在的这家公司，任职岗位是GIS开发工程师，主要负责服务端GIS内容的实现。从入职后到今年年初，一直在做一个小程序，算是公司的一个实验性产品，和已有产品的实际关联不大。 从3月份开始，将基于既有的产品实现，结合新项目的特性以及通用性要求，实现产品的升级。这对我来说，也算是一个重要的时间节点。因为自此我算是真正进入了WebGIS开发领域，以服务端开发为切入点。 项目部署工作 大概是22年的7-8月份，上面提到的WebGIS项目实现将作为基线产品的一部分，为后续的项目应用提供支持。而后面我将会同时负责WebGIS服务端的项目部署工作。 截至到2023年初，我已经经历了很多个项目。思来想去，我觉得这对我来说也是一个有意义的时间节点。从项目应用开发到基线产品，再到基线产品项目应用部署。一方面也算是证明了当初选择的路线，同时也更加坚定。另一方面，在疫情时代，公司能有项目那应该是好事，虽然我大抵是不喜欢做部署工作。 公司年会 对，这也是另一个重要的时间节点。2022年12月4号晚，发布了《杭州市关于优化调整疫情防控相关措施的通告》。2023年1月13日下午，公司举办了年会。这么结合起来看，是不是看起来明年会更好！ 今年其实发生了挺多的事情，自己在心态上也发生了一定的变化（主要指工作方面）。从3月的充满希望，到年底的身心俱疲。正好借年会的氛围想了想，我觉得可以换一种心态开启2023年。当初选择来这里，也就是因为自己的路线规划与公司的技术发展方向是基本一致的，到今天公司并没有发生较大的变化。那么既然是自己想要做的，那么就更应该去做好，主动去做，你是在借助公司的资源实现自我的目标，你甚至可以尝试去干预以符合你的目标。未来的岳父大人也给我说：有的时候，不要计较那么多，即使辛苦一点也没关系，但是你要清楚你在做什么。 做了再多，不如做好一个，这就是你最好的名片。——自我PUA 2023展望 技术 围绕地理信息，更加深入底层实现。以空间数据库为核心，以数据处理与使用为重点，以数据渲染为次重点，由内到外，逐步构建技术体系。 写作 2022年的成果惨淡，整整一年只有仅仅四篇文章，还都是拂衣天气的内容。 希望从2023年开始，可以实现一周双更，单更是底线。同时还要能够提高文字表达的能力。 生活 可以一夜暴富吗？ 后记 第一次更新：2023年2月13日晚，完成前言编写 第二次更新：2023年2月18日下午，完稿

前言 本文用于说明本次开发所使用的环境，以及环境的搭建过程。 操作系统 Windows 10 专业版 其实我当时使用的操作系统的Arch Linux，开发完成后才又重装回Windows。 现在又用回了Fedora 38 Workstation @time 2023.10.07 服务端 服务端使用Java语言进行开发，项目构建使用Maven(Gradle)，开发工具使用Idea，服务发布使用Docker，下面是具体的版本： JDK: OpenJDK 11 Gradle: 7.3.2 Maven: Idea: IntelliJ IDEA 2022.1.3 (Community Edition) Docker: Linx Docker Desktop Version 4.23.0 (120376) [Engine: 24.0.6] 小程序 首先需要自行完成小程序的注册，具体可以参考官方文档。 其次，下载并安装小程序开发工具，参见下载页面。 最后，调试基础库选择：2.24.6 参考 开发者工具中无法显示echart或显示异常 在MobaXterm进入ssh终端后，键入上下左右出现乱码 win10上修改docker的镜像文件存储位置 WSL2 迁移 Docker 镜像存储位置 说明 如有冒犯，我在这里先向您道歉，还请联系我进行处理 email: thread_zhou@126.com

前言 这是一个前后端分离的项目，后端使用Java进行开发，而前端通过微信小程序实现。 功能结构 可从上图得知，部分功能已去除： 消息 消息推送 紧急情况推送 用户 个人中心 模型设计 用户信息（UserInfo） id Long 主键 oid String OpenID uid String UnionID name String 昵称 phone_num String 手机号 avatar String 头像地址 authState String 登录状态 Silence 静默登录（目前程序的访问是需要存在登录态的） Authorized 已授权 createTime Timestamp 记录创建时间 updateTime Timestamp 记录更新时间 行政区划信息（DistrictInfo） 使用全国行政区划信息填充，含空间数据，数据粒度到区县。目前仅支持国内数据。 id Long 主键 name String 行政区名称 grade Integer 行政区级别 1：省级行政区 2：地级行政区 3：县级行政区 4：乡镇级行政区 code String 行政区代码 centerPoint Point 行政区中心点（空间数据） bounds Geometry 行政区边界（空间数据） 关注城市（FollowCity） id Long 主键 userId Long 用户ID districtId Long 行政区划ID districtName String 行政区划名称 districtCode String 行政区划编码 orderNum Integer 序号，自然数，从1开始 createTime Timestamp 记录创建时间 天气信息 由于天气数据均来自第三方，目前数据格式于和风天气对齐。...