符合我公司GIS开源解决方案的探讨

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
简介: 文章版权由作者李晓晖和博客园共有,若转载请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/。 1.前言 这一周,我对GIS开源解决方案中涉及到的开源软件以及相关技术和流程做了一些初步的探索,也了解了一下其他公司利用开源方案做的比较成熟的案例。

文章版权由作者李晓晖和博客园共有,若转载请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/

1.前言

这一周,我对GIS开源解决方案中涉及到的开源软件以及相关技术和流程做了一些初步的探索,也了解了一下其他公司利用开源方案做的比较成熟的案例。这里我将一些技术关键点的预研做一下总结,同时对其他公司开源成功案例做一个分析,并提出个人认为目前最符合公司实际的GIS开源解决方案。

2.技术关键点预研

2.1空间数据入库(postgreSQL+postGIS)

利用postGIS将shp数据导入到postgreSQL中:

            

           

2.2空间数据编辑(uDig)

导入postgreSQL中的空间数据,可以进行展示以及编辑等操作。

 

2.3SLD样式文件的制作

可以直接利用uDig进行图层配图以及生产对应的SLD文件,并且可以导出:

 

 

2.4利用geoserver发布postGIS中的空间数据

在Geoserver中添加stores选择postgis即可:

 

 

2.5利用Geoserver发布图层组

将多个单独发布的图层服务组合为一个图层组,在一次请求中可以显示所有图层组下的图层:

 

包含了单元网格和社区的图层组:

 

2.6利用GeoWebCache切图缓存

研究了GeoWebCache的两种切图策略:一种是类AGS切图策略,即预先切图;一种是类AGS动态切图策略,即第一次请求时切图。

切图的相关配置和结果:

 

 

2.7对利用postGIS中的ST_Geometry函数进行空间数据管理和空间分析的预研

PostGIS中的ST_Geometry函数与SDE中的基本相同,不过它包含了自身的一些扩展函数。大致有如下功能:

 

在postgresql中测试了基本的空间要素增删查改以及空间要素的面积和长度获取:

 

3.其他公司成熟案例的研究

某公司的平安XX(安防项目)为这次研究的案例对象,通过与他们研发人员的交流,我大致得出以下几点信息:

3.1采用框架

Geoserver(地图服务器)+geoWebCache(瓦片缓存服务)+JBOSS(中间件)+postgreSQL(空间数据库)+Oracle(业务数据库)+uDig(空间数据编辑工具)。

3.2 该项目的一些分析点总结

a.该项目中Geoserver发布了近六十个图层,无明显不稳定问题。

b.该项目中的空间数据查询、编辑以及涉及到的空间分析功能,均用ST_Geometry函数实现,效率不错。

c.项目中地图瓦片缓存采用的geoWebCache的动态出图策略。近六十个图层作为底图,第一次请求出图的时间大约为20多秒(算上网络耗费)。

d.业务数据和空间数据分开存放,业务数据存放到Oracle中,空间数据存放到postgresql中。

e.项目的部署,为他们研发事先将数据均处理好后,再将已包含了数据的Geoserver和空间库发给现场工程人员。

 

3.3 个人对该项目的评价

3.3.1优点

a.出图和空间分析等功能是基本齐全的,效率和稳定性也不错。平安XX本身是一个比较大的项目,经历了比较好的实践考验。

b.将空间分析均用ST_Geometry+SQL来实现,而不通过Geoserver本身提供的WFS服务,可以有更多的定制需求,并且如果出错也方便排查。如果编写的合理的话,是可以加速数据的获取。同时,非GIS专业的开发人员也更容易理解。

c.将空间数据和业务数据分开,这样可以保证原有的其他项目使用的业务数据改动不大,保证系统的稳定性。

3.3.2缺点

a.项目的实施均需要研发人员参与,将数据入库以及发布。然后还要配合现场将环境布置好。

 

3.4 有待证实的地方

a.当用geoWebCache进行切图时,如果底图配图很复杂,是否可以保证切图的不失真。

b.当用GeoWebCache进行切图时,如果底图是很大的影像图(GB以上),是否可以保证切图的不失真,以及第一次出图时的出图效率。

c.当用Geoserver发布超过100个图层服务时,Geoserver本身的稳定性问题。

 

4.符合公司的开源解决方案

通过以上的技术关键点预研和其他公司成功案例的分析,结合公司目前的整体架构,我个人提出一个自认为比较符合公司的开源解决方案:

GeoServer(地图服务)+本地瓦片服务(ArcGIS等切图)+Tomcat(中间件)+Postgresql(空间数据库)+Oracle(业务数据库)+uDig(空间数据编辑工具)。

