【问题标题】:Ideal database for geo (map) data地理(地图)数据的理想数据库
【发布时间】:2011-04-20 08:38:08
【问题描述】:

我正在寻找有关存储地图的理想数据库或数据结构的建议。本质上,地图由类似于道路、路径等的“方式”组成。方式包含节点(具有纬度和经度坐标,有时还有高度。)

任何此类数据库或结构:

  1. 应该能够快速(毫秒)定位边界框中的所有节点

  2. 可选地,当大量节点位于边界框中而不是少数节点时,或者如果边界框很大,则不应显着减慢速度

  3. 应该能够找到直接连接的节点:例如连接两种方式的节点

  4. 可以只读

  5. 应该紧凑(避免浪费空间) - 我希望将英国地图放入不到 1 GB 的空间。我有一个卫星导航,它使用 SD 卡上大约 800 MB 的空间来执行此操作。

我最初在考虑用四叉树来存储路径。但是快速实现很棘手,而且它们不适用于单个节点;所有节点都尽可能放在最小的 bbox 中。

(我故意使用与 Open Street Map 相同的术语,因为我打算使用该数据。)

【问题讨论】:

  • 我开始悬赏这个问题。

标签: sql database geolocation mapping openstreetmap


【解决方案1】:

我建议 PostGIS 1.5 使用 geography 类型,因为它适合您的需求,但我唯一关心的是在嵌入式设备上使用类似的东西是内存使用情况。

我使用 Java 中的非 GIS 数据库(火鸟)构建了一些模糊相关的东西,并且性能足以在边界框中检索点(尽管需要花哨的 SQL,而 PostGIS 不是这种情况)。

【讨论】:

    【解决方案2】:

    PostGIS 可能是最好的选择。注意:PostGIS 带有地理扩展的 PostgreSQL。您实际上是安装 postgres,然后运行各种添加地理功能和类型的脚本。

    请参阅OpenStreetMap information about PostGIS。您可以使用 osm2pgsql 将 OpenStreetMap 行星文件/行星提取物加载到 PostGIS 中,这是在运行 Mapnik 渲染器的 OpenStreetMap 瓦片服务器上完成的。不过……

    OpenStreetMap 数据还有一个更原始的数据库模式(称为“节点”和“方式”等的表)这是 main OpenStreetMap 数据库服务器用于存储其地理数据并允许编辑的内容通过 API。这在空间索引等方面并不那么聪明,但又好又简单。您可以通过安装OpenStreetMap API/website ruby on rails code 来创建这种格式的数据库。这是设置database schema(由the rails migrations 定义)的最新版本的最可靠方法。之后,您可以运行osmosis 工具来填充数据库。

    【讨论】:

      【解决方案3】:

      PostGIS 不是唯一支持地理空间数据的数据库,但价格非常好。很难打败“免费”。

      但还有其他免费选项,一些读者可能已经拥有另一个关系数据库系统,并希望利用该专业知识而不必学习 PostGIS。任何支持开放地理联盟规范(OGC 或 OpenGeo)的数据库都足以满足您描述的场景。

      就像摄影界的格言——“最好的相机就是你随身携带的那台”——有时理想的空间数据库就是你已经拥有并知道如何使用的那台。

      以下是我所知道的所有选项的列表:

      空间 RDBMS - 提供免费选项

      • Oracle(带 Spatial 或 Locator)(免费选项:Oracle XE + Locator)
      • MS SQL Server(2008 或更高版本)(免费选项:SQL Server Express)
      • 后地理信息系统

      空间 RDBMS - 没有免费选项

      • DB2(带有空间扩展器)
      • Informix(带有空间刀片)

      不如理想的空间 RDBMS

      • MySQL Spatial(功能集非常有限)

      空间“扩展件”

      • ArcSDE(将其添加到现有的 RDBMS)

      【讨论】:

        【解决方案4】:

        我所知道的地理数据最好的数据库是带有地理扩展的 PostgreSQL,但我不知道速度。我知道 OSM 使用这个,但他们可以访问一个巨大的计算机基础设施,快速。我也知道他们有几个要求可以为他们编写更快的程序的人。

        我会说四叉树是处理地理分区数据的一个非常好的选择,据我所知,您似乎允许正方形变得太小。您可以使边界更柔和(允许一个节点位于四叉树的两个叶子中)并为每个叶子添加最少数量的节点。假设任何叶子都不允许包含少于 64 个节点,并且不超过 1024 个。

        在这里,排序对于速度尤其重要,建议对更有可能首先访问的区域进行排序。假设所有请求的 70% 将在伦敦附近,那么将这些数据放在文件开头以减少搜索时间会是最快的。

        【讨论】:

        • 感谢您的建议,+1。
        • Np,我自己一直在考虑基于 OSM 数据的服务 - 但我目前缺乏托管的可能性和经济性。
        【解决方案5】:

        我不确定空间,但您可能想考虑将任何地理扩展用于通用数据库服务器(如果可能的话)。他们通常提供快速的地理索引,基于边界框(回答 1 和 2)许多地理程序来进行计算(回答 3,intersect(way1,way2))。

        另外,你的问题更适合http://gis.stackexchange.com

        【讨论】:

        • 我认为这更像是一个编程问题,因为实现同样重要。我考虑使用 SQLite3,因为它有一个 R*Tree 扩展,但这太慢了。
        • 嗯,产品部件的推荐会在其他网站上得到更好的服务。算法部分也可能在那里得到很好的服务。您是否尝试过任何其他数据库?
        • 不——我没有。 SQLite3 相当快 - 大约 40 毫秒来获取 100m x 100m 盒子中的所有节点。我不认为大多数数据库会比这更多,所以我正在寻找解决问题的更好方法,例如不同的数据结构或算法。
        • 我认为您应该更详细地描述您的需求,并强调您不是在寻找数据库,而是寻找一种方法。
        • 如果数据库快得多,我仍然愿意使用它。
        猜你喜欢
        • 1970-01-01
        • 2017-10-07
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2016-09-24
        • 2014-06-07
        • 2019-05-11
        • 2010-10-31
        相关资源
        最近更新 更多