Релейшены - за и против

Выделено из топика Конвертер OSM → MP

А можно конкретные цифирки? А то я тут размахнулся на 65534 дочерних объекта, может, и не стоило?

Честно говоря, считаю (и как-то подумалось, что в сообщении имеет место именно это), что объединять нужно relation’ами.
Да и вообще, по-хорошему, ВСЕ объекты должны быть relation’ами, а node и way использоваться не как самостоятельные объекты, а как “кирпичики” для построения объектов.

Насколько помню, у линии есть ограничение на 2000 точек. Поправьте, если ошибаюсь.

http://wiki.openstreetmap.org/wiki/API_v0.6#Capabilities:GET.2Fapi.2Fcapabilities

Ага, а ещё было предложение выкинуть ноды и веи, и заменить их релейшенами type=node и type=way

Надо!
Собственно, недостаточная поддержка релейшнов (если не сказать - их необязательность) связана с одним единственным обстоятельством - ошибкой проектирования, допущенной на ранней стадии проекта.
Без релейшнов вменяемую карту сделать невозможно.
ТОЛЬКО релейшнами (т.е. когда ЛЮБОЙ объект является релейшном) - запросто. Более того, только в этом случае появится приемлемая гибкость, универсальность и простота обработки.
По сути сейчас проекту не хватает одного - запретить другие объекты кроме релейшнов.

Увы, это лишь limitations of the current API.
Кстати, можно пояснения к паре строчек?
- это, наверное, оно и есть
- что за площадь и в каких единицах измеряется?
- опять же, что за страница?
- это, как я погимаю, история изменений? А кто-то говорил, что под нее отведено 64-разрядное целое (кстати, интересно - со знаком или без)
- а это совсем непонятно

Простое устранение “элементарных” типов ни к чему хорошему не приведет. А вот если рендерер или конвертор будет работать ИСКЛЮЧИТЕЛЬНО с релейшнами, не разбирая отдельные узлы и пути до тех пор, пока они не встретятся в релейшне, это здорово упростит задачу.

Честно говоря, считаю (и как-то подумалось, что в сообщении имеет место именно это), что объединять нужно relation’ами.

Релейшн никакой новой информации не добавляет. Объекты (сегменты рек, дорог), уже объединены самой топологией.

И кому оно будет нужно, если оно ничего не “увидит” на карте?

Все просто
area - площать, отдаваемая апи клиенту.
tracepoints - пакет точек треков, отдаваемых апи за раз.
changesets - количество объектов в чейнджсете
timeout - таймаут отвала при выполнении запроса.

Зато он позволяет обрабатывать объекты без использования геометрических расчётов, кои бывают весьма тяжелы, и не всегда однозначны. Тут нужен компромис. Что-то считать через геометрию (типа принадлежности дороги нас. пункту или привязка точки POI к адресу дому, внутри которого она находится), А что-то лучше выделить в отдельные сущности (если расчёт слишком тяжёлый или приводит к неоднозначностям).

На самом деле у relation название немного неподходящее. По идее это должен быть “object”. :slight_smile:

Посмотрите на релейшены маршрутов… С них 1 единственный толк сейчас - прицепить название группе веев. Причём сама по себе группа содержит в себе веи никак не упорядоченные (“сенолослома”), часто в маршрутах нет остановок, в тех случаях когда они есть, они почти всегда перепутаны местами. Весь вопрос с том, ради чего задумывается релейшен, и насколько его потом будут правильно создавать и модифицировать. Сейчас мне интересна тема маршрутов общественного транспорта, так я только на то, чтобы найти правильно составленный маршрут (по правилам OSM) убил 3 дня. Да, можно наплодить из хоть сколько. толку от них не будет без внятной документации и инструментов для их корректного редактирования и валидации действий пользователя над ними.
Что качается расчётов, то в текущей ситуации их в 1000 раз больше чем, если вместо релейшена, провести единый вей через все точки маршрута.

Ну и как тут поможет топология? :slight_smile:
Чтобы был толк - надо чтобы те, кто эту информацию использует, написали внятное описание что и как делать, а так же создали необходимые инструменты визуализации/редактирования/валидации. Только тогда можно расчитывать что результат будет удобоваримым.
ИМХО, именно так работает процесс стандартизации в OSM, всё держится на обратной связи. Будут инструменты для обратной связи - будет результат. Не будет обратной связи - будет разброд и шатание.

Мы тут тоже маршрутным транспортом занимаемся, но решили всю информацию держить у себя (для возможности оперативного редактирования). Дык спец редактор для его составления и прокладки по карте сделали - иначе никак.

На самом деле, по-хорошему, строить нужно не релейшны, а именно объекты, которые могут включать узлы, пути и отношения. Т.е. единственная сущность, которая рисуется либо обрабатывается - объекты, которые состоят из узлов, путей и отношений, причем последние сами по себе ни в отрисовке ни в анализе не участвуют.
Такое построение целесообразно потому, что релейшны могут включать друг друга, а поэтому рисоваться/анализироваться должны не все из них, а лишь - верхнего уровня. Вот объекты и должны играть роль релейшнов верхнего уровня.

Точка — тоже object, но отношением его не представить. Отношение так названо за его характерную черту — он сопоставляет различные сущности друг с другом.

А вот представить линии как отношения не помешало бы, ведь с точки зрения софта не важно, что обрабатывать, тем более что и линии и отношения по сути одно и то же — упорядоченный набор сущностей (точек в частности). Более того, не мешало бы добавить и другие геометрические формы — криволинейные.

Что касается type, так это вообще, имхо, лишний ключ — что представляет отношение всегда определяется через прочие его теги и членов. Это всё равно, что писать type=landuse/amenity/natural и т. п.

Я об этом уже говорил, но мне не вняли.

Ну нельзя это назвать 100% ошибкой. Всё что угодно можно было бы закартировать и без релейшенов, при помощи одних только точек и линий, просто это требовало бы несколько иного подхода. Например, при помощи широкого использования составных ключей (через двоеточие), и сборки полигонов из линий-фрагментов по общему ключу (ref, name и пр.).

Нет, это принципиально невозможно. Одна сущность может быть непредставима ни одним из типов: “точка”, “линия”, а требовать именно объединения нескольких примитивов в одну совокупность.

Только для того, чтобы собрать объект из полигонов, линий и точек, нужен этот самый ref, т.е. УНИКАЛЬНЫЙ НОМЕР ОБЪЕКТА. И даже если в том файле или БД, с которыми мы работаем, не будет ЗАПИСИ, соответствующей объекту как таковому, реально этот объект будет существовать в виде своего номера.
А раз так, то явное введение объекта существенно упростит работу с файлом/БД.

На самом деле, точку можно представить отношением. Теги lat и lon, а в само отношение ничего не включать. :3

Тогда как на такую точку поставить тег lat? На обычную-то можно :slight_smile: