【问题标题】:Identifying and relating cities from different sources从不同来源识别和关联城市
【发布时间】:2016-02-13 05:27:16
【问题描述】:

我有不同的供应商,他们通过不同城市向我传递了一个 excel,在每个城市,他们使用一些特殊的代码进行他们的运营和更多对我的业务有用的数据。

问题是我对所有这些城市都一团糟:

  • 我的数据库中有自己的城市,大约有 9000 条记录。
  • 提供者 A 给我他的 excel 或 webservice 以获得大约 6000。
  • 提供商 B 再给我 5000。
  • 提供者 C ...等

我的供应商提供的一些城市已经在我的数据库中,我只需更新我需要的所需数据。

否则,我必须在我的数据库中插入那个新城市。

而且,每次供应商给我这些城市的更新。

嗯,主要问题是我对一个城市的称呼与他们不同,他们也彼此不同...如何知道我是否已经拥有那个城市,或者我必须创建一个新城市一个,因为我们使用不同的名称?

在我看来,我只能手动实现。将他们的城市与矿山进行比较。

当然,工作量太大,我自己做了一个脚本,实现了数据库的levehnstein功能,我可以自动看到比较符合的,一键选择。脚本完成其余的工作(将他们对该城市的特殊操作代码更新为存储在我的数据库中的相应城市)。

即使有了它,我仍然觉得我错过了一些东西。如果这些城市有一个 unicode,这将更容易和自动,但我没有任何代码比我的表标识符更能识别这些城市。我的供应商也是如此,尽管有些用途是向我提供他们提供的城市之间的邮政编码,但不是全部。

有没有比我更好的解决方案?您通常使用的任何通用代码或任何其他方法?

编辑: 嗯,每个城市都属于一个国家。当然,我正在考虑这一点。

在我的城市表中,每个目的地都有一个 ID,然后是每个提供商的操作代码列(我知道,这可以用更多的关系更好地表示),加上国家代码、邮政编码、用于 seo 的 url ...

尊重 MagnusL 提到的解决方案,创建同义词表,为什么我需要存储同义词?关于你提到的 levehnstein 和人类互动的脚本,这正是我目前正在做的:

提供者和我的目的地表提供的每条记录。给定一个供应商城市记录,我将显示我的表格中更重合的那些。

但在此之前,我会自动链接所有邮政编码和国家/地区重合的人。

为每个城市更新我的提供商特殊操作代码需要做很多工作。我只是很好奇人们是如何处理这个问题的,我相信很多开发者在某些时候不得不面对这个问题。

【问题讨论】:

  • 有多少个提供者,他们的城市名称总是相同还是没有规则?例如,“Chicago”的一个提供者是否总是提供“CHICAGO”或者它可以是“chicago”或类似的东西?我认为您可以创建一些内部“AI”,通过将信息从->映射到每个提供者来及时学习。
  • 所有城市都来自同一个国家吗?城市名称的差异是由于不同的拼写、拼写错误还是不同的语言?
  • @FrancisEytanDortort 不,在世界各地。是的,不同的拼写、拼写错误甚至是语言。
  • @Vladan 关于“AI”的说法听起来不错,但恐怕对我的目的来说太过分了。我什至不知道从哪里开始。
  • 目前我将使用邮政编码,以便为尽可能多的城市映射操作代码,并手动完成其余部分(借助 levehnstein 算法)。

标签: analysis identification


【解决方案1】:

如果正确匹配城市很重要,我猜您的流程中必须有一些手动步骤。如果您包含较小城镇的名称,您总有一天会遇到相同的名称实际上可能是两个不同国家的两个不同地方。 (在 Google 地图上试试慕尼黑,您会在德国和北达科他州得到一个。)

有点复杂,但我想未来的证明,工作流程是在主数据表中使用 id 号代替城市名称。然后设置一个位置表,将这些 ID 号作为主键,您喜欢的城市名称,然后是国家代码、邮政编码、WGS84 坐标、大陆名称等所需的尽可能多的元数据列。为城市名称同义词添加另一个表,仅包含 id 编号和名称(id 列上没有 UNIQUE 约束)。

让您的导入脚本在尽可能多的元数据(可能来自不同提供者的不同元数据)的帮助下尝试匹配城市,以及您提到的 Levehnstein 算法,并让它足够聪明以要求人机交互在没有一个或多个城市匹配的情况下。它当然可以向您显示最接近的猜测,因此您可以选择正确的猜测并将其存储在同义词表中。

(是的,要实现这一目标需要大量编码。您是否觉得值得,取决于您进行这些更新的频率。)

提示:维基百科有关于城市名称不同的文章,即https://en.wikipedia.org/wiki/List_of_names_of_European_cities_in_different_languages

【讨论】:

  • 一开始我不理解你,一旦链接到我的城市,存储他们的元数据可能是个好主意。所以我可以有更多与我的城市相关的不同拉链(有时提供的拉链不同,因为它们属于同一个城市但区域略有不同,所以它们在我的第一次尝试中不匹配)
【解决方案2】:

如果您使用额外的表格进行名称翻译怎么办? IE,该表将有 2 列:A 列是您使用的名称,B 列是提供者使用的名称。您可能需要手动调整此表,如下所示:

Bruxelles:Brussels
Bruxelles:Brussel
Bruxelles:Bruxelles

在导入时,您将使用城市名称

select A where B = Brussels

在您的聚合数据库中,名称将保持一致。

【讨论】:

  • 这并没有为我节省任何工作,我仍然需要手动比较它们来创建翻译表
  • 手动比较听起来确实是一项巨大的工作,我宁愿考虑合并现有列表,具体取决于您需要的城市和语言。我找到了几个这样的城市列表,但什么都没有
  • 抱歉,输入之前的编辑...手动比较听起来确实是一项巨大的工作,我宁愿考虑合并现有列表...如果以欧洲为例,您可以轻松创建一个脚本解析 26 页(en.wikipedia.org/wiki/… 直到 Z)以生成该表。
猜你喜欢
  • 1970-01-01
  • 2011-10-27
  • 2021-06-28
  • 1970-01-01
  • 1970-01-01
  • 2021-09-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多