离线环境下Docker环境部署解决方案

2019-08-20

在Docker的实际应用过程中，避免不了需要将Docker部署到离线环境下，为了解决这个问题，我做了离线部署实验，现在将部署流程介绍一下。

实验准备

准备两台虚拟机，一台可以联网，一台无法联网，可以联网的虚拟机是为了Docker部署做准备。

Docker环境部署

使用联网机器下载Docker部署包

1.在可以连网的机器上，安装yum扩展：

1	yum install -y yum-utils

2.添加docker-ce的yum来源

1	yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

3.创建文件夹保存Docker部署包

1	mkdir /home/dockerinstall

4.将Docker及其依赖包下载至部署包文件夹中

1	yum install --downloadonly --downloaddir=/home/dockerinstall docker-ce

这里需要找一台干净的虚拟机，否则有些部署过的包会下载不下来，导致在离线机上部署会导致安装失败。
提取Docker部署包的过程，可以只做一次，后面反复部署的时候可以使用这个成果进行离线部署。

下载部署包

5.将离线部署包拷贝到U盘中

离线机上部署Docker

1.U盘挂载

在网上找了好多方法都无法正确识别U盘，我用的方法是肉眼看-_-!!!，看插上U盘之后Dev目录下多了什么文件，就把这个文件挂载起来看一下是不是。
U盘挂载

2.离线安装Docker

进入离线部署包目录下，使用yum localinstall *安装所有部署包。
离线安装

3.启动Docker服务

1
2
3

usermod -aG docker $(whoami)
systemctl enable docker.service
systemctl start docker.service

启动服务

Docker镜像迁移(以PostGIS镜像为例)

这里使用的是Docker save和load的方式，通过镜像本地文件进行迁移。

Docker镜像导出

1	docker save mdillon/postgis > /home/postgis.tar

镜像导出

Docker镜像导入

1	docker load < /mnt/usb/postgis.tar

镜像导入

测试验证

1.启动PostGIS容器

1	docker run --name postgresql --restart=always -d -p 5432:5432 -v /home/pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=1234 mdillon/postgis:10-alpine

启动容器

2.打开5432端口

1 2	firewall-cmd --permanent --add-port=5432/tcp firewall-cmd --reload

3.连接测试

展开全文 >>

使用Docker版本Jenkins持续集成

2019-07-30

最近使用Docker进行服务部署大大增加了部署的方便性，但是代码更新、代码混淆、Docker镜像构建、上传镜像至仓库、定时编译等一系列操作还是很磨人的。鉴于程序员的懒惰特性，所以引入了Jenkins做持续集成。

部署Jenkins

1.首先下载Jenkins镜像：

1	docker pull jenkins/jenkins

2.启动Jenkins

1	docker run --name devops-jenkins --user=root -p 28080:8080 -p 50000:50000 -v /opt/data/jenkins_home:/var/jenkins_home -d jenkins/jenkins

由于8080端口比较容易被占用，所以这里使用28080做为Jenkins的端口。

配置Jenkins

启动完成之后，稍等一会儿就可以通过http://localhost:28080访问Jenkins了。

1.配置Jenkins之前，需要解锁Jenkins：

2.通过页面提示的文件位置，或者查看docker日志，找到密钥，填入即可。
解锁Jenkins

3.接下来安装插件，可以使用推荐安装，也可以自定义安装：

4.配置管理员用户名、密码：

5.配置完成：

通过Jenkins构建服务镜像

由于Jenkins使用的是Docker部署，所以Docker容器内部构建服务镜像，我使用Publish Over SSH插件进行构建，这个是目前的方案，如果后面有更好的方案，再更新。

1.在插件管理器中搜索Publish Over SSH，并进行安装：
安装插件

2.配置SSH
在[系统管理]-[系统设置]中找到Publish Over SSH区域，在上面增加本机访问用户名、密码(或SSH密钥)：

配置之后可以验证是否能够连通：

3.创建Jenkins任务
创建任务
我创建的是构建一个自由风格的软件项目，在构建中增加一个Send files or execute commands over SSH步骤，即通过SSH执行一个命令。
配置SSH

