zoukankan      html  css  js  c++  java
  • 符合我公司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/

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

                                          

  • 相关阅读:
    013.ES6 -对象字面量增强型写法
    012. ES6
    011. ES6 语法
    10. 9. Vue 计算属性的setter和getter 以及 计算属性的缓存讲解
    4. Spring MVC 数据响应方式
    3. SpringMVC 组件解析
    9. Vue 计算属性
    【洛谷 2984】给巧克力
    【洛谷 1821】捉迷藏 Hide and Seek
    【洛谷 1821】银牛派对Silver Cow Party
  • 原文地址:https://www.cnblogs.com/naaoveGIS/p/4196504.html
Copyright © 2011-2022 走看看