У меня есть база данных заданий mysql и solr, каждая со значением lat и lon для своего местоположения.
В настоящее время пользователи могут искать работу по местоположению, в пределах х миль.
Я хочу предоставить возможность поиска по местоположению, в течение х минут (время в пути).
Я пробовал поиск, но я могу только найти информацию о том, как нанести на карту возможную область путешествия, например, этот пример из route360: http://codepen.io/route360/pen/Wrbvmg
Кто-нибудь знает, как я могу тогда искать документы в моем ядре Solr (или в MySQL DB при необходимости), где docs latlon находится в этой области?
Или я должен подходить к этому по-другому?
У меня есть решение, работающее, где я просто использую среднюю скорость (скажем, 30 миль в час), а затем умножаю на фактор времени, который вводит пользователь (я использую солярий)
$speed = 30; //mph
$time = $_GET['time']; //say it was '30' minutes
// time is in minutes. get what that is as fraction of 60
// to multiply speed by to get radius
$fraction = $time/60; // would give 30/60 = 0.5;
$radius = $speed * $fraction; // would give 30 * 0.5 = 15 miles radius// lat and lon are created earlier from user input location by querying my DB of locations
$query->createFilterQuery('distance')->setQuery(
$helper->geofilt(
'latlon',
doubleval($lat),
doubleval($lon),
doubleval($radius * 1.609344) // default is KM so multiply to get miles
)
);
это отлично работает, но не совсем так точно. Это также не позволяет мне фильтровать по типам поездок, таким как ходьба, общественный транспорт … Есть идеи?
Время в пути — нетривиальный расчет.
Сначала вычислите минимальную и максимальную широту и долготу для ограничительной рамки x единиц измерения расстояния N, S, E, W входного местоположения. Получите ID, широту и долготу для местоположений в пределах ограничительной рамки
Затем вычислите «прямолинейное» расстояние между каждой точкой и входным местоположением, чтобы отфильтровать его до короткого списка местоположений, попадающих в радиус круга × единицы измерения расстояния.
Имейте в виду, что планета Земля не является сферой. Модели округлости мира существуют. Имеет ли это значение, зависит от того, насколько важны ложные негативы, сколько элементов нужно обработать и что является приемлемой производительностью.
Для последнего шага вам понадобится модель судоходных точек в качестве орграфа. Сопоставьте каждый locationID с узлом в орграфе.
Это подход в ширину, который лучше всего работает с ребрами, стоимость которых не сильно меняется. Возможно, вам удастся оптимизировать, настроив выбор узла, чтобы расставить приоритеты для узлов с низким прямым расстоянием до местоположения в коротком списке, но тогда вам нужно будет отследить маршрут, выбранный для каждого посещенного узла, в случае, если маршрут, рассчитанный позже, имеет более низкую стоимость чем уже рассчитанный маршрут, что требует вычитания разницы от всех узлов, чей текущий лучший маршрут проходит через повторно посещенный узел.
Я изучил некоторые из этих алгоритмов задач с графами в модуле «Информатика» около 10 лет назад. Это не новая проблема. Может существовать существующее решение, которое вы могли бы использовать вместо кодирования этого самостоятельно.
Других решений пока нет …