不，不幸的是没有。
为什么你可能会问
因为不同的国家和国家对存储地址的格式和要求有很大不同。
例如，在英国，定义邮政编码有一套相当复杂的规则，而在美国，邮政编码是 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 文件中。
同样，没有标准，除了如何引用或可能不引用列以及分隔点是什么，但读者必须提前知道每列代表什么。
也没有“预制”地理存储元素（实际上根本没有数据类型），因此您的阅读应用程序还需要提前知道列数据类型的含义，以便它可以适当地解析它们。
然而，从好的方面来说，一切都可以阅读它们，他们是否能理解它们是另一回事。