История вопроса

На этой неделе у меня пошли гениальные идеи, как нам обустроить API. Ночная беседа с jekhor про проблемы отношений веломаршрутов утром понедельника конденсировалась в тикет в Rails Port, где я предложил добавить в возвращаемые объекты ссылки (тип и id) на содержащие их линии и отношения. Так редактор всегда будет знать, что точки и линии принадлежат неподгруженным объектам, и сможет предупредить пользователя перед разбиением или удалением. После обычных комментариев непонимания обсуждение перешло на технические проблемы и вопросы совместимости, и вечером на встрече рабочей группы по технологиям (EWG) мы согласились, что добавление нового тега в вывод API сломает какие-нибудь программы, вроде osmosis. Поэтому пора повышать номер версии OSM API.

В вечерней беседе после конференции промелькнула мысль, что если мы так и будем ждать от API 0.7 великого (см. список предложений и сокращённый список), он никогда не наступит. Поэтому нужно двигаться мелкими шажками: например, поправить бардак в статусах ошибок HTTP, добавить мелкие валидации, формат JSON, всё такое. На этой волне я составил список, выросший за неделю до 14 пунктов, большая часть которых решается парой запросов к базе данных (а то и вовсе парой строк кода). Задержав окончание собрания на час, мы с Мэттом Эймосом договорились, что пора делать форк, или как там добавляется новый API к серверу. Просто чтобы была площадка для экспериментов, и чтобы дать старт. Вполне вероятно, на следующей неделе будут сделаны первые запросы к ...dev.openstreetmap.org/api/0.7.

Конечно, согласившись, что изменения должны быть мелкими, я не продержался и часа, чтобы не взяться за вечную проблему API 0.6: тип объектов area. Подходов к нему было множество, хотя после ноября 2012 года, когда Jochen Topf написал заметку про области, копошение затихло. Что печально: ни один из вариантов не был идельным. Например, решение для береговых линий было только у совсем диких предложений. Не совместив в едином типе здания о четырёх стенах и береговую линию, нечего и думать о свержении статуса-кво. Пришлось подумать очень хорошо, и решение оказалось достаточно простым, похожим на предыдущие попытки, и одновременно отличающимся в деталях.

Предлагаемые области содержат списки точек для каждого из внешних и внутренних контуров: как линии, только вместо одного списка — несколько. По сути, это полигоны модели Simple Features, со всеми плюшками и ограничениями, и их преобразование в формат Shape / PostGIS будет элементарно. Недостатки — невозможность делить часть контура между областями и ограничения на количество точек — исправляет второй способ задания областей. Он похож на мультиполигоны, но наоборот: не область ссылается на линии, а линии на область. Так можно совместно одновременно редактировать одну и ту же область (привет трогавшим границу РФ), и не будет конфликтов, потому что сам объект не изменяется. Со стороны базы это не отличается от мультиполигона: всё то же отношение «многие ко многим», но без явного списка для потребителей данных. При этом все точки и линии, составляющие контуры, сортируются против часовой стрелки для внешних контуров и по часовой для внутренних: это позволяет правильно отобразить частично загруженные данные (у мультиполигонов с этим беда). В вики есть наглядный пример с картинкой, но если объяснить ещё проще, вместо полигонов будут костлайны. Вопрос «делать Онежское озеро мультиполигоном или костлайном» отпадёт автоматически.

Одного видения для внедрения типа area недостаточно: нужно продумать алгоритм миграции базы данных, написать новые api и страницы для Rails Port, обновить cgimap, сделать поддержку в каком-нибудь редакторе (и, боюсь, level0 недостаточно) и в каком-нибудь рендерере (хоть osmarender). Написать сотню тестов и убедить всех, что идея работает. Только после этого, когда мутный поток «а вот я бы сделал так» иссякнет, а форк будет готов к пул-реквесту, вопрос «а не сделать ли нам тип area вот так» приобретёт достаточный вес. Право, лучше не мучаться, а ограничиться для нового API правкой статусов ошибок, мелкими валидациями и парой новых запросов к базе данных.

Поделиться
Отправить
2014   osm.org
8 комментариев
Виктор

Только не надо трогать береговую линию, это ошибка.
Оставьте ее как есть, пожалуйста... Единственное адекватное решение береговой линии это разбить на квадранты, хотя бы 11 зума, это займет мизер места, но все программы будут правильно рендерить океан.

Смешивать здания area которые видны на 17 зуме и coastline, которые невозможно объединить в разумных пределах — это плохой подход. Да есть еще Великие Озера, которые сложно процессить, но опять же навредить проще, чем улучшить.

Честно говоря, я против сортировок по часовой и против, гораздо проще склеивать и считать вложенность.