这里的命令就是在本机使用的shell命令，用&&连接。
大致分为以下几个过程：
1）进入代码目录
2）使用git更新代码
3）代码混淆
4）通过Dockerfile构建服务镜像
5）上传服务镜像至仓库

如果命令执行时间过长，需要修改超时时间：
配置SSH

如果需要定时构建，在构建触发器中设置定时构建：

这里：
1）日程表中的内容，可以到网上搜一下具体的含义；
2）jenkins的Docker时间不是本地时间，修改的方法后面再研究(可能需要在启动容器的时候，传入环境变量)

构建服务镜像

通过手动启动，或者定时启动构建任务，即可进行服务镜像构建：
构建服务镜像

展开全文 >>

CentOS挂载Windows共享文件夹

2019-06-28

CentOS可以使用mount命令挂载Windows共享文件夹，下面是示例：

创建本机挂载文件夹

1	mkdir /mnt/windowssharefolder

安装cifs

1	yum install cifs-utils -y

挂载Windows共享文件夹

1	mount -t cifs -o username="dlwy",password="dlwy" //192.168.1.101/测试版本 /mnt/windowssharefolder

共享文件夹

取消挂载

1	umount /mnt/windowssharefolder

One More Thing

如果有的共享文件夹挂载时提示Host is down，可以参考这个解决方案，添加-o vers=2.0之类的。

展开全文 >>

关于面积计算，我想说点什么

2019-06-12

近几年总会有用户反馈说我们软件计算出来的面积和ArcGIS(ArcMap)不一样，问原因是什么。对于这个问题已经解释的嘴都快磨破了，所以想在这里详细说一下原因，如果哪里说的不正确，请指正。

我们所说的面积计算

我们说的面积计算，也是常用的，基本上是在高斯投影下的计算出来的面积。高斯投影的主要特点：
1）有3度分带、6度分带之说，具体的可以看一下下面的图片：

2）高斯投影是有变形的，越接近中央经线变形越小，越远离中央经线，变形越大

ArcGIS计算出来的面积一定就是准确的吗

为了验证这个问题，我创建了一个西安80经纬度的数据，并在114度右侧画了一个长度是0.1度的正方形：
创建验证数据

位置示意如下(略夸张)：
创建验证数据

可见这个正方形应该在3度分带38带内，而且很靠近中央经线。虽然在6度分带20带内，但是在20带的边缘。

我将这个正方形分别投影到3度分带38带、3度分带37带、6度分带20带：
数据投影

通过属性表的计算几何功能，计算每个图形的面积：
计算面积

PS:计算几何无法计算经纬度数据面积：
计算面积

通过计算几何可以得到下面的结果(area字段值)：
3度分带38带：
计算面积结果
3度分带37带：

6度分带20带：

由此看出面积大小关系是：
3度分带38带(106904700.551742) < 6度分带20带(107118282.196343) < 3度分带37带(107133029.229033)

这个结果的原因是什么，可以看下面的示意图(略夸张)：
3度分带38带：
位置示意图
6度分带20带：

3度分带37带：

3度分带38带是图形最接近中央经线(114度)的，也就是变形最小的。6度分带20带下的图形离中央经线(117度)小于3度，变形已经比较大了。3度分带37带下的图形离中央经线(111度)大于3度，变形比较大而且比6度分带20带的图形变形大。

所以说，ArcGIS的面积计算结果，是和数据的空间参考有关系的。面积计算比较准确的应该是在3度分带下，而且在其所在的分带内计算，使用6度分带、跨带计算都会变形比较大，进而导致面积计算不准确，如果拿这样的结果和MAPZONE面积计算结果进行对比，我们是拒绝的。

MAPZONE的面积计算逻辑

根据上面的分析，MAPZONE的面积计算逻辑就很清晰了，就是将图形投影3度分带其所在的带号内进行面积计算，以保证相对准确。而且如果有跨越两个带的图形，MAPZONE会使用两个分带的边界线对图形进行分割，分割出来的部分在各自的分带内进行面积计算，最后再累加成整个的图形面积。
MAPZONE计算面积结果

