Question

是否有开放的数据格式来表示道路，地方，地下，国家，建筑等GIS数据。

我希望该格式可以定义地址组件的地址结构和名称我需要的是响应反向地理编码请求而返回的数据格式我在互联网上寻找它，但似乎每个地理编码提供商都定义了自己的格式。

我应该设计自己的格式吗？

我的问题是否有意义？（我是GIS的新手）。如果我没有说清楚，我不会寻找GeoJSON，GML或WKT等数据格式，因为它们定义几何并且不定义任何地址结构。

UPD 即可。我正在尝试不同的地理编码服务，并尝试将它们隔离到单独的模块中。我需要为所有这些提供一个通用接口，我不想再构成一个数据格式（因为一方面我不完全理解域，另一方面，字段本身似乎很好地研究）。该模块的职责是采取部分地址（或坐标），如“96，Dubininskaya，莫斯科”，并返回包含门牌号码（96），街道名称（Dubininskaya），sublocality（Danilovsky rn），城市（莫斯科），行政管理的数据结构地区（Moskovskaya oblast），国家（俄罗斯）。问题是，在不同的国家，可能会有更多/更少的划分（更多/更少的地址组件），我需要在各个国家统一这些组件。

Answer 1

不幸的是，没有。

为什么你可能会问

因为不同的国家和国家在存储地址方面有着截然不同的格式和要求。

例如，在英国，定义邮政编码有一套非常复杂的规则，其中美国的邮政编码是4位数字，前缀是简单的2个字母的州代码。

然后你必须考虑问题究竟是什么构成一个地址？这种差异不仅在国与国之间，而且有时在同一领域内有很大差异。

例如:(在英国）

Smith and Sons Butchers
10 High street
Some town

Mr smith
10 High street
Some town

The Occupier
10 High Street
Some Town

Smith and Sons Butchers
High Street
Some Town

英国是否所有有效地址，并且在所有情况下，帖子都会到达正确的目的地，但GPS可能会遇到问题。

可能会设置一个GPS数据库，以便每个建筑物都是几何方形，ID是门牌号。

那会让我们能够确切地说出数字10的位置，这意味着最后一次查找会立即失败。

可以按业务名称对情节进行索引，直到您开始使用人名或通用标题为止。

有很多变化，根本无法创建一个统一格式，可以包含允许地球上的任何应用程序正确格式化任何地理编码地址所需的每个可能规则。

那么我们如何解决这个问题？

简单，缩小范围。

仅处理您需要使用的一组特定实体。
仅保留描述您需要描述的内容所需的信息（此处始终记得YAGNI *）
使用标准数据传输格式（如JSON，XML和CSV），这将增加您对无法控制的代码执行更少工作以使其读取数据输出的机会

（* YAGNI =你不需要它）

现在，深入挖掘：

说到实际的GIS数据，有很多标准格式文件，最常见的3个是：

Esri形状文件（* .shp）
Keyhole mark up语言（* .kml）
逗号分隔值（* .csv）

免费和付费的所有主要GIS套餐都可以使用这三种文件类型中的任何一种，还有更多。

Shape形状文件是目前最常见的形状文件，几乎我在IT中遇到的地理空间数据的每一点都存在于形状文件中，但我不建议存储数据在它们中进行处理时，它们是一种非常复杂的格式，通常很慢且顺序访问。

如果要在其他系统中使用几何文件，则不会出错。

他们还有额外的好处，你可以将属性附加到每个数据项，如地址详细信息，名称等。

问题是，没有标准可以称为属性列，或者您将包括什么，并且可能更严重的是，列名称限制为大写，并且长度限制为32个字符。

Kml文件是另一个非常普遍认可的文件，并且因为基于XML并且由Google使用，您可以在其中包含大量额外数据，从技术上讲，它们可以自我描述读取它的机器。

不幸的是，即使只是为了一些简单的几何形状，文件大小也非常庞大，这种权衡确实意味着它们在地球上的任何编程语言中都很容易处理。

这将我们带到了卑微的CSV。

自从时间开始以来，数据传输的主要停留时间（不仅仅是地理空间）。

如果您可以将数据放在数据库表格或电子表格中，则可以将其放在CSV文件中。

同样，除了如何引用或不引用列以及分离点是什么之外，没有标准，但读者必须提前知道每列代表什么。

此外，没有“预先制作”的地理存储元素（实际上根本没有数据类型）所以您的阅读应用程序也需要提前知道列数据类型的含义，以便它可以解析适当的。

然而，从好的方面来说，一切都可以阅读它们，是否可以理解它们是一个不同的故事。

表示GIS数据的格式

1 个答案: