CN117131297A - 一种基于浏览器的地理信息数据的快速发布方法 - Google Patents

一种基于浏览器的地理信息数据的快速发布方法 Download PDF

Info

Publication number
CN117131297A
CN117131297A CN202310892618.2A CN202310892618A CN117131297A CN 117131297 A CN117131297 A CN 117131297A CN 202310892618 A CN202310892618 A CN 202310892618A CN 117131297 A CN117131297 A CN 117131297A
Authority
CN
China
Prior art keywords
data
point
geographic information
information data
line segment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202310892618.2A
Other languages
English (en)
Other versions
CN117131297B (zh
Inventor
刘博�
薛炜
王向珍
李飞亮
王佳乐
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Karamay Sky Map Co ltd
Original Assignee
Karamay Sky Map Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Karamay Sky Map Co ltd filed Critical Karamay Sky Map Co ltd
Priority to CN202310892618.2A priority Critical patent/CN117131297B/zh
Priority claimed from CN202310892618.2A external-priority patent/CN117131297B/zh
Publication of CN117131297A publication Critical patent/CN117131297A/zh
Application granted granted Critical
Publication of CN117131297B publication Critical patent/CN117131297B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/29—Geographical information databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9537—Spatial or temporal dependent retrieval, e.g. spatiotemporal queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Remote Sensing (AREA)
  • Processing Or Creating Images (AREA)

Abstract

本发明涉及地理信息数据发布技术领域，解决了目前创建点的图层进行标注导致数据更新困难、繁琐且耗时较长的技术问题，尤其涉及一种基于浏览器的地理信息数据的快速发布方法，该方法包括以下步骤：S1、获取任意区域内的地理信息数据；S2、以Json数据格式自定义地理信息数据中的点状符号、线状符号、填充符号以及相关过滤规则；S3、采用格式转换算法将自定义后的地理信息数据生成Json数据。本发明能够实现在修改要素信息时直接进行修改，从而规避了同步更新其他图层数据的现象，解决了数据更新困难、繁琐且耗时较长的问题，最大程度上降低服务端的访问量以及检索负担，进而提高了对于地理信息数据的发布速率。

Description

一种基于浏览器的地理信息数据的快速发布方法
技术领域
本发明涉及地理信息数据发布技术领域，尤其涉及一种基于浏览器的地理信息数据的快速发布方法。
背景技术
电子地图可以分为两个部分，一个部分是用户所使用的用户端，另一部分是由服务商所提供的网络端，该网络端也称为地图引擎。用户通过操作用户端来向电子引擎发送请求，如果该请求通过地图引擎的认证，则地图引擎会返回相应的地图数据给用户端，之后用户端通过数据读取、渲染等手段将电子地图显示在显示屏上，以供用户进行观看。
当前矢量地图的标注渲染多数是采用创建点的图层进行标注，比如说，一条道路要建立道路中心线、道路面和道路中心点三个图层数据，采用这种方式将会导致数据更新困难、繁琐且耗时较长，比如要改一条要素信息就要同步更新掉三个图层数据，不仅给服务端造成了大量的访问、检索负担，在用户体验上也并不友好。
发明内容
针对现有技术的不足，本发明提供了一种基于浏览器的地理信息数据的快速发布方法，解决了目前创建点的图层进行标注导致数据更新困难、繁琐且耗时较长的技术问题。
为解决上述技术问题，本发明提供了如下技术方案：一种基于浏览器的地理信息数据的快速发布方法，该方法包括以下步骤：
S1、获取任意区域内的地理信息数据；
S2、以Json数据格式自定义地理信息数据中的点状符号、线状符号、填充符号以及相关过滤规则；
S3、采用格式转换算法将自定义后的地理信息数据生成Json数据；
S4、对生成的Json数据中的线、面几何体进行标注得到矢量地图标注渲染数据；
S5、将矢量地图标注渲染数据实时切片为用于在Web端启用渲染并于大型地理空间数据集进行交互的矢量切片；
S6、采用Canvas渲染器对矢量切片进行Web端渲染并完成快速发布。
进一步地，在步骤S2中，具体过程包括以下步骤：
S21、定义符号symbolizers已完成对于地理信息数据中的点状符号、线状符号和填充符号的自定义；
S22、定义相关过滤规则filter，具体为：
通过递归方式支持多重嵌套，例如(&&((||||)&&))||；
支持“&&”、“||”、“！”逻辑符；
运算operator[“运算符”，“左值”，“右值”]；
支持“＝＝”、”*＝”、”|＝”、”<”、”<＝”、”>”、”>＝”运算符号；
S23、定义缩放级别zoom，配置最大和最小显示级别。
进一步地，在步骤S21中，具体过程包括以下步骤：
S211、在定义名称时需采用canvas原名称设定，不区分大小写，无波峰命名规则，如果原来是波峰方式则去掉中间分隔符；
S212、区分填充和线条(描边)，填充属性配置前加’fill’前缀，默认为线条stroke，例如：opacity透明度，无前缀表示为线条透明度，fillopacity则表示为填充透明度。
S213、定义渲染器类型kind，Mark定义为点状符号；Fill定义为填充符号；Icon定义为图标符号；Line定义为线状符号；Text定义为文本符号。
进一步地，在步骤S3中，具体过程包括以下步骤：
S31、加载SLD样式配置，并读取自定义符号的配置属性，自定义符号为点状符号Mark、填充符号Fill、图标符号Icon、线状符号Line和文本符号Text；
S32、读取比例尺数据并转换响应的缩放级别，格式转换公式如下：
Resolution*Scale＝1/96*0.0254＝0.0254/96
Scale＝0.0254/(96*Resolution)
Scale＝1:(96*Resolution/0.0254)
其中，Resolution表示分辨率，Scale表示比例尺数据；
S33、将自定义后的地理信息数据按照格式转换公式生成json数据。
进一步地，在步骤S4中，具体过程包括以下步骤：
S41、获取Json数据中要素信息的layer图层及其所在canvas画布，要素信息为Json数据中所包含的几何体数据；
S42、判断要素信息中几何体的类型，并选择相应的标注方式，类型包括点、线段、多边形，标注方式包括中心点标注、重心点标注和沿线标注；
如果是点，则采用中心点标注，且中心点为该点的当前点坐标(x,y)；
如果是多边形，则采用重心点标注，并计算多边形的重心点；
如果是线段，则采用沿线标注，并计算线段的标注路径，否则计算线段的中心点；
S43、使用canvas命令绘制画布并保存。
进一步地，在步骤S42中，判断要素信息中几何体的类型，具体过程包括：
获取要素信息中几何体的所有点数组points:[[x1,y1],[x2,y2]…]
如果点数组points的长度等于1，则几何体为点；
如果点数组Points的长度大于1，且第一个点不等于最后一个点，则几何体为线段；
如果点数组Points的长度大于1，且第一个点等于最后一个点，则几何体为多边形。
进一步地，在步骤S42中，计算多边形的重心点，包括以下步骤：
S4211、以多边形的一个顶点O为原点，作连接原点O与其他所有非相邻顶点的线段，将多边形分为n-2个三角形；
S4212、计算n-2个三角形的面积和重心；
S4213、根据面积三角形的面积和重心计算多边形的重心；
多边形的重心(Cx，Cy)的计算公式为：
上式中，cx[i]、cy[i]、S[i]分别为所划分的第i个三角形的重心坐标和面积。
进一步地，在步骤S42中，计算线段的标注路径，具体过程包括以下步骤：
S4221、根据线段的像素坐标计算其长度；
S4222、判断线段的长度是否小于文本的宽度；
若小于，则返回步骤S4221；
若大于，则进入步骤S4223；
S4223、计算线段的起点和终点之间的夹角；
S4224、判断夹角是否小于0，若夹角小于0，则对数组倒排；
S4225、逐个计算文本起始点及偏移度并使用canvas绘制。
进一步地，在步骤步骤S42中，计算线段的中心点，具体过程包括以下步骤：
S4231、计算线段的总长度，并除以2得到长度halfDist；
S4232、依次计算线段中相邻两点和/>的距离segDist并累加得到长度dist；
如果长度dist大于线段总长度的1/2，则计算超出长度的所占比例ratio；
具体的，所占比例ratio的计算公式为：
S4233、根据所占比例ratio计算线段的中心点；
线段的中心点(Px，Py)的计算公式为：
上式中，ratio为长度dist减去线段总长度1/2的所占比例。
进一步地，在步骤S5中，具体过程包括以下步骤：
S51、从矢量地图标注渲染数据中读取GeoJSON数据；
S52、采用矢量切片生成算法根据GeoJSON数据的纬度生成矢量切片Tiles。
借由上述技术方案，本发明提供了一种基于浏览器的地理信息数据的快速发布方法，至少具备以下有益效果：
1、本发明实现了根据几何体进行自动标注的功能，能够根据几何体的类型进行选择中心点标注、重心点标注和沿线标注的标注方式，能够实现在修改要素信息时直接进行修改，从而规避了同步更新其他图层数据的现象，解决了数据更新困难、繁琐且耗时较长的问题，最大程度上降低服务端的访问量以及检索负担，进而提高了对于地理信息数据的发布速率。
2、本发明将GIS软件与Web服务器集成，利用通用的浏览器进行地理信息的发布，无需使用任何插件，从而大大地降低了终端客户的培训成本和技术负担。
3、本发明利用多种技术的WebGIS能做到“一次编写，多处运行”。真正发挥跨平台的技术优势。能够让GIS系统的用户通过网络不但能够访问本系统中分散在不同站点的数据和数据处理服务，同时还能维持系统的一致性以及平衡这种访问的网络负载。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本发明地理信息数据的快速发布方法的流程图；
图2为本发明计算多边形重心点的示意图；
图3为本发明矢量切片的示意图；
图4为本发明计算切片边界的示意图；
图5为本发明笛卡尔坐标转换为图像坐标的示意图；
图6为本发明地图叠加展示界面的实例图；
图7为本发明监控视角分析界面的实例图；
图8-图10均为本发明数据管理界面的实例图。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。借此对本申请如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
电子地图作为替代传统的地图的优选方案，早已被广大用户所接受，使用电子地图已经是日常生活中不可缺少的一部分。电子地图常用的功能有：地理信息查阅、定位、自动导航等等。
电子地图可以分为两个部分，一个部分是用户所使用的用户端，另一部分是由服务商所提供的网络端，该网络端也称为地图引擎。用户通过操作用户端来向电子引擎发送请求，如果该请求通过地图引擎的认证，则地图引擎会返回相应的地图数据给用户端，之后用户端通过数据读取、渲染等手段将电子地图显示在显示屏上，以供用户进行观看。
而本申请所提供的地理信息数据的快速发布方法是基于Web端渲染并完成快速发布，在浏览器中，对于地理信息数据的发布主要存在以下问题：
1、地图发布服务或者使用ArcGIS或者使用国信思南的产品，或者使用超图，而这些全都是商业软件，费用较高，一些用户需求很难实现；
2、当前地理信息数据存在多种坐标系，不同坐标系很难进行叠加显示；
3、在数据存储方面还主要还是shp(ESRI Shapefile)格式，这是一种文件形式的存储对I/O要求很高，如果是大数据量的检索是远远不如数据库形式的存储；
4、在地图要素交互方面，传统的方式是发布图片切片，交互后通过接口反向查询数据返回前端，这种方式不仅给服务端造成了大量的访问、检索负担，在用户体验上也并不友好；
5、在多图层叠加展示方面如果全部或者大部分都通过栅格切片方式，会加大数据流量问题，在交互方面因为图层是叠加暂时的，也就说只有最上面的一层图层才有有效的交互；
6、传统的地图配图是通过专业的制图软件来进行的，这就要求配图人员需要掌握这门软件，无形中就增加了人员成本及用户绑定。
有鉴于此，本实施例提出了一种基于浏览器的地理信息数据的快速发布方法，请参照图1，该方法的实现是通过依次执行以下步骤来完成的，具体步骤如下：
S1、获取任意区域内的地理信息数据；对于任意区域主要还是取决于用户端方面的选择，即在现实中用户端所选取的某个区域内的电子地图，而电子地图的显示需要读取与该区域相对应地理信息数据，需要说明的是，地理信息数据能够从相应的数据库中直接获取，在此不再详细赘述地理信息数据的来源。
S2、以Json数据格式自定义地理信息数据中的点状符号、线状符号、填充符号以及相关过滤规则；步骤S2中所进行的自定义地理信息数据中的点状符号、线状符号、填充符号以及相关过滤规则，可以理解为：结合SLD、OpenLayers-Styles、MapBox-Styles、CartoCSS等样式标准，自定义地理信息数据样式新格式，该格式可以成为其他标准的交换格式，在所有支持的格式之间进行转换，因此自主开发了符号编辑器、过滤器、代码编辑器、预览图和图例等。
在数据存储方面还主要还是shp(ESRI Shapefile)格式，这是一种文件形式的存储对I/O要求很高，如果是大数据量的检索是远远不如数据库形式的存储，因此需要解决地理信息数据发布服务的一致性。
一、目前主要的地图发布引擎有ArcGIS Server、SuperMap iServer和司南超擎。
1)、ArcGIS Server其实最大的问题就是授权，因无法使用最新版本的服务，导致以下几个问题：
A、在矢量切片上支持并不友好；
B、不支持最新版本的postgis数据库；
C、前端API过于庞大加载慢。
2)、SuperMap iServer没有优点就是最大的缺点。超图系列的看似什么都支持，其实本身并不具备行业技术优势。一直在做技术堆砌，对于非专业地理信息性质的公司选择超图是最好的选择。
3)、司南超擎，使用的是矢量切片技术，前端JS使用的是mapbox-gl，目前来说最大的问题就是没有提供WFS服务，无法对要素进行增删改操作。
二、解决数据存储的一致性
数据存储的一致性，我们首先要解决两个问题：
1)、数据的存储方式；
2)、数据和坐标系转换；
1、数据的存储方式：
我们常见的主要是shp(ESRI Shapefile)格式，也就是文件方式。文件方式的存储最大的弊端就是要受到I/O的影响。ArcGIS其实很少直接用shp文件作为发布数据的载体，主要是通过工具导入到oracle数据库里。不选用常见的shp格式，那就需要选一款支持空间查询的数据库。最终，我们选择是PostGIS。
2、数据和坐标系转换：
通过研究了一下各大gis产品，发现在数据和坐标系转换基本都使用的是OGR(OGR是GDAL项目的一个分支，提供对矢量数据的支持)，GDAL(Geospatial Data AbstractionLibrary)是一个在X/MIT许可协议下的开源栅格空间数据转换库。它利用抽象数据模型来表达所支持的各种文件格式。它还有一系列命令行工具来进行数据转换和处理。
三、解决数据发布的一致性
(一)矢量数据
很长时间以来我们在使用矢量数据都是由服务器端提供WFS服务(OGCWebFeatureService(WFS)接口标准定义了一组接口，用于在Internet上访问要素和要素属性级别的地理信息)。WFS服务更适合要素的操作，并不适合用于地图的渲染。每个请求都需要进行一次数据查询对于服务器端压力过重。但是单纯使用WMS/WMTS服务，又很难达到对要素属性的显示、查询、过滤等要求。
为此选择了MVT格式(MVT的全名是MapboxVectorTile，是Mapbox标准的向量切片)也就是我们常说的矢量切片。
在数据传输上采用了pbf格式。谷歌公司早在很久以前提出了一种数据格式，他们希望数据以二进制编码的形式进行传播，这样数据量可以做到最小，传播速度可以提升10多倍。于是他们提出了protocol buffer简称pbf这种格式。事实上mvt文件的编码也借鉴了这种思想，mvt文件实际上也是编码文件，但是不是二进制码，二者的编码规则不相同，从体积和传输速度上讲，pbf更彻底，传输速度更快。
(二)数据交互方面
无论是shp格式，还是KML/XML或OSM等作为数据交互对于客户端来说都不友好。我们需要选择一个适合网络传输、易读、易操作的地理信息数据格式作为前后端的交互介质。符合JSON标准GeoJSON成为了最优选择。
四、矢量切片和前端渲染
(一)首先矢量切片存在的必要性体现在：
1.当表示的地理范围足够大，或者数据量层级足够多的时候，栅格切片弊端多，矢量切片适用；
2.从数据体积层面讲，矢量切片提及要比栅格切片小的多；
3.矢量切片更加灵活，可查询，可交互，用户反馈效果好；
4.数据传输，转化更加容易，安全，展示效果好；
5.矢量切片和栅格切片的原理一样，都是把数据按照层级分割开来加载，但矢量切的不是图片，而是数据本身，或者更精确地说，那不是切，而是抽稀+分级，抽稀是指在相对遥远的距离我们不需要看的那么清楚，举个例子，在视觉中展现的一个五边形，放大10倍以后很可能是9边形、11边形等等。
(二)使用矢量数据或矢量切片就必须要用web端的渲染
目前主流的渲染有canvas，svg，WebGL，WebGL通过增加OpenGL ES 2.0的一个JavaScript绑定，WebGL可以为HTML5 Canvas提供硬件3D加速渲染，对于一个点来说需要三个坐标。
SVG优点多，交互方便，纯矢量图形，但是对于大数据量显示会生成海量DOM，客户端负载重。
兼顾负载等方面，我们主要是使用了Canvas进行web端渲染。
五、解决API接口的一致性
(一)前端Javasript
1、因各大GIS厂商都有自己的标准体系，比如Esri的，百度的，谷歌的，超图的，MapBox的，这些API跟他们提供的服务具有强关联性。我们在实际生产中会根据用户的实际要求会相应的选择不同的api作为前端的开发。这就导致很多已经做好的功能无法复用，需要重新学习和开发，极大的影响生产效率。为此，我们需要一个中间件，能够沟通不同API的桥梁。这就是KTGIS JS主要解决的问题。
2、在做前端开发过程中，我们发现很多业务都是基于相同的地图功能衍生实现，而这些地图功能都需要进行额外的编码。实际生产中我们重点应该关注的是业务的逻辑和呈现。那么我们就要对基础地图功能进行封装，尽量通过配置或只编写相关的业务代码来呈现，即功能和业务解耦。
(二)服务端Web API
不管是数据请求还是功能请求都以服务的方式通过统一的API接口调用。首先，我们得支持主流关系型数据库，例如oracle，mysql，mssql，postgres等等和常用得非关系型数据库，例如mongodb，Elasticerach，Membase等。
其次，我们需要支持各种地图数据，这方面可以通过地图数据发布服务来解决
最后，确定数据交互主要以Json格式。
有鉴于此，本实施例所提供的方法中还包括如下步骤：
S21、定义符号symbolizers已完成对于地理信息数据中的点状符号、线状符号和填充符号的自定义；在步骤S21中，具体过程包括以下步骤：
S211、在定义名称时需采用canvas原名称设定，不区分大小写，无波峰命名规则，如果原来是波峰方式则去掉中间分隔符；
S212、区分填充和线条(描边)，填充属性配置前加’fill’前缀，默认为线条stroke，例如：opacity透明度，无前缀表示为线条透明度，fillopacity则表示为填充透明度。
S213、定义渲染器类型kind，Mark定义为点状符号；Fill定义为填充符号；Icon定义为图标符号；Line定义为线状符号；Text定义为文本符号。
S22、定义相关过滤规则filter；
步骤S22中的定义相关过滤规则filter，具体为：
通过递归方式支持多重嵌套，例如(&&((||||)&&))||；
支持“&&”、“||”、“！”逻辑符；
运算operator[“运算符”，“左值”，“右值”]；
支持“＝＝”、”*＝”、”|＝”、”<”、”<＝”、”>”、”>＝”运算符号。
S23、定义缩放级别zoom，配置最大和最小显示级别。
步骤S2最终实现结合SLD、OpenLayers-Styles、MapBox-Styles、CartoCSS等样式标准，自定义地理信息数据样式新格式，该格式可以成为其他标准的交换格式，在所有支持的格式之间进行转换。
S3、采用格式转换算法将自定义后的地理信息数据生成Json数据；在步骤S3中，具体过程包括以下步骤：
S31、加载SLD样式配置，并读取自定义符号的配置属性，自定义符号为点状符号Mark、填充符号Fill、图标符号Icon、线状符号Line和文本符号Text；
S32、读取比例尺数据并转换响应的缩放级别，格式转换公式如下：
Resolution*Scale＝1/96*0.0254＝0.0254/96
Scale＝0.0254/(96*Resolution)
Scale＝1:(96*Resolution/0.0254)
其中，Resolution表示分辨率，Scale表示比例尺数据；
S33、将自定义后的地理信息数据按照格式转换公式生成json数据。
S4、对生成的Json数据中的线、面几何体进行标注得到矢量地图标注渲染数据；当前矢量地图的标注渲染多数是采用创建点的图层进行标注，比如说，一条道路要建立道路中心线、道路面和道路中心点三个图层数据，采用这种方式将会导致数据更新困难，比如要改一条要素信息就要同步更新掉三个图层数据。
有鉴于此，本实施例所提供的方法还包括如下步骤：
S41、获取Json数据中要素信息的layer图层及其所在canvas画布，要素信息为Json数据中所包含的几何体数据；
S42、判断要素信息中几何体的类型，并选择相应的标注方式，类型包括点、线段、多边形，标注方式包括中心点标注、重心点标注和沿线标注；
如果是点，则采用中心点标注，且中心点为该点的当前点坐标(x,y)；
如果是多边形，则采用重心点标注，并计算多边形的重心点；
如果是线段，则采用沿线标注，并计算线段的标注路径，否则计算线段的中心点；
S43、使用canvas命令绘制画布并保存。
在步骤S42中，判断要素信息中几何体的类型，具体过程包括：
获取要素信息中几何体的所有点数组points：[[x1，y1]，[x2，y2]…]
如果点数组points的长度等于1，则几何体为点；
如果点数组Points的长度大于1，且第一个点不等于最后一个点，则几何体为线段；
如果点数组Points的长度大于1，且第一个点等于最后一个点，则几何体为多边形。
在步骤S42中，计算多边形的重心点如图2所示，包括以下步骤：
S4211、以多边形的一个顶点O为原点(可以选输入的第一个点作为原点)，作连接原点O与其他所有非相邻顶点的线段，将多边形(n条边)分为n-2个三角形；
S4212、计算n-2个三角形的面积和重心；
具体的，设其中一个三角形的重心为G(cx，cy)，顶点坐标分别为A1(x1，y1)、A2(x2，y2)、A3(x3，y3)，则有：
则面积S为：
S4213、根据面积三角形的面积和重心计算多边形的重心；
多边形的重心(Cx，Cy)的计算公式为：
上式中，cx[i]、cy[i]、S[i]分别为所划分的第i个三角形的重心坐标和面积，另外，在步骤S422中求每个三角形的重心坐标时要除以3，实际上不需要在求每个三角形坐标时都除以3，只需要求出∑cx[i]*S[i]后一次性除以3即可。
在步骤S42中，计算线段的标注路径，具体过程包括以下步骤：
S4221、根据线段的像素坐标计算其长度，具体的通过计算任意两点像素坐标间的长度并累加得到整个线段的长度，计算公式为：
线段上任意两点的像素坐标分别为和/>则P1和P2之间的距离计算公式为：
随后，通过依次选取线段上的点进行计算并累加，便可得到线段的长度。
S4222、判断线段的长度是否小于文本的宽度，文本的宽度可从上述步骤S213中所定义的文本符号Text直接获取；
若小于，则返回步骤S4221；
若大于，则进入步骤S4223；
S4223、计算线段的起点和终点之间的夹角；
具体的，线段起点和终点之间的夹角的计算方法为：
设线段起点的坐标为终点的坐标为/>则夹角的计算公式为：
bearing＝angle*(180/Math.PI)
上式中，angle表示起点和终点间夹角，单位为弧度，Math.atan2表示数学函数，计算二维坐标系中任意一个点(x，y)和原点(0，0)的连线与X轴正半轴的夹角大小，bearing表示角度，单位为°，Math.PI表示数学函数中的圆周率，为3.1415926…。
S4224、判断夹角是否小于0，若夹角小于0，则对数组倒排，具体为，将数组最后一位排到第一位，倒数第二位排到第二位，依次类推直到第一位排到最后一位，例如：原数组[1，2，3]倒排后数组为[3，2，1]。
S4225、逐个计算文本起始点及偏移度(任意两点夹角)并使用canvas绘制，具体为，Canvas API(画布)是在HTML5中新增的标签用于在网页实时生成图像，并且可以操作图像内容，基本上它是一个可以用JavaScript操作的位图(bitmap)。Canvas对象表示一个HTML画布元素-<canvas>，它没有自己的行为，但是定义了一个API支持脚本化客户端绘图操作。
在步骤步骤S42中，计算线段的中心点，具体过程包括以下步骤：
S4231、计算线段的总长度，并除以2得到长度halfDist，线段的总长度可通过上述步骤S4221得到；
S4232、依次计算线段中相邻两点和/>的距离segDist并累加得到长度dist；
如果长度dist大于线段总长度的1/2，则计算超出长度的所占比例ratio；
具体的，所占比例ratio的计算公式为：
S4233、根据所占比例ratio计算线段的中心点；
线段的中心点(Px，Py)的计算公式为：
上式中，ratio为长度dist减去线段总长度1/2的所占比例。
本实施例所提供的方法实现了根据几何体进行自动标注的功能，能够根据几何体的类型进行选择中心点标注、重心点标注和沿线标注的标注方式，能够实现在修改要素信息时直接进行修改，从而规避了同步更新其他图层数据的现象，解决了了数据更新困难、繁琐且耗时较长的问题，最大程度上降低服务端的访问量以及检索负担，进而提高了对于地理信息数据的发布速率。
S5、将矢量地图标注渲染数据实时切片为用于在Web端启用渲染并于大型地理空间数据集进行交互的矢量切片；在步骤S5中，具体过程包括以下步骤：
S51、从矢量地图标注渲染数据中读取GeoJSON数据；
S52、采用矢量切片生成算法根据GeoJSON数据的纬度生成矢量切片Tiles。
步骤S52中，从理论上讲，数字地图能够查看任何比例的数据，并且适用于任何感兴趣的区域，地图切片是一种约束数字地图的方法，能够大大提高地图的速度和效率显示，对于矢量切片生成算法以图3和图4为例进行说明，具体如下：
如图3所示，为矢量切片的示意图，切片地图不支持任何比例，仅提供有限的比例刻度集合，切片地图不会渲染任何感兴趣区域的数据，而是仅渲染它在刻度内的固定网格上，并由显示相应的磁贴集合，大多数磁贴地图通过从包含以下内容的单个磁贴开始划分世界整个世界，并称之为“缩放级别0”。每个成功“缩放级别”将磁贴数量增加4倍垂直和水平多次。
如图4所示，为计算切片边界的示意图，将GeoJSON数据中的要素信息裁剪到切片边界，在默认的Tiling scheme origin和图片大小的情况下，进行地图切片，就可以根据用户设置的比例尺来计算GeoJSON数据所在整个网格中的行列号了，即GeoJSON数据的经纬度。计算公式如下：
col1＝(int)Math.floor((point.x1-this.x1)/256/plottingResolution)
row1＝(int)Math.floor((Math.abs(point.y1-this.y1))/256/plottingResolution)
其中，point是当前点的坐标(x1,y1)，this指的是起点(-400,400)，plottingResolution是指当前图层下的地图分辨率，col1为列号，对应图5中的y，row1为行号，对应图5中的x，(int)Math.floor为数学函数，即返回小于或等于一个给定数字的最大整数，Math.abs为数学函数，即返回给定数字得绝对数。
这里计算要注意两点，一是计算结果只求整数部分；二是要取绝对值。
首先，对于地图发布来说，加载最效率的方法还是直接发布切片好的数据。但是，这种方式作为地图展示还算可以，如果进行交互操作就非常麻烦，同时对于一些更新频繁的数据，每更新一次数据就要重新切片就有些得不偿失了，矢量切片技术的出现，弥补了传统切片技术的实时性和交互性问题。因为是对数据进行了切片，效率高；使用了PBF压缩技术，切片数据小传输速率就快，从而能够实现实时、动态切片。这也为服务器端切片缓存提供了技术基础。即：随着请求可以将已经做好的切片缓存下来，在未有数据更新的情况下不做二次处理。
其次，对于客户端来说，缓存主要体现在以下几个方面：
1、PouchDB本地缓存；
2、预加载技术；
3、通过较低的缩放比例放大等效的Tiles。
因此具有以下优势：
1)降低项目成本。
2)便于数据维护、管理、分发，减少维护成本。
3)压缩数据提高传输效率节省服务器资源。
4)友好的交互和高效率的前端渲染，提升用户体验。
5)提高开发人员的工作效率。
6)提高代码利用率，提升开发和维护效率。
长期以来比较困扰的就是各数据集的坐标系不同的问题，传统的做法是将原始数据进行坐标系转换。ArcGIS虽然支持各种坐标系，但是对于同一地图还是需要将坐标系统一，举例来说，底图采用了国家2000大地坐标系，某一图层使用了北京54坐标系，那么当我们输入北京54坐标进行定位时，位置就会错。MapBox以及司南超擎主要采用了矢量切片技术，但是他们支持的坐标系比较单一，目前仅支持国家2000大地坐标系(EPSG：4490)和伪墨卡托投影(EPSG：3857)
本实施例依托强大的GDAL/ORG，实现不同坐标系的转换。注意：这里的转换不是将原数据集坐标进行转换，而是将不同的大地坐标系或投影坐标系转换为屏幕坐标。这样我们就彻底解决了不同坐标系之间的转换问题。即，同一数据源可以生成各种坐标系的切片数据，解决不同坐标系显示和交互的问题。
如图5所示，根据GeoJSON数据所在整个网格中的行列号，将其从笛卡尔坐标(相对于地理)转换为图像坐标(相对于图像左上角)。
笛卡尔坐标转换为图像坐标：
screenX＝zoom*cartX+screen_width/2+offsetX
screenY＝screen_height/2-zoom*cartY+offsetY
上式中，screenX：屏幕坐标x；
screenY：屏幕坐标y；
zoom：地图缩放级别，0级显示整个世界；
screen_width：当前屏幕得宽度；
screen_height：当前屏幕得高度；
offsetX：屏幕X横轴偏移量单位像素，默认为0；
offsetY：屏幕Y轴偏移量单位像素，默认为0；
cartX：笛卡尔坐标X；
cartY：笛卡尔坐标Y。
需要说明的是，请求数据中，Z表示缩放层级，Z＝zoom，XY原点在左上角，X从左向右，Y从上向下；
笛卡尔坐标(2维)X轴[-200,200]，Y轴[-200,200]代表屏幕坐标，X轴位于干涉[0,400]Y轴的间隔为[0,400]，实际一张世界地图展开要远远大于这个像素，因为不能让边缘为+/-无穷大，所以将缩放坐标让我们称之为scalefactor，例如1像素＝10笛卡尔。
随后通过删除在切片分辨率下不可见的额外折点，以整数形式量化从双精度到切片分辨率的坐标。
本实施例通过将矢量地图标注渲染数据切片为矢量切片，能够实现大数据量的实时渲染和动态加载，从而减少每次加载的数据量，提高效率。
S6、采用Canvas渲染器对矢量切片进行Web端渲染并完成快速发布。最终通过采用现有技术中的Canvas渲染器或SVG渲染器即可进行渲染并快速在Web端发布，因此，本实施例所提供的方法将GIS软件与Web服务器集成，利用通用的浏览器进行地理信息的发布，无需使用任何插件，从而大大地降低了终端客户的培训成本和技术负担。
本实施例所提供的方法实现了在国家和世界范围内的分布式环境下，地理空间数据和地理信息处理资源的共享，它允许用户通过网络实时获取不同系统中的地理信息，而无需考虑数据和处理的起源地和规格，避免了冗余数据存储，是实现地理空间数据共享的一次深刻的技术革命。
本实施例所提供的方法利用多种技术的WebGIS能做到“一次编写，多处运行”。真正发挥跨平台的技术优势。能够让GIS系统的用户通过网络不但能够访问本系统中分散在不同站点的数据和数据处理服务，同时还能维持系统的一致性以及平衡这种访问的网络负载。
实验例
通过采用本发明所提供的地理信息数据的快速发布方法，对某采油厂地理信息进行验证，具体内容如下：
某采油厂地理信息综合应用系统，通过我公司自主研发的KTGIS地图引擎，将厂区内的业务数据共计48个图层进行坐标转换、地图切片并发布成服务叠加展示，根据相关的业务需求进行了图层数据的专题应用。
1、地图叠加展示
如图6所示，为地图叠加展示界面的实例图，基于2000国家大地坐标系进行叠加发布，验证了此系统能显著提高海量地学数据的发布速度，实现了平滑的地图浏览，并具有灵活的数据查询和交互能力，充分满足地学数据在线发布服务的需求，使厂内各级管理人员在地图上对各类设施、设备等能找的到、看的清，提升了数据存在的价值。
2、监控视角分析
如图7所示，为监控视角分析界面的实例图，基于监控图层数据结合KTGIS的接口功能进行监控范围分析，便于用户查找监控盲区。
3、数据管理
如图8-图10所示，为数据管理界面的实例图，为用户实现了地图的上传、配图、属性配置、图层数据管理、图层发布、外部数据接口管理等功能，解决了用户在使用传统的地理信息软件对图层数据进行管理时的繁琐步骤，用户能自行运维的同时，提升了工作效率及应用效果。
以上实施方式对本发明进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种基于浏览器的地理信息数据的快速发布方法，其特征在于，该方法包括以下步骤：
S1、获取任意区域内的地理信息数据；
S2、以Json数据格式自定义地理信息数据中的点状符号、线状符号、填充符号以及相关过滤规则；
S3、采用格式转换算法将自定义后的地理信息数据生成Json数据；
S4、对生成的Json数据中的线、面几何体进行标注得到矢量地图标注渲染数据；
S5、将矢量地图标注渲染数据实时切片为用于在Web端启用渲染并于大型地理空间数据集进行交互的矢量切片；
S6、采用Canvas渲染器对矢量切片进行Web端渲染并完成快速发布。
2.根据权利要求1所述的地理信息数据的快速发布方法，其特征在于，在步骤S2中，具体过程包括以下步骤：
S21、定义符号symbolizers已完成对于地理信息数据中的点状符号、线状符号和填充符号的自定义；
S22、定义相关过滤规则filter，具体为：
通过递归方式支持多重嵌套，例如(&&((||||)&&))||；
支持“&&”、“||”、“！”逻辑符；
运算operator[“运算符”，“左值”，“右值”]；
支持“＝＝”、”*＝”、”|＝”、”<”、”<＝”、”>”、”>＝”运算符号；
S23、定义缩放级别zoom，配置最大和最小显示级别。
3.根据权利要求2所述的地理信息数据的快速发布方法，其特征在于，在步骤S21中，具体过程包括以下步骤：
S211、在定义名称时需采用canvas原名称设定，不区分大小写，无波峰命名规则，如果原来是波峰方式则去掉中间分隔符；
S212、区分填充和线条，填充属性配置前加’fill’前缀，默认为线条stroke；
S213、定义渲染器类型kind，Mark定义为点状符号；Fill定义为填充符号；Icon定义为图标符号；Line定义为线状符号；Text定义为文本符号。
4.根据权利要求1所述的地理信息数据的快速发布方法，其特征在于，在步骤S3中，具体过程包括以下步骤：
S31、加载SLD样式配置，并读取自定义符号的配置属性，自定义符号为点状符号Mark、填充符号Fill、图标符号Icon、线状符号Line和文本符号Text；
S32、读取比例尺数据并转换响应的缩放级别，格式转换公式如下：
Resolution*Scale＝1/96*0.0254＝0.0254/96
Scale＝0.0254/(96*Resolution)
Scale＝1:(96*Resolution/0.0254)
其中，Resolution表示分辨率，Scale表示比例尺数据；
S33、将自定义后的地理信息数据按照格式转换公式生成json数据。
5.根据权利要求1所述的地理信息数据的快速发布方法，其特征在于，在步骤S4中，具体过程包括以下步骤：
S41、获取Json数据中要素信息的layer图层及其所在canvas画布，要素信息为Json数据中所包含的几何体数据；
S42、判断要素信息中几何体的类型，并选择相应的标注方式，类型包括点、线段、多边形，标注方式包括中心点标注、重心点标注和沿线标注；
如果是点，则采用中心点标注，且中心点为该点的当前点坐标(x,y)；
如果是多边形，则采用重心点标注，并计算多边形的重心点；
如果是线段，则采用沿线标注，并计算线段的标注路径，否则计算线段的中心点；
S43、使用canvas命令绘制画布并保存。
6.根据权利要求5所述的地理信息数据的快速发布方法，其特征在于，在步骤S42中，判断要素信息中几何体的类型，具体过程包括：
获取要素信息中几何体的所有点数组points:[[x1,y1],[x2,y2]…]；
如果点数组points的长度等于1，则几何体为点；
如果点数组Points的长度大于1，且第一个点不等于最后一个点，则几何体为线段；
如果点数组Points的长度大于1，且第一个点等于最后一个点，则几何体为多边形。
7.根据权利要求5所述的地理信息数据的快速发布方法，其特征在于，在步骤S42中，计算多边形的重心点，包括以下步骤：
S4211、以多边形的一个顶点O为原点，作连接原点O与其他所有非相邻顶点的线段，将多边形分为n-2个三角形；
S4212、计算n-2个三角形的面积和重心；
S4213、根据面积三角形的面积和重心计算多边形的重心；
多边形的重心(Cx,Cy)的计算公式为：
上式中，cx[i]、cy[i]、S[i]分别为所划分的第i个三角形的重心坐标和面积。
8.根据权利要求5所述的地理信息数据的快速发布方法，其特征在于，在步骤S42中，计算线段的标注路径，具体过程包括以下步骤：
S4221、根据线段的像素坐标计算其长度；
S4222、判断线段的长度是否小于文本的宽度；
若小于，则返回步骤S4221；
若大于，则进入步骤S4223；
S4223、计算线段的起点和终点之间的夹角；
S4224、判断夹角是否小于0，若夹角小于0，则对数组倒排；
S4225、逐个计算文本起始点及偏移度并使用canvas绘制。
9.根据权利要求5所述的地理信息数据的快速发布方法，其特征在于，在步骤步骤S42中，计算线段的中心点，具体过程包括以下步骤：
S4231、计算线段的总长度，并除以2得到长度halfDist；
S4232、依次计算线段中相邻两点和/>的距离segDist并累加得到长度dist；
如果长度dist大于线段总长度的1/2，则计算超出长度的所占比例ratio；
具体的，所占比例ratio的计算公式为：
S4233、根据所占比例ratio计算线段的中心点；
线段的中心点(Px,Py)的计算公式为：
上式中，ratio为长度dist减去线段总长度1/2的所占比例。
10.根据权利要求1所述的地理信息数据的快速发布方法，其特征在于，在步骤S5中，具体过程包括以下步骤：
S51、从矢量地图标注渲染数据中读取GeoJSON数据；
S52、采用矢量切片生成算法根据GeoJSON数据的纬度生成矢量切片Tiles。
CN202310892618.2A 2023-07-20 一种基于浏览器的地理信息数据的快速发布方法 Active CN117131297B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310892618.2A CN117131297B (zh) 2023-07-20 一种基于浏览器的地理信息数据的快速发布方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310892618.2A CN117131297B (zh) 2023-07-20 一种基于浏览器的地理信息数据的快速发布方法

