Сравнение Lat, длинных координат

Я сделал это однажды для веб-сайта. Т.е. найдите дилера в 50 милях Вашего почтового индекса. Я использовал большое круговое вычисление для нахождения координат, которые были в 50 милях к северу, в 50 милях к востоку, в 50 милях к югу, и в 50 милях к западу. Это давало мне минуту и макс. lat и минута и макс. долго. Оттуда затем я сделал запрос базы данных:

select *
    from dealers
    where latitude  >= minlat
      and latitude  <= maxlat
      and longitude >= minlong
      and longitude <= maxlong

Так как некоторые из тех результатов все еще будут на расстоянии больше чем в 50 миль, затем я использовал большую круговую формулу еще раз в том маленьком списке координат. Затем я распечатал список наряду с расстоянием от цели.

Конечно, если Вы хотели искать точки около демаркационной линии времени или полюсов, чем это не будет работать. Но это работает отлично для поисков в Северной Америке!

Общее понятие, которое Вы описываете, является ближайшим соседним поиском, и существует целое огромное количество методов, которые имеют дело с решением этих типов запросов, или точно или приблизительно. Основная идея состоит в том, чтобы использовать пространственный метод разделения для сокращения сложности от O (n) на запрос к (приблизительно) O (зарегистрируйте n) на запрос.

KD-деревья и варианты KD-деревьев, кажется, работают очень хорошо, но деревья квадрантов будут также работать. Качество этих поисков зависит от того, статичен ли Ваш набор 15 000 точек данных (Вы не добавляете много точек данных ко множеству элементарных исходов). Смонтируйтесь и работа Arya над библиотекой Approximate Nearest Neighbour и проста в использовании, и поймите, даже без хорошего основания в математике. Это также дает Вам некоторую гибкость в типах и допусках Ваших запросов.

Это скорее зависит, сколько раз Вы хотите сделать это, и какие ресурсы доступны - если Вы делаете тест однажды, затем O (зарегистрируйте N), методы хороши. Если бы Вы делаете, это тысячу раз на сервере, создавая растровую справочную таблицу было бы быстрее, или предоставление результата непосредственно или как первая стадия. 2 ГБ битового массива могут отобразить целый мир lat-lon на значение на 32 бита на уровне пикселей на 0,011 градусов (1.2 км в экваторе) и должны вписаться в память. Если Вы только делаете единственную страну или можете исключить полюса, у Вас могут быть меньшая карта или более высокое разрешение. Для 15 000 точек у Вас, вероятно, есть значительно уменьшенная карта - я сначала оценил ее как первый шаг к выполнению lat-lon к поискам почтового индекса, которому нужно более высокое разрешение. В зависимости от требований Вы используете отображенное значение для указания на результат непосредственно, или к короткому списку кандидатов (который позволил бы меньшую карту, но требует большей последующей обработки - Вы не находитесь в O (1) территория поиска больше).

На основе Ваших разъяснений я использовал бы геометрическую структуру данных, такую как KD-дерево или R-дерево. MySQL имеет ПРОСТРАНСТВЕННЫЙ тип данных, который делает это. Другие языки/платформы/базы данных имеют библиотеки для поддержки этого. В основном такая структура данных встраивает точки в дерево прямоугольников и ищет дерево с помощью радиуса. Это должно быть достаточно быстро, и я верю, более просто, чем создание Диаграммы Вороного. Я предполагаю, что существует некоторый порог, выше которого Вы предпочли бы добавленную производительность Диаграммы Вороного, таким образом, Вы будете готовы заплатить добавленную сложность.

Вы не указывали то, под чем Вы подразумевали самый быстрый. Если бы Вы хотите получить ответ быстро, не пишущий кода, я дал бы gpsbabel фильтру радиуса движение.

Это может быть решено несколькими способами. Я сначала приблизился бы к этой проблеме путем генерации сети Delaunay, подключающей самые близкие точки друг к другу. Это может быть выполнено с командой v.delaunay в ТРАВЕ ГИС-приложения с открытым исходным кодом. Вы могли завершить проблему в ТРАВЕ с помощью одного из многих модулей сетевого анализа в ТРАВЕ. С другой стороны, Вы могли использовать свободный пространственный RDBMS PostGIS, чтобы сделать запросы расстояния. Пространственные запросы PostGIS значительно более мощны, чем запросы в MySQL, поскольку они не ограничиваются к операциям BBOX. Например:

SELECT network_id, ST_Length(geometry) from spatial_table where ST_Length(geometry) < 10;

Так как Вы используете Долготу и Широту, Вы, вероятно, хотите использовать функции Сфероидального Расстояния. С пространственным индексом PostGIS масштабируется очень хорошо для больших наборов данных.

Даже если Вы создаете диаграмму Вороного, которая все еще означает, что необходимо сравнить x, y координаты ко всем 15 тысячам созданных областей. Для создания этого легче, первая вещь, которая появилась в мой ум, хотя должен был создать своего рода сетку по возможным значениям, так, чтобы можно было легко поместить и координата x/y в одно из полей в сетке, если то же сделано для списка областей, необходимо быстро уменьшить возможных кандидатов на сравнение (потому что сетка была бы более прямоугольной, для области возможно быть в нескольких положениях сетки).

Преждевременная оптимизация является корнем всего зла.

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

Насколько большой область эти координаты, распространенные законченный? В какой широте они? Какого количества точности Вы требуете? Если они справедливо близко друг к другу, можно, вероятно, проигнорировать то, что земля кругла, и просто рассматривайте это как Декартову плоскость вместо того, чтобы иметь предосудительные отношения со сферической геометрией и большими круговыми расстояниями. Конечно, поскольку Вы добираетесь далее от экватора, степени longitute становятся меньшими по сравнению со степенями широты, таким образом, своего рода масштабный коэффициент может быть соответствующим.

Запустите с довольно простой формулы расстояния, и грубая сила ищут и видят, сколько времени это собирается взять и если результаты достаточно точны, прежде чем Вы станете необычными.

Спасибо все для ответов.

@Tom, @Chris Апчерч: координаты являются справедливо близко к каждому другими, и они находятся в относительно небольшой площади приблизительно 800 кв. км. Я предполагаю, что могу предположить, что поверхность является плоской. Я должен обработать запросы много раз, и ответ должен быть достаточно быстрее для большего веб-опыта.

Сетка очень проста, и очень быстро. Это - в основном просто 2D массив списков. Каждая запись массива представляет точки, которые падают в ячейке сетки. Очень легкий настроить сетку:

for each point p
  get cell that contains p
  add point to that cell's list

и очень легко искать вещи:

given a query point p
  get cell that contains p
  check points in that cell (and its 8 neighbors), against query point p

Alejo

Только, чтобы быть противоположными, Вы имеете в виду близко в расстоянии или (ведущее) время? В городской зоне я с удовольствием управлял бы 5 милями (5 минут) на магистрали, чем 4 мили (20 минут останавливаются и проходят) в другом направлении.

Таким образом, если бы это - 'самая близкая' метрика, Вам нужно, я изучил бы базы данных GIS с метриками времени прохождения.