在数据库中存储地理地址/位置的通用方法是什么？[关闭]

25

什么是地理地址/位置的正确格式，最适合地球上的任何地址？目前，我有：

国家
市
街
数
文本数据（为简单起见）
压缩
纬度/经度

但是我相信我可以改善它：一个国家或地区或地区之类的东西。或在新加坡或香港没有区域/地区/州。

可能没有街道，但道路，林荫大道或其他东西。许多建筑物可能是复合的。可能有地板。房间号。等等....

— Xwaro
source

11

您需要解释什么应用程序，以及谁提供该地址。例如，在大多数网络商业商店/网站上，我不会键入任何“纬度/经度”，而这对洲际弹道导弹（或GPS）必不可少。同样，海拔（以及时间和日期）在某些情况下也很重要（例如，某些船舶在海上，或某些珠穆朗玛峰上的旅行者）。因此，我不确定是否有任何普遍的答案。

— 巴西尔·斯塔林凯维奇

61

值得一读：mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses

— High Performance Mark

6

@BasileStarynkevitch：我认为“对于什么应用程序”并不是那么重要，而对于“什么用例”则不那么重要。例如，如果用例是要确保全球邮政服务可以传递邮件，我想这个问题可以用一种明智的方式回答。但是，对于此用例，不需要“ lat / lng”。

— 布朗

34

我认为地址的通用格式是单个字符串。

— Erik Eidt

12

您提出的问题非常痛苦，以至于有些公司开发了通用的解决方法，例如：what3words.com（归结为将位置坐标映射到三个单词）。他们声称，“有了what3words，现在每个人和每个地方都有一个地址。”

— 罗曼·苏西

51

Google开发了一个库，可帮助验证世界上每个国家/地区的邮政地址，您可以使用该库来设计用于存储此数据的架构。

在目标客户群的地址中查找最常见的必填字段，以开始使用，并在确定具有不同要求的其他国家/地区时，可以继续调整架构。

— 米奇达夫
source

5

+1用于研究现有解决方案。AddressAndroid SDK中的类可能是另一个不错的起点。

— 凯文·克鲁姆维德

4

快速浏览Google图书馆显示它建立在oasis-open.org/committees/ciq/download.shtml

— grahamj42'9

@ grahamj42，大声笑，该页面是如此残破。

— Nakilon

41

在数据库中存储地理地址/位置的通用方法是：

[Address] nvarchar(max) not null

这需要最少的编程代码（从而减少了维护成本），并且与任何地址完全兼容。但是，它具有三个大问题：

缺少数据验证意味着该字段可用于存储地址以外的目的。目的之一是DOS攻击，旨在通过在地址字段中输入2 GB数据来填充数据库的空间。
以这种方式存储的数据使得无法出于商业智能和数据挖掘目的对其进行处理。例如，有多少用户来自印度？没有容易分辨的方法，因为这些地址不会被标准化。
用户可能会错误地输入不完整或明显错误的地址。

为了减轻第一个问题，请将字段限制在您认为合理的范围内。就个人而言，我将以1000个字符开头，然后在获得足够大的数据集之后根据第一个用户输入的地址长度来减少它。

为了缓解其他两个问题，您可以使用第三方API来解析地址，并向您提供包含国家，城市，邮政编码等数据。如果可能的话，API应该能够在以下位置显示地址将地图返回给用户，以减少用户输入不完整或错误地址的风险：大多数用户知道他们的住所，并且看到地图上的其他位置会立即为他们提供线索，他们应该检查输入内容。

请注意，无论您使用什么API，它都不是完美的。它将找到大多数地址，但不是全部。这意味着，如果API告知该地址不存在，但用户坚持认为该地址存在，则即使该用户输入了错误，也应该事先信任该用户。

这也意味着您仍然应该将原始用户的输入与API的结果并排存储。这意味着架构变为：