面积计算还能再精确些吗

所谓的精确，就是指图形变形小，比较接近实际的图形面积。据我所知，有下面两种办法：
1)将高斯投影的中央经线、中央纬线移到图形的中心点，以保证变形最小。
之前有一个北京地方坐标系，就是将中央经线、中央纬线移到北京正中心，以保证测量的准确性，其proj4定义如下：+proj=tmerc +lat_0=39.865766 +lon_0=116.35025181 +k=1 +x_0=500000 +y_0=300000 +ellps=krass +units=m +no_defs。其中+lon_0、+lat_0为重新定义的中央经线和中央纬线。
2）使用球面面积计算方法
这种计算方法的正确性还没有验证过，目前已知PostGIS提供的ST_Area函数可以计算球面面积。

One More Thing

如果仔细看高斯投影的分带示意图，可以看到有部分3度分带和6度分带的中央经线是重合的：

例如3度分带的39带和6度分带的20带，在ArcGIS中查看不加带号坐标系的参数定义：
同一坐标系

可以看出这两个坐标系的定义参数，除了名称(SRID)之外，其它参数是完全一致的，所以中央经线重合的不加带号的3度、6度分带，完全可以看做是同一种坐标系，没有必要进行严格区分。

后记

因为这个面积的问题，我们的移动端产品计算面积加上了如下设置：
移动GIS
可能有的人就是觉得ArcGIS计算才是对的吧。。
黑人问号

展开全文 >>

试用DBLink进行PostgreSQL跨库查询

2019-06-06

最近接到个需求，如果两种数据分别存储于不同服务器的不同PostgreSQL数据库上，能否进行跨库叠加分析。上网搜了一些资料说使用DBLink扩展可以达到跨库查询和更新的目的，所以就验证一下。

手头上两台服务器，两个数据分别在123、140服务器中，验证方式是先在123中使用DBLink查询140服务器中的数据，如果可行，再测试叠加分析。

安装DBLink扩展

在123服务器上的PostgreSQL数据库中，安装DBLink扩展：

1	create extension dblink

使用DBLink进行跨库查询

1	select * from dblink('dbname=lydb host=192.168.1.140 port=5432 user=postgres password=1234','select pk_uid,geom from ldgx_36_jiangxi.ldgx2016_p') t (pk_uid integer, geom geometry)

跨库查询

可以看到，跨库查询可以正常进行，那跨库叠加分析是否可行呢？

使用DBLink进行跨库叠加分析

select dst.pk_uid, st_intersection(src.geom, dst.geom) geom from zrbhq src inner join (select * from dblink('dbname=lydb host=192.168.1.140 port=5432 user=postgres password=1234','select pk_uid,geom from ldgx_36_jiangxi.ldgx2016_p') as t(pk_uid integer, geom GEOMETRY)) dst on st_intersects(src.geom, dst.geom)

跨库叠加分析

证明跨库叠加分析是可以实现的，但是效率可能不高，遇到大数据量的叠加分析会比较耗时，建议避免这种情况出现。

展开全文 >>

使用Docker部署PostgreSQL数据库、PostGIS插件

2019-05-30

回顾自己写的文章，讲如何部署PostgreSQL和PostGIS有好几篇，包括如何在不同的操作系统下部署PostgreSQL数据库，如何配置PostgreSQL数据库，如何迁移PostgreSQL数据库存储目录位置，如何部署PostGIS插件，如何更新PostGIS插件，如何编译带ST_AsMVT函数的PostGIS插件等，最近在使用Docker，所以找了一下PostgreSQL和PostGIS的Docker镜像，发现上面说的那些只需要一个命令就可解决。。

选择Docker镜像

在Docker Hub和网上搜索了一下，mdillon/postgis是大家建议使用的，针对我们现在使用的PostgreSQL和PostGIS的版本，我选择了10-alpine镜像，总大小只有48M。

