Мультиполигоносрач

Ну, давайте сделаем свой незакостенелый OSM с блекджеком и нормальными человекопонятными объектами и связями, как минимум на уровне API.

А если серьёзно, то я не встречал пока вменяемых предложений по изменению модели OSM. Без шуток.
Не могли бы вы обрисовать своё видение организации оптимальной структуры данных. Ну или ссылок каких накидать.

Хм… да немного перебор, я не думаю, что там wood настолько сплошняковый… прям ни капли чистого места…

Я вот тоже стал подседать на мультиполигоны … но вот только совсем не завидую тому, кто вдруг захочет что-то улучишить или исправить …

Вообще прикольна модель объектов в ОСМ:

  1. Точка - node
  2. Линия состоящая из точек - way
  3. Линия состоящая из линий - relation (река например)
  4. Площадный объект без дырок состоящий из точек - way
  5. Площадный объект без дырок состоящий из линий - multipolygon aka relation
  6. Площадный объект с дырками состоящий из линий - multipolygon aka relation

Мультиполигон состоящий только из outer - изврат. Это типичный way но составленный из линий а не точек. Короче “relation наше всё” звучит как-то непривычно для человека пришедшего из мира векторной графики …

Так проблема идеологическая или техническая? С технической точки зрения в JOSMе с мультиполиками всё ок. А если проблема идеологическая, то на данном этапе развития ОСМ лучше способы решения проблемы обсуждать на кухнях под канистру горячительного)))

4 и 5 бывают копиями, но таки я лично использую 5 вариант, когда например граница residential и industrial совпадает или граница парка идёт, но не по всей границе есть barrier, потом в мульти-полигоне есть и линия с barrier и линия без тегов и вкрапления barrier в эту линию… Или недавний пример - граница парка - кирпичный забор завода, то есть стенка и к заводу и к парку в ОСМо-плане принадлежит. Наверное плохо, когда это доводят до абсурда…

GaM

Еще пример: стык леса и луга. Ранее я рисовал 2 полигона с общими точками в месте соприкосновения. Сейчас же я лучше нарисую 2 мультиполигона. Быстрее и править потом проще…

А я вот в упор не понимаю чем 2 полигона с границей “по общим точкам” хуже 2х мультиполигонов. То что линии накладываются - и что? При двух мультиполигонах геометрия все равно в общей линии накладывается, просто это происходит не столь явно. Хотя мне не западло и так и эдак нарисовать.

А еще мультиками удобно собирать полигон place у пребрежных НП из линии по суше и куска coastline.

Хм… Вообще-то гис-технологиям не один десяток лет, и всё уже давно придумано.

Ну если навскидку:

  • надо отцепить API от внутреннего представления данных
  • на уровне пользователя объекты надо сделать атомарными и более-менее унифицированными (никаких мультиполигонов, которые состоят из веев, которые состоят из нодов!)
  • нужны более гибкие способы задания связей между объектами

Если когда-нть до этого дойдёт, тогда можно уже будет думать дальше.

не знаю как Фелису, а мне понятней не стало, может гугл подскажет…

“Если когда-нть до этого дойдёт, тогда можно уже будет думать дальше.” - OSM так не работает. Пока нет чёткого представления, бесполезно браться за реализацию.

Если не сложно, можно конкретные ссылки? Где бы почитать теорию и какие-то азы.
Мне действительно интересно. Но я далёк от мира ГИС. Я варюсь в CAD/CAM и векторной графике поэтому сравнивать могу только с ними.
Из ГИС имел дело только с MapInfo. Но много и плотно. Ненавижу эту программу всеми фибрами души. Именно за “бестолковую модель данных” (ИМХО, конечно).

И текущая модель представления данных в OSM мне по душе. Вопрос скорее в неудобном инструментарии для работы с этой моделью. Отсюда много непонимания и сложности в освоении.

Ещё раз и ко всем

Если вам по душе другое представление данных, поделитесь ссылкой на описание этой системы. Заранее признателен всем откликнувшимся.

Дык я ж говорю: в ОСМ этого не будет, по многим причинам.
Как OSM работает, все знают: API 0.6 уже почти 3 года, а про 0.7 ещё даже нет понимания, что в него включить.
Так что действительно, “бесполезно браться”.

Лёшь, поделись ссылками хотя бы для познания.

За всё это время я видел только одно внятное и проработанное предложение по исправлению ситуации, не в жанре «нужны более гибкие способы» и «бесполезно браться»: тип данных area. На самом деле, даже конкретная реализация этого типа не важна, потому что самое важное — валидация при загрузке. Ну и удобство редактирования, которое для мультиполигонов я стараюсь повысить своим плагином. Но апи 0.7 никто не будет заниматься, пока не решён вопрос с переходом на ODbL.

Пока я советую, и советую уже очень долгое время, не ныть, а смириться с нынешней моделью данных и научиться её использовать.

Area - те же яйца, вид сбоку. Ни один из этих семи “внятных и проработанных” вариантов проблем не решает.

Именно что.

Просто проблемы на самом деле не там.

Пожалуйста, говорите конкретней. Спасибо. :wink:

Я конечно ничего не хочу сказать плохого, но по-моему деревья не квадратные? И пробелы между ними есть. Там очень много inner нужно сделать, если уж браться за рисование.

(del)

Если у кого-то бугурт из-за мультиполигонов, то это прекрасно, так мы быстрее доведём ситуацию до «СДЕЛАЙТЕ ХОРОШИЙ ИНСТРУМЕНТ ДЛЯ РАБОТЫ С МУЛЬТИПОЛИГОНАМИ ВО ВСЕХ РЕДАКТОРАХ». Давно пора же.

Тред не читал.