Для маленьких полигонов любой из подходов хорош, для огромных (страны, моря. coastline) вижу решения как разбиение на квадранты + доп. отношение (имя, список квадрантов) и API который бы позволял мержить квадранты (хотя его не сложно и самому написать)

Илья Зверев

Давай сразу условимся, что ни порядка следования точек, ни явных ссылок на линии пользователи не увидят. Редактирование береговой линии для них не сильно будет отличаться от редактирования, например, границы леса. Разбитую на квадратики поверхность моря (или суши) всё так же можно будет скачать с http://openstreetmapdata.com — изменится лишь алгоритм сборки полигонов, да появится какая-то валидация на сервере OSM, из-за которой береговую линию станет чуть сложнее сломать. Последний твой абзац — это придумывание костылей для обхода проблемы, которой не будет существовать, если примут моё предложение о модели area.

Виктор

Внимательно изучив предложенный метод, http://wiki.openstreetmap.org/wiki/User:Zverik/Areas_ru, тег <area> был давно предложен и я его полностью поддерживаю для редактирования.
С точки зрения редактирования, я также поддерживаю arearef id=«1000». с другой стороны не вижу смысла ограничивать А — одним arearef (то есть их может быть много), а B я думаю это надо распространить и на relationref. Точно такая же логика применима и к national трассам и к route и ко всему остальному.

Я также считаю, что мы все время пытаемся применить универсальный формат, что не совсем правильно. Например, для процессинга и рендеринга гораздо удобнее , когда точки лежат в самих объектах, как way, area (именно лежат как lat/lon), что не надо сохранять и держать кеши, а можно обрабатывать за линейное время. Также абсолютно логично , если сначала будут идти пустые relation (только теги), а уже дальше полные node и полные way (это может не имеет отношение к текущей дискуссии).

По поводу «больших» объектов, я думаю, что предложенная схема по-большому счету ничего не меняет для coastline (можно ссылаться на один area World ocean?). Но это не решает проблему рендерингов локальных областей. Может редактировать это и удобнее, это можно постпроцессить и разбивать на квадранты (спасибо за ссылку, к сожалению не нашел там osm.xml). Но «нативная» поддержка квадрантов, могла бы нас избавить от вопроса , если я в центре океана, то что рисовать, на суше я или в море, ведь по bbox мне ничего не вернется.

А обрабатывать coastline способом большие леса и поля, спасибо, уже хватило... Тем более, что никогда не известно, а  все линии леса попали в pbf или это просто не замкнутый лес. Площади должны оставаться площадями и их должно быть очень сложно сломать или выгрузкой или редактирование одной маленькой части.

Илья Зверев

Arearef-ов может быть много, я сейчас пояснил в тексте, раз это не было очевидно. Отношения уже поздно менять, ну и я против отношений route=road и веломаршрутов, это всё тегами делалось бы куда лучше. Если в отношении больше десятка членов, его схема — отстой.

Схема, как раз, решает проблему рендеринга кусочков областей: даже если в bbox попала информация только об одном отрезке, уже можно правильно нарисовать всю область в рамках bbox — благодаря фиксированному направлению обхода, как в костлайнах. А если ничего не попало — так и сейчас невозможно определить. Против слома тут можно сделать некоторые проверки, что уже лучше, чем в мультиполигонах.

пыщ-пыщ

Никто не читает штосм, а я читаю.

Хм...

А я тоже читаю! Пиши есчё! )

comme jamais

It’s very!

fserges

0.7 должен быть, хотя бы с минимальными изменениями. А то появилось ощущение проект застыл, только количество точек продолжает увеличиваться ...

putnik

Если 0.7 в обозримом будущем не будет вообще, то ощущение, что проект застыл, будет куда сильнее, чем если это будут только фиксы.

Виктор

Отпишу в топик, хотя может уже никто не читает. Основная проблема OSM вырос и вырос до приличного продукта, но методы, которые мы применяем сложно назвать «приличными».

Сейчас самое время начать разделять, внутреннюю базу и загружаемую базу. Самое время начать думать, а что если мы внутренне сделаем поддержку 0.7, а внешне можем read-only отдавать и 0.6. Это возможно сделать ! И это нужно сделать! В конце концов оба варианта плохие : А) ничего не менять Б) менять и все ломать.

Пора наконец-то задуматься о backward compatibility и forward compatibility и наконец-то разделить загрузки по предназначениям. Или наши форматы не поддерживают версионирование? Так нет же xml видел сам.

Так что никто не должен страдать, надо сделать поддержку 2 версий и запустить самый нереальный change типа area и посмотреть, что все еще работает. К сожалению, сделать это могут только владельцы osm Editing API (openstreetmap.rog).