启动容器

镜像pull到本地之后(不pull在启动的时候发现本地没有也会从Docker Hub上先下载再启动)，启动镜像：

1	docker run --name postgresql -d -p 5432:5432 -v /home/pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=1234 mdillon/postgis:10-alpine

其中：
–name为设置容器名称
-d为设置容器在后台运行
-p为设置端口映射
-v为设置数据库存储目录映射，可以将数据库存储目录保存在主机目录，防止容器被删除之后数据库中的数据丢失
-e为设置数据库参数，这里设置的是数据库管理员密码

Docker部署如何解决之前的问题

1.部署和配置PostgreSQL、PostGIS：镜像中内置的PostgreSQL数据库配置文件已修改，支持局域网访问。内置了PostGIS插件。
2.更改PostgreSQL数据库存储目录位置，只需要通过-v指定目录映射即可。
3.支持ST_AsMVT函数，镜像中的PostGIS已经是基于protobuf-c编译的了，可以支持ST_AsMVT函数。
4.升级PostgreSQL、PostGIS版本，只需要pull最新版本的镜像，删除旧版本容器，启动新容器即可。

One More Thing

除了之前的问题之外：
1.使用Docker部署还可以在性能比较好的机器上部署多套数据库，通过-p端口号映射进行区分，部署的PostgreSQL数据库版本也可以不同，为以后的数据库负载均衡、读写分离、主从备份等创造条件。
2.通过Docker-Compose或者k8s进行容器编排，方便数据库、服务、前端等快速部署，减少运维人员使用难度。

展开全文 >>

试用TileStrata-underzoom插件

2019-05-29

TileStrata真是个神仙宝藏框架，今天试用的是tilestrata-underzoom插件，通过介绍能看出这个插件允许使用低级别的瓦片拼成高级别的瓦片，目前我知道的一个用途是能解决绘制高级别瓦片速度慢的问题。

1.编写代码

首先，编写瓦片服务代码：

const tilestrata = require('@conorpai/tilestrata');
const mapnik = require('@conorpai/tilestrata-mapnik');
const dependency = require('tilestrata-dependency');
const underzoom = require('tilestrata-underzoom');
const disk = require('tilestrata-disk');
var strata = tilestrata({
    balancer: {
      host: '0.0.0.0:22221'
    }
  });
//原始地图服务
strata.layer('oriimage')
    .route('tile.png')
        //.use(disk.cache({dir: 'oricache'}))
        .use(mapnik({
            pathname: 'mapnik.xml',
            OriX: -180,
            OriY: 90,
            FirstDPI: 1.40625
        }));
//underzoom地图服务
strata.layer('underzoom').route('tile.png')
    //.use(disk.cache({dir: 'underzoomcache'}))
	.use(underzoom({
		source: dependency('oriimage', 'tile.png'),
		size: 256,
		zooms: 6
    }));
var port = process.env['port'];
strata.listen(port);

2.验证拼接结果

验证两个瓦片服务绘制出来的瓦片是否相同：

普通瓦片服务：
瓦片对比

underzoom瓦片服务：
瓦片对比

由于Mapnik的线宽符号单位是像素，所以在比较高级别会因为边线太宽而糊在一起，看的不是很清楚。相比之下，使用underzoom由于是使用低级瓦片拼接而成，图形边界比较明显。

3.验证瓦片绘制效率

接下来使用tilemantle工具进行瓦片请求，获取瓦片加载时间：

普通瓦片服务：
请求时间

underzoom瓦片服务：
请求时间

可以看出，使用underzoom拼接绘制效率比普通瓦片效率高，而且如果增加瓦片服务集群，会明显提升并行绘制效率，进而提升underzoom拼接瓦片效率，在以后的实施过程中，如果遇到了高级别瓦片绘制效率瓶颈，可以考虑使用这个方案。

展开全文 >>

试用VS Code Remote

2019-05-15

几天前，微软发布了VS Code Remote，用来做远程开发，可以支持在物理机、容器以及Windows Subsystem for Linux(WSL)上实现无缝远程开发，可以做到：