Publications (2)

Publication Number Publication Date
CN117131297A true CN117131297A (zh) 2023-11-28
CN117131297B CN117131297B (zh) 2024-06-28

Family

ID=

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117726707A (zh) * 2024-02-08 2024-03-19 北京未来宇航空间科技研究院有限公司 一种电子地图中自定义区域展示方法、装置及电子设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060041375A1 (en) * 2004-08-19 2006-02-23 Geographic Data Technology, Inc. Automated georeferencing of digitized map images
CN102693306A (zh) * 2012-05-24 2012-09-26 武汉大学 一种多尺度地理数据的在线联动更新服务方法
CN110019588A (zh) * 2017-09-04 2019-07-16 高德信息技术有限公司 一种道路确定方法及装置
CN112559667A (zh) * 2021-02-23 2021-03-26 北京简巨科技有限公司 地图编辑器、地图引擎、地图编辑系统、方法及存储介质
CN115408406A (zh) * 2022-08-26 2022-11-29 青岛励图高科信息技术有限公司 一种基于地图服务的高密度船位动态渲染系统
CN115810064A (zh) * 2022-11-01 2023-03-17 中冶武勘智诚(武汉)工程技术有限公司 基于开源gis技术的地图制图与发布平台的构建方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060041375A1 (en) * 2004-08-19 2006-02-23 Geographic Data Technology, Inc. Automated georeferencing of digitized map images
CN102693306A (zh) * 2012-05-24 2012-09-26 武汉大学 一种多尺度地理数据的在线联动更新服务方法
CN110019588A (zh) * 2017-09-04 2019-07-16 高德信息技术有限公司 一种道路确定方法及装置
CN112559667A (zh) * 2021-02-23 2021-03-26 北京简巨科技有限公司 地图编辑器、地图引擎、地图编辑系统、方法及存储介质
CN115408406A (zh) * 2022-08-26 2022-11-29 青岛励图高科信息技术有限公司 一种基于地图服务的高密度船位动态渲染系统
CN115810064A (zh) * 2022-11-01 2023-03-17 中冶武勘智诚(武汉)工程技术有限公司 基于开源gis技术的地图制图与发布平台的构建方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
朱正国: "电子地图中标注算法的研究及应用", 《中国优秀硕士学位论文全文数据库基础科学辑（月刊）》, no. 02, pages 1 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117726707A (zh) * 2024-02-08 2024-03-19 北京未来宇航空间科技研究院有限公司 一种电子地图中自定义区域展示方法、装置及电子设备

