为什么 libpostal/pypostal `expand_address` 输出一个数组？

Question

我正在浏览非常优秀的 libpostal (pypostal) 库，不幸的是，它没有我能找到的文档。

他们的例子：

>>> expand_address('Quatre vingt douze Ave des Champs-Élysées')
[u'92 avenue des champs-elysees', u'92 avenue des champs elysees']

输出由 2 个相同字符串组成的数组。这个选择的效用/目的是什么（即我如何使用它？）

谢谢

Answer 1

对于扩展地址和将地址解析为城市、州、邮政编码等，它的作用相同。

第一个元素始终是您可以使用的最有可能的正确答案。

Answer 2

首先，应该非常清楚地说明

expand_address()

并不是为了对地址特别智能。它的目标和目的是创建可索引/可搜索的地址。¹它使用不利用 NLP 的更简单算法来“标准化”它们。²具体原因，我不确定。可能有性能方面的考虑。

遗憾的是，正如您所说，文档很少。我目前正在尝试使用版本

v1.1-alpha

，但我的来源可能与旧版本有关，因此里程可能会有所不同。

---

这里的其他答案充其量是错误的或没有受过教育。

我将一一解决此处答案中发现的不准确之处。

对于扩展地址和将地址解析为城市、州、邮政编码等，它的作用相同。

我不明白这里的“相同”是什么，但是

parse_address()

返回一个元组列表，表示其组成部分中的 single 地址。

expand_address()

返回包含完整地址的字符串列表。我想返回一个列表意味着它们是“相同的”，哈哈。

第一个元素[从expand_address()返回]始终是您可以使用的最有可能的正确答案。

根本不是真的。结果不以任何方式排名或排序。³

根据我收集的信息，其主要规范化机制之一是语言检测。语言概率是“评分”，我必须假设包含语言的结果有一些阈值，但它们不是“有序”的。结果也不包含分数。有趣的是，如果 expand_address() 的描述属于您的用例，可以通过向其传递一种语言来改进它。4

语言和区域不是 1:1，但这就是我们给出的，并且这可能会有所帮助。 ^{一个例子是“4123 Griffin Ave Los Angeles CA”，其中明显包含西班牙语单词，因此语言识别会为该地址的西班牙语记录一些相对较高的分数。对于美国人来说，CA 是州的缩写可能是显而易见的，但在西班牙语中，“街道”这个词是“calle”，所以它也必须考虑到这种可能性。我们可以将 language=['en']} 传递给

expand_address()

，这将排除字符串“CA”的街道后缀，例如“calle”。再次强调，使用语言与区域并不是 1:1，因此这可能并不总是按预期工作。

基本上，它在地址扩展中将 ST 扩展为街道和其他短词。

有点。从一般意义上讲，这就是“扩展”在这种情况下的含义。它经常这样做它的扩展，但它也可以返回看起来像缩写的东西，例如。

ca

可能是

california

或

canada

，但也可能不是。扩展取决于

address_components

设置，这些设置决定哪些部分扩展或不扩展。例如，从扩展中排除 ADDRESS_STREET 不会将

st

转换为

street

。有些默认值会影响展开的内容。5 ^{这里的总结是，}expand_address()

是为了在某种意义上以更机器可读的格式生成各种标准化或规范化的地址。

---

将人工输入的地址转换为这种标准化格式意味着可以快速、一致、可靠地执行诸如在数据库中的特定地址查找企业之类的操作。

它没有考虑位置。

说实话，我正在努力想象它的良好用途。

感觉

---

parse_address()

可以完成我需要的前半部分，然后

expand_address()

可以完成后半部分，但由于它不处理类似于

parse_address()

结果的结构，并且它没有考虑位置就像

parse_address()

一样，它不能生成一致的东西。我仍然发现自己需要使用像

Google 地址验证

这样的东西来取回“标准化”的东西。