不，遗憾的是没有。
你为什么会问
因为不同的国家和国家存储地址的格式和要求大不相同。
例如，在英国，定义邮政编码有一套相当复杂的规则，而在美国，邮政编码是 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 标记语言 (*.kml)
- 逗号分隔值 (*.csv)
所有免费和付费的主要 GIS 软件包都可以使用这 3 种文件类型中的任何一种，等等。
到目前为止，形状文件是您会遇到的最常见的文件，我在 IT 工作中遇到的几乎所有地理空间数据都保存在形状文件中，但我不建议您存储您的数据在它们中进行处理时，它们是一种相当复杂的格式，访问起来通常很慢且顺序。
但是，如果您的几何文件要在其他系统中使用，您就不会出错。
它们还有额外的好处，您可以将属性附加到每个数据项，例如地址详细信息、姓名等。
问题是，对于属性列的名称或包含的内容没有标准，而且可能更严重的是，列名限制为大写，长度限制为 32 个字符。
Kml 文件是另一个广为人知的文件，因为 Google 使用基于 XML 的文件，所以您可以在其中包含大量额外数据，从技术上讲，这些数据对机器读取它是自我描述的。
不幸的是，即使对于少数几个简单的几何图形，文件大小也可能非常庞大，但这种权衡确实意味着它们很容易用地球上几乎任何编程语言处理。
这将我们带到了不起眼的 CSV。
从一开始就是数据传输（不仅仅是地理空间）的主要内容。
如果您可以将数据放入数据库表或电子表格中，那么您可以将其放入 CSV 文件中。
同样，除了如何引用或不引用列以及分隔点是什么之外，没有标准，但读者必须提前知道每列代表什么。
也没有“预制”地理存储元素（实际上根本没有数据类型），因此您的阅读应用程序还需要提前知道列数据类型的含义，以便它可以解析适当的。
然而，从好的方面来说，一切都可以阅读它们，他们是否能理解它们是另一回事。