4.1系统详细构架解说

4.1.1底图缓存服务

公司可以依然采用ArcGIS来进行切图(公司有正版),这样有三个好处:

a.项目实施人员易操作。

b.配图容易。

c.可以保证切图质量和效率。

切完的图,我们采用我们已有的的离线瓦片策略即可,绕过GeoWebCache的采用和配置。当然,如果不想用ArcGIS切图,想进行全开源化,我们也可以研究使用MapTiler这个开源切图工具,切图的效率和效果都比较好。

4.1.2 部件动态出图(WMS)

采用公司已有的基于GeoServer的功能。

4.1.3 矢量查询(WFS)

采用公司已有的基于GeoServer的功能。

4.1.4 空间分析功能(WFS)

对于已通过GeoServer开发的空间分析功能,可基于采用。对于未开发的部分,建议采用ST_Geometry函数来进行。

4.1.5 空间数据库

采用postgresql+postGIS。PostGIS支持批量入库,也支持中文数据,稳定性和性能均很不错,操作也很容易。同时,开发方面的教程和社区论坛也很多。

4.1.6 数据编辑器

采用uDig来进行空间数据编辑。uDig可以直接导入shp数据或者postgis中的数据,也可以将shp数据导入到postgresql中。还支持数据的样式编辑以及SLD文件的生成。

4.2项目的实施

a.切图环节工程可自行完成。

b.空间数据的入库环节工程也可以通过postGIS自行完成,操作跟catalog操作一样很简单。

c.空间数据的发布和部件基本样式的关联,以及业务数据的生成,可以通过修改目前已有的小工具来实现。

d.复杂样式的配置和发布,可以由研发来协助完成。

 

                                                                       -----欢迎转载,但保留版权,请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/

                                                                           如果您觉得本文确实帮助了您,可以微信扫一扫,进行小额的打赏和鼓励,谢谢 ^_^

                                      

 

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍如何基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
Windows
ps软件2023免费磨皮滤镜插件portraiture安装下载教程
Portraiture一款适用于Photoshop与Lightroom的智能磨皮滤镜插件,可智能识别人像的皮肤、头发、眉毛等区域,实现自动化的磨皮、美颜处理,再也不用研究那些晦涩难懂的磨皮教程了,一键磨皮走起! 接下来,一起来看看怎么安装激活这款插件吧。
4998 3
|
7月前
|
存储 数据挖掘 Python
单细胞 轨迹分析 教程(长文+代码)
单细胞 轨迹分析 教程(长文+代码)
265 10
单细胞 轨迹分析 教程(长文+代码)
|
数据挖掘 定位技术 API
Python GIS神器geopandas 1.0版本来了
Python GIS神器geopandas 1.0版本来了
330 4
|
人工智能 UED
提升5.69倍,高效RAG上下文压缩方法COCOM
【8月更文挑战第7天】在AI领域,大型语言模型(LLMs)展现出了强大的计算与知识处理能力,但也面临着处理复杂任务时因上下文信息激增而导致生成时间延长的问题。为解决这一挑战,研究人员开发了COCOM上下文压缩方法,该方法通过将冗长的上下文信息压缩成简洁的上下文嵌入,有效提升了RAG系统的解码速度。实验表明,COCOM能在不牺牲答案质量的前提下,将解码时间最多提升5.69倍,极大改善了用户体验。然而,该方法也可能存在信息损失的风险,且在特定任务上的效果可能受限,因此在实际应用中需综合考量压缩率与答案质量的平衡。论文详情参见:https://arxiv.org/abs/2407.09252。
482 3
|
网络协议
masscan的常用命令记录
masscan的常用命令记录
846 0
|
安全 关系型数据库 Go
远程连接PostgreSQL:配置指南与安全建议
远程连接PostgreSQL:配置指南与安全建议
1162 0
|
Rust 关系型数据库 Linux
如何发布具有超高性能的地图服务
如何发布具有超高性能的地图服务
172 0
|
自然语言处理 JavaScript 前端开发
低代码平台加载远端组件解决方案(1)——defineAsyncComponent
低代码平台加载远端组件解决方案(1)——defineAsyncComponent
919 0
|
Docker 容器
docker使用遇到问题Got permission denied while trying to connect to the Docker daemon socket
docker使用遇到问题Got permission denied while trying to connect to the Docker daemon socket
1692 0
|
Linux C# Windows
Cesium系列:dae模型转gltf
如何将dae格式模型转成gltf格式
542 0