Ну, давайте сделаем свой незакостенелый OSM с блекджеком и нормальными человекопонятными объектами и связями, как минимум на уровне API.
А если серьёзно, то я не встречал пока вменяемых предложений по изменению модели OSM. Без шуток.
Не могли бы вы обрисовать своё видение организации оптимальной структуры данных. Ну или ссылок каких накидать.
Я вот тоже стал подседать на мультиполигоны … но вот только совсем не завидую тому, кто вдруг захочет что-то улучишить или исправить …
Вообще прикольна модель объектов в ОСМ:
Точка - node
Линия состоящая из точек - way
Линия состоящая из линий - relation (река например)
Площадный объект без дырок состоящий из точек - way
Площадный объект без дырок состоящий из линий - multipolygon aka relation
Площадный объект с дырками состоящий из линий - multipolygon aka relation
Мультиполигон состоящий только из outer - изврат. Это типичный way но составленный из линий а не точек. Короче “relation наше всё” звучит как-то непривычно для человека пришедшего из мира векторной графики …
Так проблема идеологическая или техническая? С технической точки зрения в JOSMе с мультиполиками всё ок. А если проблема идеологическая, то на данном этапе развития ОСМ лучше способы решения проблемы обсуждать на кухнях под канистру горячительного)))
4 и 5 бывают копиями, но таки я лично использую 5 вариант, когда например граница residential и industrial совпадает или граница парка идёт, но не по всей границе есть barrier, потом в мульти-полигоне есть и линия с barrier и линия без тегов и вкрапления barrier в эту линию… Или недавний пример - граница парка - кирпичный забор завода, то есть стенка и к заводу и к парку в ОСМо-плане принадлежит. Наверное плохо, когда это доводят до абсурда…
Еще пример: стык леса и луга. Ранее я рисовал 2 полигона с общими точками в месте соприкосновения. Сейчас же я лучше нарисую 2 мультиполигона. Быстрее и править потом проще…
А я вот в упор не понимаю чем 2 полигона с границей “по общим точкам” хуже 2х мультиполигонов. То что линии накладываются - и что? При двух мультиполигонах геометрия все равно в общей линии накладывается, просто это происходит не столь явно. Хотя мне не западло и так и эдак нарисовать.
Хм… Вообще-то гис-технологиям не один десяток лет, и всё уже давно придумано.
Ну если навскидку:
надо отцепить API от внутреннего представления данных
на уровне пользователя объекты надо сделать атомарными и более-менее унифицированными (никаких мультиполигонов, которые состоят из веев, которые состоят из нодов!)
нужны более гибкие способы задания связей между объектами
Если когда-нть до этого дойдёт, тогда можно уже будет думать дальше.
“Если когда-нть до этого дойдёт, тогда можно уже будет думать дальше.” - OSM так не работает. Пока нет чёткого представления, бесполезно браться за реализацию.
Если не сложно, можно конкретные ссылки? Где бы почитать теорию и какие-то азы.
Мне действительно интересно. Но я далёк от мира ГИС. Я варюсь в CAD/CAM и векторной графике поэтому сравнивать могу только с ними.
Из ГИС имел дело только с MapInfo. Но много и плотно. Ненавижу эту программу всеми фибрами души. Именно за “бестолковую модель данных” (ИМХО, конечно).
И текущая модель представления данных в OSM мне по душе. Вопрос скорее в неудобном инструментарии для работы с этой моделью. Отсюда много непонимания и сложности в освоении.
Ещё раз и ко всем
Если вам по душе другое представление данных, поделитесь ссылкой на описание этой системы. Заранее признателен всем откликнувшимся.
Дык я ж говорю: в ОСМ этого не будет, по многим причинам.
Как OSM работает, все знают: API 0.6 уже почти 3 года, а про 0.7 ещё даже нет понимания, что в него включить.
Так что действительно, “бесполезно браться”.
За всё это время я видел только одно внятное и проработанное предложение по исправлению ситуации, не в жанре «нужны более гибкие способы» и «бесполезно браться»: тип данных area. На самом деле, даже конкретная реализация этого типа не важна, потому что самое важное — валидация при загрузке. Ну и удобство редактирования, которое для мультиполигонов я стараюсь повысить своим плагином. Но апи 0.7 никто не будет заниматься, пока не решён вопрос с переходом на ODbL.
Пока я советую, и советую уже очень долгое время, не ныть, а смириться с нынешней моделью данных и научиться её использовать.
Я конечно ничего не хочу сказать плохого, но по-моему деревья не квадратные? И пробелы между ними есть. Там очень много inner нужно сделать, если уж браться за рисование.
Если у кого-то бугурт из-за мультиполигонов, то это прекрасно, так мы быстрее доведём ситуацию до «СДЕЛАЙТЕ ХОРОШИЙ ИНСТРУМЕНТ ДЛЯ РАБОТЫ С МУЛЬТИПОЛИГОНАМИ ВО ВСЕХ РЕДАКТОРАХ». Давно пора же.