3.3. Web 制图体系结构的数据层

在上一课中,您了解到用于Web 制图的系统架构包括一个数据层。这可以简单到服务器计算机上文件夹中的几个shapefile,也可以复杂到包含独立文件和关系数据库生态系统的多个企业级服务器。确实,在我们的系统架构图中,我已将数据层表示为包含文件服务器和数据库服务器。

../../_images/data_architecture.png

图3.1文本描述

数据层包含将包含在web地图中的数据集。几乎可以肯定的是,它将为您的专题网络地图层存储数据。如果您决定创建自己的基础地图和瓦片集,它也可能保存基础地图图层的数据。有时,您会从其他人的服务器中提取底图,甚至很可能会有一些专题图层,从而减轻了维护数据的负担。

一些组织对于采用与他们日常编辑使用的相同数据库并将其放在Web上的想法感到不安。出于安全和性能方面的原因,存在这种不安的理由。如果允许Web地图用户修改数据库中的项目,则要避免数据被删除,破坏或破坏的可能性。此外,您也不希望网络用户的活动对数据库造成如此沉重的负担,以至于内部GIS用户的性能会变慢,反之亦然。

出于这些原因,组织通常会创建其数据库的副本或副本,并将其指定为仅供web使用。如果web地图中的要素不是设计为供最终用户编辑的,则此数据库副本是只读的。另一方面,如果web用户将对数据库进行编辑,则它将使用自动脚本或web服务定期与内部“生产”数据库同步。如果您希望GIS分析员在将web编辑提交到生产数据库之前检查web编辑,则可以在同步之前插入质量保证(QA)步骤。

3.3.1. 数据放在哪里?在服务器上还是在自己的机器上?

通常,您可以通过最小化数据到达最终用户之前必须在计算机之间进行的“跳跃”次数来提高web地图的性能。如果您的数据是基于文件的或存储在非常简单的数据库中,则可以将其副本直接存储在承载地理空间web服务的计算机上,从而消除地理空间服务器和数据服务器之间的网络通信。但是,如果您有大量数据,或者数据库有大量用户,最好将数据库保存在自己的计算机上。将数据库隔离到其自身的硬件上,可以使用更具针对性的备份和安全性流程以及冗余存储机制来减轻数据丢失和损坏。当许多并发用户访问这两个组件中的任何一个时,它还有助于防止数据库和服务器争用资源。

如果选择将数据存储在与服务器分离的计算机上,则需要确保防火墙允许在所有必要端口上的计算机之间进行通信。这可能需要咨询您的IT员工(如有必要,请烘焙饼干)。您可能还需要确保运行web服务的系统进程被允许从另一台计算机读取数据。最后,您不能使用本地路径(如C:\data\Japan)来引用数据集;您必须在共享路径中使用计算机的网络名称;例如,\\dataserver\data\Japan。

3.3.2. 文件与数据库

在设计数据层时,您将需要决定是将数据存储在一系列简单文件(例如shapefile或KML)中还是存储在包含空间数据支持的数据库中(例如PostGIS或SpatiaLite)。如果您的数据集不经常更改且大小可管理,则基于文件的数据方法比数据库更容易建立。基于文件的数据集也可以更轻松地在用户和计算机之间转移和共享。

当您有大量数据要存储、数据正由不同的方频繁编辑、需要允许不同的安全特权层或维护关系表以链接数据集时,数据库更为合适。数据库还可以为运行SQL查询和计算空间关系(如交集)提供强大的本机选项。

如果有一个长期运行的地理信息系统项目位于数据库中,而您现在决定将其公开到web上,则需要决定是将数据保存在数据库中,还是将数据的副本提取到基于文件的数据集中。

3.3.3. 开放数据格式和专有格式

为了回顾上一部分的要点,在本课程中,我们将使用开放数据格式,换句话说,就是公开记录的格式,并且对于任何软件包的创建和使用都没有法律限制或使用费要求。您可能很熟悉其中的许多文件,例如shapefile,KML文件,JPEG等。相反,专有数据格式是由特定的软件供应商创建的,或者没有文档记录,或者不能从头开始合法创建,也不能由任何其他开发人员扩展。Esri文件地理数据库是一种众所周知的专有格式的示例。尽管Esri已发布了用于创建文件地理数据库的API,但是不能扩展或逆向工程底层格式。

一些最广泛使用的开放数据格式实际上是由专有软件供应商设计的,他们经过深思熟虑后决定将其作为开放格式发布。两个例子是Esri shapefile和Adobe PDF。尽管开放数据格式会带来自由和开放源码软件替代品与供应商的功能竞争的风险,但它增加了供应商软件的互操作性,而且,如果广泛采用,还会增强供应商在软件社区中的影响力和可信度。