Similar Documents

Publication Publication Date Title
Pajarola et al. Survey of semi-regular multiresolution models for interactive terrain rendering
CN105718481B (zh) 一种海量地形数据组织发布方法
CN105516311A (zh) 一种电子地图全景图获取方法及系统
CN105701103A (zh) 一种基于地理信息的三维应用系统
van Oosterom et al. Vario-scale data structures supporting smooth zoom and progressive transfer of 2D and 3D data
CN107992589B (zh) 一种svg地图数据的加载方法、装置及系统
CA2827940A1 (en) Methods and systems for browsing heterogeneous map data
WO2018063915A1 (en) Rendering map data using descriptions of raster differences
CN111986306A (zh) 一种一体化数据展示与仿真平台
Singh et al. Web 3D GIS application for flood simulation and querying through open source technology
CN113495933A (zh) 一种矢量瓦片显示方法及系统
Loesch et al. OpenWebGlobe–an open source SDK for creating large-scale virtual globes on a WebGL basis
Yu et al. A hybrid system of expanding 2D GIS into 3D space
She et al. An efficient method for rendering linear symbols on 3D terrain using a shader language
CN117131297B (zh) 一种基于浏览器的地理信息数据的快速发布方法
Guney Rethinking GIS towards the vision of smart cities through CityGML
CN117408004A (zh) 一种基于矢量切片技术实现三维管网动态建模方法及系统
Wu et al. GPU ray casting method for visualizing 3D pipelines in a virtual globe
Christen et al. Large scale constraint delaunay triangulation for virtual globe rendering
Alderson et al. Offsetting spherical curves in vector and raster form
CN117131297A (zh) 一种基于浏览器的地理信息数据的快速发布方法
Glander et al. Automated cell based generalization of virtual 3D city models with dynamic landmark highlighting
Hu et al. Geospatial web service for remote sensing data visualization
CN112445951A (zh) 快速灵活切换的兼容多种地图的海洋数据可视化方法
Zhang et al. Research and application of visualization technology for massive land spatial data based on vector tiles

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant