Найдите почтовые индексы Великобритании, наиболее близкие к другим почтовым кодам Великобритании, сопоставив строку почтового индекса

Question

Вот вопрос, который заставляет меня бодрствовать уже несколько дней.Пока я пришел к единственному выводу, что Red Bull обычно не помогает программистам.

В моем приложении есть сценарий, где у меня есть пара заданий (от 1 до 50).У задания есть адрес, и у меня есть следующие свойства адреса: почтовый индекс, широта и долгота.

У меня есть таблица рабочих, и у них тоже есть адреса.В то время как задания или работники создаются с помощью экранов, я использую запросы Google Map, чтобы убедиться, что предоставленный почтовый индекс действителен и находится в Великобритании, поэтому все адреса проверены.

Я использую элемент управления планировщика для отображения некоторых работниковпо оси Y и временной шкале по оси X.Каждое задание имеет дату и может перемещаться в планировщике только вертикально на дату задания.Пользователь выбирает несколько заданий, и они отображаются в корзине рядом с планировщиком.Пользователь может затем перетащить работу против рабочих.Все это вручную, поэтому оно работает.

Моя задача состоит в том, чтобы автоматизировать это, чтобы пользователь ничего не делал, кроме как просто проверяя и распределяя задания.Поэтому я должен автоматизировать процесс.

У каждого работника есть свойство WillingMaximumDistanceTravel, которое представляет собой целое число, представляющее мили, и работник готов отправиться на работу.

Теперь вот головная боль: У меня более 1500 рабочих.У меня есть служебная функция, которая использует Json Convert от Newtonsoft для десериализации потока ответа из Google Maps.Мне нужно скормить его Почтовый индекс A и B.

Я также планирую представить новую таблицу в DB для хранения результатов поиска в виде почтового индекса A, почтового индекса B и расстояния.Поэтому, если я обнаружу, что снова сравниваю те же самые почтовые индексы, я просто и медленно и постепенно получу результат из БД, и мне больше не потребуется беспокоить Google, поскольку эта таблица будет очень полной.

Я не могуиспользуйте простую формулу Haversine, так как путь Crow-fly здесь не мой.Беда в том, что на это уходит много времени.Некоторые работники могут проехать более 10 миль, а некоторые - от 15 до 80. Мне нужно взять первую работу из списка и запустить ее с каждым соответствующим работником системы!Мне было интересно, что почтовый индекс Великобритании имеет образец для этого.Если мы отсортируем список британских почтовых индексов, можем ли мы сделать приблизительную оценку по алфавитно-цифровому шаблону, где мы достигнем отметки 100 миль, отметки 200 миль и т. Д.?

Если кого-то интересуеткод, пожалуйста, напишите строку, и я вставлю его.

Answer 1

Вы хотите искать пространственный индекс или кривую заполнения пространства. Пространственный индекс сводит 2-мерную проблему к 1-мерной и рекурсивно разделяет поверхность на более мелкие фрагменты, но в основном это переупорядочение фрагментов. Поверхность можно разделить либо индексом, либо строкой, используя 4 символа. Последний может быть полезен для вас, потому что он позволяет вам запрашивать строку со всеми строковыми операциями, скрытыми в ядре базы данных. Вы хотите найти блог Ника по пространственному индексу quadtree hilbert-curve.

Answer 2

(Я работаю на Google, но я не говорю от имени Google. Я не имею ничего общего с API карт.)

Я подозреваю, что это не очень хорошая ситуация для использования GoogleAPI Карт, просто потому, что вы проталкиваете так много данных.Вы действительно не хотите делать так много запросов, даже если бы вы могли делать это в пределах указаний .

Когда я работал над чем-то похожим на предыдущей работе, мы купили локальноAPI для размещения карт - но даже этого было недостаточно для такой работы.В итоге мы предварительно вычислили время, необходимое для прохождения от центра тяжести каждой «области» почтового индекса (возможно, неправильное название для нее, но за первой частью почтового индекса следует первая цифра оставшейся части, например, «SW1W 9» для «SW1W 9TQ»).«) в любую другую область, сохраняя результат в гигантском столе.Я думаю, что мы сделали это только для почтовых индексов, которые находились в пределах 100 миль или чего-то подобного, чтобы сократить объем предварительной обработки.

Даже тогда , простая БД не была настолько быстройкак мы и хотели - мы сохранили результаты в гигантском файле с одним байтом на пару источник / назначение.(У нас была фиксированная последовательность исходных и целевых почтовых индексов, поэтому нам не нужно было указывать их.) В этот момент вычисление времени в пути состояло из:

• Обработка областей почтового индекса (подстрокаработа)
• Найти индекс каждой области почтового индекса в последовательности
• Проверить, загрузили ли мы эту часть файла (мы загружаемся лениво для скорости запуска)
• Загрузитьстрока в случае необходимости и просто получить к ней доступ в противном случае

Байты были по скользящей шкале точности, поэтому в течение первых 60 минут это было поминутно, тогда каждое дополнительное значение означалодополнительные 2 минуты, затем 5 и т. д. (Это не точные значения, но это было что-то в этом роде.)

Когда вы выработали «хороших кандидатов», вы можете попросить API на месте илиAPI Карт Google для более точных указаний для ваших точных почтовых индексов, конечно.