在部署相同的操作系统上进行开发，或者使用更大或更专业的硬件
把开发环境作为沙箱，以免影响本地计算机配置
让新手轻松上手，让每个人都保持一致的开发环境
使用原本在本地环境不可用的工具或运行时，或者管理它们的多个版本
在WSL里开发Linux应用
从多台不同的计算机访问现有的开发环境
调试在其它位置(比如客户网站或云端)运行的应用程序

本次试用的是通过SSH来连接远程物理机，实现远程开发。

由于我们近期使用的Mapnik没有windows版本，所以之前的开发工作都是在Ubuntu上或者MacOS上进行的，有些不方便，VS Code Remote推出之后，就可以在windows上连接Ubuntu或者MacOS来进行开发和调试工作。

安装VS Code Insiders版本

目前VS Code Remote只能在预览版中使用，到这里下载、安装预览版，预览版的图标是不可描述的绿。。

安装Remote Development插件

到扩展商店中搜索remote，安装Remote Development插件，同时会安装Remote - SSH、Remote - Containers和Remote - WSL，用于三种不用的远程登陆方式。
安装扩展

安装、配置SSH

在远程端需要安装ssh-server，本机安装ssh-client。
这次本机是Windows 7操作系统，使用提OpenSSH做为ssh-clinet。到这里下载最新版本，在本机解压后，将其路径添加到系统环境变量的Path中。

然后使用ssh-keygen生成密钥，然后使用ssh-copy-id将密钥拷贝到远程机器上。由于这步和git配置相同，而且OpenSSH中没有ssh-copy-id命令，所以我用的是git bash做的。
配置ssh

在VS Code中配置远程连接

点击侧边栏中的远程连接图标，并进行配置：
配置远程连接

连接远程机器

使用右键进行连接，首次连接会在远程机器上部署远程开发相应环境，连接完成后可以看到左下角显示连接的远程机器名称。
连接远程机器

打开远程开发代码

连接远程机器成功之后，点击打开文件夹，就会显示出远程机器上的目录结构，选择代码目录，即可打开远程机器上的代码。
打开远程代码

调试

调试远程代码

展开全文 >>

试用TileStrata-blend插件

2019-04-09

最近经常遇到这样的情况，服务端发布的瓦片服务过多，导致前端加载太多的layer，增加前端网络请求负担，所以我们想某些相似的瓦片服务是否可以组合在一起，对于前端来说就是一个layer，瓦片合并的工作交给服务端进行。今天提到的TileStrata-blend插件就是用来做瓦片服务合并工作的。

首先发布三个瓦片服务，分别是林地小班、叠加分析结果和林地小班标注，配图和效果如下：
林地小班：

<Map  srs="+proj=longlat +ellps=GRS80 +no_defs">
  <Style name="My Style">
    <Rule>
      <PolygonSymbolizer fill="rgb(0,255,0)" />
      <LineSymbolizer stroke="rgb(255,255,0)" stroke-width="1"/>
    </Rule>
  </Style>
  <Layer name="layer" srs="+proj=longlat +ellps=GRS80 +no_defs ">
    <StyleName>My Style</StyleName>
    <Datasource>
		...
    </Datasource>
  </Layer>
</Map>

林地小班
叠加分析结果：

<Map  srs="+proj=longlat +ellps=GRS80 +no_defs">
  <Style name="My Style">
    <Rule>
      <LineSymbolizer stroke="rgb(255,0,0)" stroke-width="1"/>
    </Rule>
  </Style>
  <Layer name="layer" srs="+proj=longlat +ellps=GRS80 +no_defs ">
    <StyleName>My Style</StyleName>
    <Datasource>
		...
    </Datasource>
  </Layer>
</Map>

叠加分析结果
林地小班标注：

