Comments 20
Два раза читал про Способ 1 и думал зачем он вам нужен вообще… он оказывается ТОЛЬКО для случая когда от точки внутри МКАД надо найти расстояние до точки вне МКАД…
Вы кстати оценивали имеет ли это смысл?
Ошибка существенная может быть только когда точка от которой ищем находится рядом с границей МКАД, особенно рядом с границей которая ближе к целевой точки, т.е. построитель маршрутов может выбрать для выезда «дальнюю» развязку МКАД.
Ну ещё может быть часть маршрута может пройти по МКАД, но Способ 2 с этим справится, главной границы МКАД с припуском взять.
Непонятно, вершины и очертания…
Вы кстати оценивали имеет ли это смысл?
Ошибка существенная может быть только когда точка от которой ищем находится рядом с границей МКАД, особенно рядом с границей которая ближе к целевой точки, т.е. построитель маршрутов может выбрать для выезда «дальнюю» развязку МКАД.
Ну ещё может быть часть маршрута может пройти по МКАД, но Способ 2 с этим справится, главной границы МКАД с припуском взять.
они не совпадают с вершинами очертания дороги на карте
Непонятно, вершины и очертания…
он оказывается ТОЛЬКО для случая когда от точки внутри МКАД надо найти расстояние до точки вне МКАД
Нет, если точка внутри полигона, мы ничего не рассчитываем. А если вне полигона — тогда строим KD-дерево.
Насчет вершин и очертаний я имею в виду вот что — есть полигон, который описывает мкад. но выезды с мкада сами по себе не лежат в вершинах, а на отрезках между вершинами, поэтому мы еще задаем отдельный полигон, в котором содержатся только выезды. В целом, можно было бы обойтись только им, но тогда есть маловероятная ситуация, когда точка внутри мкад окажется вовне.
Нет, если точка внутри полигона, мы ничего не рассчитываем. А если вне полигона — тогда строим KD-дерево.
Какого полигона? Почему не рассчитываете…?
До полигона, который обозначает область. Это в заголовке указано, это задача которая решается. Если точка лежит внутри области (полигона, который ей соответствует), очевидно, что расстояние равно нулю.
Хорошо. Тогда зачем Способ 1? Какой в нём смысл если можно сделать один запрос к маршрутизатору по Способ 2?
Верно, оба способа делают одно и то же, и оба делают всего 1 запрос к сервису геокодинга. Но моя цель не выбрать лучший, а просто рассказать, как вообще можно эту задачу решить. Оба способа рабочие, можно брать и пользоваться на здоровье
Ну сетевой запрос при вызове distance_matrix будет один, но запросов в маршрутизатор будет сколько маршрутов вы запросили и биллить вас будут за каждый маршрут, т.е. тут несколько запросов к маршрутизатору.
Так зачем Способ 1 если он ничем не лучше Способа 2, он дороже и моё предположение изначальное неверно?
Так зачем Способ 1 если он ничем не лучше Способа 2, он дороже и моё предположение изначальное неверно?
нет, везде будет 1 запрос. Есть точка. Мы проверили с помощью геометрии, что ее координаты не принадлежат нашему полигону. Значит нужно применять любой способ расчета.
В первом способе у нас есть несколько вершин (высчитанных благодаря KD-дереву), мы спрашиваем гугл — скажи мне, вот до этой, этой или этой точки, какой кратчайшее расстояние до любой из них?
Во втором способе мы знаем предопределенную точку внутри полигона, и говорим гуглу — дай маршрут до этой точки. Он построит несколько маршрутов, но это всё 1 запрос будет. Дальше мы рассчитаем, какова длина внешней части пути.
Когда к нам придет новая точка, нам так и так делать новый запрос в гугл, потому что будут новые ближайшие вершины или новый маршрут в центр, это неизбежно
В первом способе у нас есть несколько вершин (высчитанных благодаря KD-дереву), мы спрашиваем гугл — скажи мне, вот до этой, этой или этой точки, какой кратчайшее расстояние до любой из них?
Во втором способе мы знаем предопределенную точку внутри полигона, и говорим гуглу — дай маршрут до этой точки. Он построит несколько маршрутов, но это всё 1 запрос будет. Дальше мы рассчитаем, какова длина внешней части пути.
Когда к нам придет новая точка, нам так и так делать новый запрос в гугл, потому что будут новые ближайшие вершины или новый маршрут в центр, это неизбежно
нет, везде будет 1 запроссетевой да, а биллинг с вас снимут как за N-запросов маршрутизатора
биллинг Distance Matrix API developers.google.com/maps/documentation/distance-matrix/usage-and-billing
Чем Способ 1 лучше Способа 2?
Можно конкретно текст, на основании которого сделан такой вывод?
Я вижу вот что:
— Usage is tracked for each Product SKU
— Cost is calculated by SKU Usage x Price per each use
— SKU: Distance Matrix (0.005 USD per each)
— SKU: Directions (0.005 USD per each)
Из этого я делаю вывод, что оплата и того и другого запроса одинаковая.
Вероятно то, о чем вы говорите, основано вот на этой строчке.
Действительно, каждый запрос distance_matrix в моём алгоритме создает 7 elements, но биллинг не по ним выставляется. Есть только ограничения на elements — Maximum 100 elements per server-side request, 1000 elements per second.
Поправьте меня, если я не прав
Я вижу вот что:
— Usage is tracked for each Product SKU
— Cost is calculated by SKU Usage x Price per each use
— SKU: Distance Matrix (0.005 USD per each)
— SKU: Directions (0.005 USD per each)
Из этого я делаю вывод, что оплата и того и другого запроса одинаковая.
Вероятно то, о чем вы говорите, основано вот на этой строчке.
Each query sent to the Distance Matrix API generates elements, where the number of origins times the number of destinations equals the number of elements.
Действительно, каждый запрос distance_matrix в моём алгоритме создает 7 elements, но биллинг не по ним выставляется. Есть только ограничения на elements — Maximum 100 elements per server-side request, 1000 elements per second.
Поправьте меня, если я не прав
Действительно, способ 2 выглядит лучше, потому что по биллингу дешевле. Но теоретически второй способ зависит от выбранной точки, до которой строится маршрут, и из-за этого кратчайшее расстояние до полигона не всегда может быть таковым по факту, в том числе из-за особенностей дорог. 
Тем не менее, в целом Способ 2 выглядит предпочтительнее
Тем не менее, в целом Способ 2 выглядит предпочтительнее
чуть подредактировал статью, чтобы было понятнее в этом месте
Со вторым способом первой части так и не разобрался, хотелось бы услышать примеры. Так же бегло посмотрел репозиторий и там жестко зашиты несколько полигонов, и вопрос, ваша библиотека работает только на этих полигонах? и почему бы не подавать на вход geojson?
Да, сейчас полигоны жёстко зашиты, для решения задач этого было достаточно. В дальнейшем если будет потребность, можно будет расширять.
Второй способ я использовал для расчета расстояния до КАД в Питере, насчет примера не знаю, насколько это уместно делать в комментариях
Второй способ я использовал для расчета расстояния до КАД в Питере, насчет примера не знаю, насколько это уместно делать в комментариях
Ничего страшного, просто приведите пример как это будет использоваться в "сельском хозяйстве"?
И почему нельзя просто задать 2 точки и найти кратчайший путь? К чему все эти манипуляции с полигонами?
<перенесено в ответы к комментариям>
Sign up to leave a comment.
В зоне доступа. Находим расстояние от точки до области и сокращаем запросы обратного геокодинга