А вы попробуйте сами создать такой алгоритм, так чтобы он быстро работал на любых конфигурациях площадей. Это человеку такая прокладка даётся легко, а вот алгоритмов (которые можно было бы запрограммировать) я пока подобных не встречал, все как-то графами оперируют.
Поэтому есть вполне разумное предложение - разделить линии дорог (highway=) и площадную часть (area:highway=). Алгоритмы, которые умеют работать только с графом - будут пользоваться первыми, а если кто напишет быстродействующий площадной роутинг - смогут воспользоваться вторыми.
определение длины маршрута, содержащей проезд через площадь
отрисовка маршрута через эту площадь
1:
будем брать округленный результат, не будем считать с точностью до метра, для маршрута это не критично. предполагаем, что площадь пуста (не содержит памятников и газонов и проехать можно из точки въезда до точки выезда напрямую). тогда легко знать длину проезда через площадь. возможно эти данные (все длины, от каждой точки до каждой) можно хранить в БД. этих длин там будет не так много в среднем думаю к площади подходит 4-6 дорог, так что в среднем не более 10 значений. далее маршрутизатор просто подставляет в месте предпоалагаемого маршрута нужное число и сравнивает с другим маршрутом, определяя какой быстрее. кстати, на площадях лично я ни разу не видел дорожных знаков
2:
итак, маршрутизатор решил, что дорога через площадь короче. значит надо отрисовать маршрут
рисуем линию от А до Б. это несложно если только на пути нет препятствия
если маршрутизатор простой, то можно можно просто отрисовать поверх препятствий - водитель разберется на месте как их объехать
если продвинутый, то в месте пересечения с препятствием он изламывает маршрут по границе препятствия
если дорога напрямую из А в Б невозможна, то строится линия к ближайшей точке, находящейся поближе к Б. оттуда еще раз смотрим, можно ли проехать от этой точки до Б. при необходимости повторяем
машины ездят не где хотят. но они ездят по площадям, где фактически “протоптаны” полосы. вот сейчас не вспомню где видел, но видел дороги наподобие таких
где прямоугольник в центре - площадь. движение внутри редкое, так что никаких знаков там нет
ну хорошо, пусть для автомобильных маршрутов такого не нужно, но для пешеходных можно
да и ладно, пусть даже роутинг и там не нужен. но пусть он хотя бы делает толщину обводки такую же как у дороги и заливку
Много разных - смотря что за мелководье, в зоне приливов (tidal), пересыхающие (intermittent). На реках их отмечать вообще обычно не стоит - они слишком непостоянные, конфигурация их легко может меняться в течении нескольких лет, легко заметно при сравнении снимков за разные годы.
Добрый вечер.
Из FAQ я правильно понял - что правки рассматриваются раз в неделю?
А то изменение внес и каждый день захожу и смотрю. А на общей карте оно никак не изменилось
Обычно изменения на мапнике появляются сразу, в течении нескольких минут, но не сразу на всех зумах. Если затронуты сложные отношения, может быть намного дольше, даже месяцы.
Для конвертеров (например, делающих карту для навигационной программы) изменения доступны сразу.
В OSM нет премодерации, все правки сразу попадают в общую базу.
Если имеется в виду мапник на osm.org - то обычно данные у него обновляются в течении пару минут (иногда при работах на сервере могут временно синхронизацию отключить).
Изменения на зумах >=13 видны сразу (нажмите обновить страницу в броузере), на меньших - с задержкой, можно перерисовку конкретного квадрата дёрнуть вручную.
Исключения - береговая линия (natural=coastline), она обновляется редко (раз в несколько месяцев).
У разных конвертеров в навигаторы свои интервалы обновлений, от дней до месяцев.