<Map  srs="+proj=longlat +ellps=GRS80 +no_defs">
  <Style name="My Style">
    <Rule>
      <TextSymbolizer face-name="Noto Sans CJK SC Regular" size="10" halo-fill="white" halo-radius="1" allow-overlap="false">[mian_ji]</TextSymbolizer>
    </Rule>
  </Style>
  <Layer name="layer" srs="+proj=longlat +ellps=GRS80 +no_defs ">
    <StyleName>My Style</StyleName>
    <Datasource>
		...
    </Datasource>
  </Layer>
</Map>

林地小班标注

通过如下代码进行瓦片服务合并：

var tilestrata = require('@conorpai/tilestrata');
const mapnik = require('@conorpai/tilestrata-mapnik');
const disk = require('tilestrata-disk');
var blend = require('tilestrata-blend');
var strata = tilestrata();
//林地小班
strata.layer('847a30b3-3763-48ee-a754-57b338700d09')
    .route('tile.png')
        .use(disk.cache({dir: '/Users/paiconor/Desktop/server/dir/map/847a30b3-3763-48ee-a754-57b338700d09/cache/'}))
        .use(mapnik({
            pathname: '/Users/paiconor/Desktop/server/dir/map/847a30b3-3763-48ee-a754-57b338700d09/mapnik.xml',
            OriX: -180,
            OriY: 90,
            FirstDPI: 1.40625,
            tileSize: 512,
            scale: 2
        }));
//叠加分析结果
strata.layer('50b6be1f-d2ff-4797-9686-cf525dfde42b')
    .route('tile.png')
        .use(disk.cache({dir: '/Users/paiconor/Desktop/server/dir/map/50b6be1f-d2ff-4797-9686-cf525dfde42b/cache/'}))
        .use(mapnik({
            pathname: '/Users/paiconor/Desktop/server/dir/map/50b6be1f-d2ff-4797-9686-cf525dfde42b/mapnik.xml',
            OriX: -180,
            OriY: 90,
            FirstDPI: 1.40625,
            tileSize: 512,
            scale: 2
        }));
//林地小班标注
strata.layer('54681f08-baf3-45d8-8052-770945f0a3ea')
    .route('tile.png')
        .use(disk.cache({dir: '/Users/paiconor/Desktop/server/dir/map/54681f08-baf3-45d8-8052-770945f0a3ea/cache/'}))
        .use(mapnik({
            pathname: '/Users/paiconor/Desktop/server/dir/map/54681f08-baf3-45d8-8052-770945f0a3ea/mapnik.xml',
            OriX: -180,
            OriY: 90,
            FirstDPI: 1.40625,
            tileSize: 512,
            scale: 2
        }));
//瓦片服务合并
strata.layer('mylayer').route('tile.png')
    .use(blend([
        ['847a30b3-3763-48ee-a754-57b338700d09','tile.png'],
        ['50b6be1f-d2ff-4797-9686-cf525dfde42b','tile.png'],
        ['54681f08-baf3-45d8-8052-770945f0a3ea','tile.png']
    ]));
strata.listen(22222);

前端加载合并后的瓦片服务：
合并结果

TileStrata-blend还有一些选项可以设置，比如给合并结果设置背景色、设置某个瓦片服务的透明度等，这些待实际应用中再仔细研究。

展开全文 >>

使用PostGIS进行拓扑抽稀

2019-04-03

抽稀，是指减少图形的节点密度。有些图形例如国界、省界、市界等节点数能达到几万个，这样的图形在渲染和空间关系判断等环节中效率会很慢，所以在一些要求不是很严格的情况下，可以使用抽稀方法减少图形的节点密度，加快处理效率。

对于抽稀的要求，最重要的是要基本保持原图形的形状，这个大部分抽稀算法都可以达到。今天我们说的是进一步的要求，就是相邻图形抽稀之后不能出现重叠和缝隙。

下面是使用PostGIS的ST_Simplify方法对要素进行抽稀的结果，可以看到比较多的重叠和缝隙：
普通抽稀

接下来介绍的拓扑抽稀方法就可以解决这个问题。

1.创建PostgreSQL数据库

如果数据已经入库，则可以跳过该操作。
创建数据库

2.创建PostGIS和Topology扩展

