Вея нет. Граница может быть веем, мультиполигоном, а может и вообще не быть. Всё это нужно по-разному обрабатывать, при том что обычно всё равно нужна точка.
Ну обрабатывать это всё надо в любом случае, иначе сервис будет убогим, если он оперирует только нодами. И опять за запрос обычно задаётся bbox-ом и что придет в результате не важно, одна точка или много точек полигона.
В way нет координат. Есть только id узлов.
Т.е. добыть координаты для way существенно более ресурсоемко. Ориентировочно - на порядок.
При обработке значительных площадей это может играть существенную роль. (успеваем обработать за 3 часа или не успеваем за сутки)
Кстати - да.
По статистике у нас менее половины населенных пунктов имеют полигональную границу.
Отчего же сразу - убогим.
Все определяется потребностями.
С точки зрения дорожного графа одна точка в центре крупной транспортной развязки намного лучше массива точек, средняя координата которых находится где-то в районе геометрического центра н/п.
Кроме того, мы ведь получаем из bbox’а не все подряд, а лишь то, что запросили. Точек типа place будет на несколько порядков меньше, чем нетегированных точек. И у нас либо существенно меньшая вероятность нарваться на таймаут, либо возможность получить данные за гораздо меньшее число запросов.
Где же тут на порядок, в первый проход получаем все точки, во-второй вей-ид куда входят эти точки.
Но это ладно, я больше не понимаю, почему вы все ссылаетесь на трудность обработки. Если программа нормальная, а не фигня на которую и не стоит равняться, то она должна уметь обрабатывать и мультиполигоны и всё прочее. А если она это всё умеет, то к чему эти выкрутасы - мы будем обрабатывать только точку.
Программа должна уметь делать только то, что от нее требуется.
Если от нее не требуется работать с мультиполигонами, она этого уметь совершенно не должна.
Скажу более: ни одна программа в принципе не может уметь ВСЕГО. И разработчику (разумеется, если он хочет создать полезную программу в обозримые сроки) обязательно нужно решить, какие функции реализовывать, а от каких - отказываться.
Из всего множества данных он выбирает линии с тегом highway и точки с тегом place.
Больше ему не нужно.
По крайней мере, пока.
Но, поверьте, это в масштабах local.osm и так довольно много.
Можно то же самое, только по-русски?
А кому мешает дублирование?
В конце концов, дублирование - это избыточность. А избыточность - непременное условие для обнаружения ошибок с целью их дальнейшего исправления.
Т.е. избыточность - это в гораздо большей степени хорошо, чем плохо.
Это как раз то, о чем я говорил: появившуюся ошибку можно алгоритмически детектировать, а потом и исправить.
Если же информация содержится лишь в одном месте, то изменение ее с правильной на неправильную алгоритмически необнаружимо, поэтому ошибка будет там до тех пор, пока кто-то глазами не обратит на нее внимание. А это может случиться очень не скоро, а то и вообще никогда.
валидаторы обычно сравнивают какое-то эталонное значение с тем что есть в базе, если там есть несколько значений, то да - покажет расхождение; саму избыточность то они не используют
и таки-да, я тоже раньше считал что все надо вешать теги на полигоны, все-таки город - это не точка на карте, если нужно отметить именно центр, то можно это сделать каким-нибудь спецтегом, внутри place; но потом вроде как убедили все на точку вешать для удобства обработки данных, но тогда по-идее дубли тегов на веях совершенно не нужны
Для начала напиши “нормальную” программу которая по планете вытащит все НП не используя точек, за приемлемое время. А потом поговорим, что сложно, что не нужно, что есть выкрутасы и где должны быть тэги.