2011-04-11 114 views
0

这里有一个问题,让我觉醒了几天。我到目前为止唯一得出的结论是,红牛通常不会帮助编码人员。通过匹配邮政编码字符串找到最接近其他英国邮政编码的英国邮政编码字符串

我在我的应用程序中有一个场景,我有几个工作(1到50)。该工作有一个地址,我有以下地址属性:邮政编码,纬度和经度。

我也有一张工作人员的表,他们也有地址。虽然职位或工作人员是通过屏幕创建的,但我使用Google Map查询来确保提供的邮政编码有效,并且位于英国,因此所有地址都经过验证。

我正在使用调度程序控件在y轴上显示一些工作人员,并在x轴上显示时间轴。每个作业都有一个日期,只能在作业日期的调度器上垂直移动。用户选择多个作业,并将其显示在靠近调度程序的篮子中。用户然后可以拖拽工作对工人。所有这些都是手动的,所以它可以工作

我的任务是自动执行此操作,以便用户除了验证和分配作业之外不会做太多工作。因此,我必须使这个过程自动化。

每个工人都有一个名为WillingMaximumDistanceTravel的属性,它是一个表示英里数的整数,工人愿意前往工作。

现在,这里头痛:我有超过1500名工人。我有一个实用功能,使用Newtonsoft的Json Convert来反序列化来自Google Maps的响应流。我需要喂它邮政编码A和B.

我还计划向DB引入一个新表,以存储距离查找作为邮政编码A,邮政编码B和距离。因此,如果我发现自己再次比较相同的邮政编码,我只需从数据库中缓慢地检索结果,最终,我不再需要打扰Google,因为此表格非常全面。

我不能使用简单Haversine公式,因为Crow-Fly路径在这里不是我的要求。其中的痛苦是需要花费很多时间来计算。有些工作人员可以行驶10英里以上,有些工作人员可以从15人到80人不等。我必须从列表中选择第一份工作,并与每个适用的系统工作人员一起运行!我想知道英国邮政编码有一个模式。如果我们对英国邮政编码列表进行排序,我们可以从字母数字模式粗略估计,我们将在哪里打100英里标记,200英里标记等等?

如果有人对代码感兴趣,请放下一行,然后粘贴它。

+0

好的,我有这个SQL查询。为了搜索closeby,我对Lat和Lon加上和减去0.100000: – DoomerDGR8 2011-04-12 13:48:57

回答

1

(我为谷歌工作,但我不能代表谷歌的说,我没有做的地图API。)

我怀疑这是不是使用谷歌地图的大好形势API,仅仅是因为你在推送这么多的数据。即使你可以在directions limits下这样做,你也不想提出这么多要求。

当我在之前的工作中处理类似问题时,我们购买了本地托管的地图API - 但即便如此,这类工作的速度还不够快。我们最终预先计算了每个邮编“区域”质心的时间(可能是它的错误名称,但邮编的第一部分后跟其余的第一个数字,例如“SW1W 9”代表“SW1W 9TQ “)到所有其他区域,将结果存储在一个巨大的表格中。我认为我们只对100英里以内或类似的邮政编码做过,以减少预处理量。

即使那么,一个简单的数据库并不像我们想要的那么快 - 所以我们将结果存储在一个巨大的文件中,每个源/目标对使用一个字节。 (我们有源邮政编码和目标邮政编码的固定顺序,所以我们并不需要指定的。)在这一点上,计算行程时间包括了:

  • 制定邮政编码区域(子串的工作)
  • 找到每个邮政编码区域的索引序列
  • 检查中,如果我们要加载的文件的一部分(我们懒加载的启动速度)
  • 负载行如果有必要,只是访问它,否则

这些字节是以精确度的滑动比例表示的,因此在前60分钟时它是以每分钟为基础的,那么每个额外值意味着额外的2分钟,然后是5等等(这些不是确切的值,但是这是类似的东西。)

当您制定出“合适的候选人”时,您可以通过现场API或Google Maps API为您的准确邮政编码提供更准确的方向,当然。

+0

我承担了这个顾虑。这就是为什么我想在进行任何Google通话之前进行研发。我想我会更多地抓我的头。 – DoomerDGR8 2011-04-12 10:03:26

1

你想寻找一个空间索引或空间填充曲线。空间索引将2d问题减少为1d问题,并将递归细分为更小的贴图,但它基本上是对贴图的重新排序。您可以使用4个字符以索引或字符串细分曲面。后者对你来说可能很有用,因为它可以让你查询隐藏在数据库引擎中的所有字符串操作的字符串。你想要找Nick的空间索引四叉树希尔伯特曲线博客。

+0

研究推荐的算法。谢谢。 – DoomerDGR8 2011-04-12 10:00:06

+0

感谢您的投票。我已经在phpclasses.org(hilbert-curve)中为PHP编写了一个四叉树实现。它为每个邮政编码使用一个字符串索引。 – Bytemain 2011-04-12 14:56:47