1 2	CREATE EXTENSION postgis; CREATE EXTENSION postgis_topology;

3.导入数据

如果处理的PostgreSQL数据库中已有数据，则跳过该操作。

这里使用GDAL提供的ogr2ogr命令行工具来做数据导入Shapefile格式的省界数据：

ogr2ogr -f "PostgreSQL" PG:"host=localhost port=5432 dbname=TopoSimplify user=postgres password=1234" /Users/paiconor/Downloads/拓扑抽稀效果/原始数据/CHN_adm1.shp -lco GEOMETRY_NAME=geom -lco FID=pk_uid -nlt PROMOTE_TO_MULTI -progress

导入数据

4.复制数据

由于处理过程中将会给数据添加字段，为了不破坏数据，将会复制一份数据进行拓扑抽稀操作。

1	create table chn_adm1_bak as select * from chn_adm1

5.创建拓扑

创建拓扑需要传入拓扑模式名称和数据的SRID，拓扑模式名称使用的是数据名称后面加上“_topo”标识，数据的SRID通过geometry_columns视图看到是4326。

1	SELECT topology.CreateTopology('chn_adm1_topo', 4326);

创建拓扑之后，在数据库中生成一个新的模式，用来存储拓扑信息：

geometry_columns中添加了相应的拓扑表信息：

6.为数据添加拓扑几何字段

添加拓扑几何字段需要传入的参数是：拓扑模式名称、数据所在模式名称、数据名称、拓扑几何字段名称和几何类型。这里将拓扑几何字段添加到复制的表(chn_adm1_bak)上。

1	SELECT topology.AddTopoGeometryColumn('chn_adm1_topo', 'public', 'chn_adm1_bak', 'topo_geom', 'MULTIPOLYGON');

添加拓扑字段

7.使用原始图形构建拓扑

构建拓扑传入的参数是：普通几何字段名称、拓扑模式名称、layer_id(暂时不清楚这个参数的作用，默认传入1)、数据容差(经纬度数据使用默认容差0.000000008983153，平面数据使用0.001)：

1	UPDATE chn_adm1_bak SET topo_geom = topology.toTopoGeom(geom, 'chn_adm1_topo', 1, 0.000000008983153);

这个处理过程和图形有关，由于我使用的是全国省界，节点非常密集，时间也比较久，处理完成之后：
构建拓扑

8.拓扑弧段抽稀

接下来使用Sandro Santilli提供的SimplifyEdgeGeom函数进行拓扑弧段抽稀。
首先将SimplifyEdgeGeom函数添加到数据库中：
添加SimplifyEdgeGeom函数
然后调用SimplifyEdgeGeom函数进行拓扑弧段抽稀，传入的参数是：拓扑模式名称、弧段ID字段名称(固定是edge_id)、抽稀容差：

1	SELECT SimplifyEdgeGeom('chn_adm1_topo', edge_id, 0.1) FROM chn_adm1_topo.edge;

9.将抽稀结果更新普通几何字段中

1	UPDATE chn_adm1_bak SET geom = topo_geom::geometry;

10.抽稀结果检查

通过SQL查询抽稀前后甘肃省界的节点数：

1	select ST_NumPoints(ST_ExteriorRing(ST_GeometryN(geom,1))) from chn_adm1 where name_1 = 'Gansu'

抽稀前节点数

1	select ST_NumPoints(ST_ExteriorRing(ST_GeometryN(geom,1))) from chn_adm1_bak where name_1 = 'Gansu'

抽稀后节点数

通过工具查看抽稀后省界间是否存在重叠和缝隙：
查看抽稀结果

通过工具查看抽稀后的图形形状是否有比较大的变化：
查看抽稀结果

11.后续工作

如果需要将抽稀后的几何更新到原始表中，可以使用如下SQL进行更新：

1	update chn_adm1 a set geom = (select b.geom from chn_adm1_bak b where a.pk_uid = b.pk_uid);

如果需要将抽稀后的结果导出，可以继续使用ogr2ogr工具进行导出。

展开全文 >>