[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null

— 阿森尼·莫尔琴科（Arseni Mourzenko）
source

注意：如果有必要，至少可以单独存储国家（地区）。例如，可以从地址字段中自动推导出该地址，并可以选择用户进行更改。

— Matthieu M.

“使用API”只是意味着其他人拥有了所有国家/地区的官方格式。没有理由您不能自己做

— Ewan

@Ewan除了时间，金钱，语言和其他障碍外，没有其他原因。

— 安德鲁说莫妮卡（Monica）恢复职权

可以，但是我们是否提供有关如何做事情或比较其他为您做事情的人的价格的答案？

— 伊万（Ewan）

@Ewan：问题是关于地址的存储格式。API并没有规定这种格式：我的答案是要表明，只要您拥有一个纯文本字段和一个XML / JSON /任何可解析数据的字段，就可以在任何地方存储和统计处理地址在世界上。

— Arseni Mourzenko

37

没有一个。

每个国家/地区都有不同的地址格式。如果幸运的话，它们完全有格式！

显然，纬度/经度会给您一个地球仪的信息，但对于识别单个房屋并没有真正的用处。例如，只考虑一个塔楼。

最好的选择是检查每个国家/地区的邮政服务的正式格式。这对于您的后端数据库可能非常有用。但是您可能必须为最终用户简化它，因为它包含的字段比大多数人习惯的更多。

以英国为例，其中包括“双重依赖的地方”之类的东西，但是没人问你问这意味着什么。

— 伊万
source

3

什么是通用方式 .....

— Xwaro

40

@Xwaro他们只是说，没有一个。

— Zymus

6

我猜Xwaro的意思是我要假设地球上的地址。

— 伊万

3

这是印刷地址格式的官方来源：万国邮政联盟

— grahamj42'9

3

有趣。我认为这是相关的页面：upu.int/en/activities/addressing/s42-standard / ...您可以看到A：只有少数几个国家，而B：从s42到国家地址格式的映射不是1比1

— Ewan

21

唯一的通用格式是具有单个文本字段，该文本字段可以包含多行文本。这将允许在地球上任何可能的地址。

— 雅克
source

2

太好了，现在每个人都可以用不同的，不兼容的方式描述相同的地址。我想这个问题不是关于标准的，因此从技术上来说这是一个正确的答案。

— 迈克尔（Michael）

@迈克尔：地址是在世界各地不同的和不兼容。目前是没有标准模板。具有多行字段允许用户实际写入正确的地址。

— JacquesB

@Michael分开的字段经常迫使我截断/缩写一个字段或另一个字段，这也导致表示不一致。（通常仍然可以正常工作，邮政服务对此很有经验）。

— 绿巨人

确认：en.wikipedia.org/wiki/Address_

— 地理

只是一个有趣的花絮，从技术上讲这不是事实。在某些国家/地区，地址的一部分被绘制为图片。

— KayakinKoder

9

我一直在开发可在许多国家/地区使用的软件解决方案。我们首先从较大的实体开始解决此问题，即国家/地区的字段最小到最小或最小。到目前为止，我们在所有尝试过的国家/地区都可以使用它。我们还拥有一个智能的防重复系统，并且由于用户非常“有创造力”，因此合并了那些以某种方式进入系统的用户。在管理部分，我们有每个国家/地区设置的地址字段顺序。例如，日本的邮政编码是第一位的，英国/美国是最后一位。

通常，我们使用：

国家
邮政/邮编
州/省/州/县
城市/镇/村
街/路/街区
建筑物名称/编号
具体/自定义信息

输入并保存后，可以显示共轭版本，而不必填写任何字段。

就像我说的那样，这对于我们拥有软件的所有国家/地区都适用，并且是自1989年以来开发的结果。

希望这可以以某种方式有所帮助或至少提供另一种见解。

— 比尔森西
source

您如何在数据库中为“州/省/州/县”命名列？

— Xwaro

6

@Xwaro没关系，无论您以什么方式感到开发人员都会为之困惑，都可以命名。这是因为该名称是软件的内部名称，用户永远不会看到它。地址永远不会与字段名称一起显示。也就是说，您永远不会看到No 10 Street Downing Street, City Westminster, State London, Country UK。相反，您会看到10 Downing Street, Westminster, London, UK

— slebetman

@slebetman问题是：如何在数据库中为“州/省/州/县”命名列？不是“您如何建议我在我的数据库中为“州/省/州/县”命名列？”

— Dari

@Dari没关系，我以我认为开发人员最不会感到困惑的任何词来命名。这是因为该名称是我软件的内部名称，用户永远看不到。因此，这取决于我的团队习惯了什么。

— slebetman '10

@slebetman-您叫什么名字？

— Dari

0

如前所述，最通用（但不可行，可能最不有用）是单个大Unicode字段。

您可以将国家/地区与其他地址分开，并将其存储为ISO国家/地区代码。它将使国家正常化，并在验证地址的其余部分方面提供一些实用程序。

您也可以将邮政编码（也称为邮政编码）与地址的其余部分分开。这在验证地址的其余部分方面也将具有一定的实用性，并且可能有助于（尽管不精确）地理位置。例如：在加拿大，您可以唯一地标识任何地址，仅指定邮政编码和街道号（又称门牌号）；并非在所有国家都如此。

由于每个国家/地区制定地址的方式各不相同，将州/省/城市专用于田地的问题开始变得越来越多。我已经设置了具有此类字段的地址表，因为最初的受众集中在北美，因为知道国际受众会遇到问题。在大多数情况下，它们可能是“鞋拔子”，但这是尴尬且容易失败的折衷方案-绝对不是通用的。

— Zenilogix
source

0

与米切达夫的答案相反，我建议不要使用Google的库。我使用非正统的寻址方案在存储库中搜索了多个国际场所，以期找到单元测试数据，但令人担忧的是，整个存储库中的命中率为零。

我认为您最好的选择是将地址视为自由格式的多行文本。令人吃惊的是，您可能无法验证所有地址，但是某些寻址格式确实很奇怪，并且可能是无法预料的，最终，填写正确地址的责任在于用户，在大多数应用中，用户承担填写地址的任何负面后果无效地址。

您也许可以使用验证器来提供警告，但仅此而已。但是请不要拒绝未经验证的地址，否则您可能会失去一些客户。这就引出了一个问题，即如何以某种方式将警告传达给用户，从而可以传达以下信息：如果用户居住在地址格式怪异的区域，则可以安全地忽略警告...

— 匿名
source

-1

正如您所说的，地球上的任何地址都只有经纬度或纬度。

https://what3words.com

这3个字是一种算法（因此不能将数据库嵌入任何东西中）可以定义地球上任何地方的3x3米斑块。

汤加（Tonga）和其他一些州已将其用作邮政编码系统，但它不会取代它，因为它非常酷，而且构造和考虑都很好。

— 备注利马
source