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 - те же яйца, вид сбоку. Ни один из этих семи “внятных и проработанных” вариантов проблем не решает.
Именно что.
Просто проблемы на самом деле не там.
Пожалуйста, говорите конкретней. Спасибо. 
Я конечно ничего не хочу сказать плохого, но по-моему деревья не квадратные? И пробелы между ними есть. Там очень много inner нужно сделать, если уж браться за рисование.
(del)
Если у кого-то бугурт из-за мультиполигонов, то это прекрасно, так мы быстрее доведём ситуацию до «СДЕЛАЙТЕ ХОРОШИЙ ИНСТРУМЕНТ ДЛЯ РАБОТЫ С МУЛЬТИПОЛИГОНАМИ ВО ВСЕХ РЕДАКТОРАХ». Давно пора же.
Тред не читал.
Знакомая мантра.
Только вот не дело это - лечить болячки дизайна редакторами. Лечить надо глубже.
Поэтому ХОРОШИЙ ИНСТРУМЕНТ ДЛЯ РАБОТЫ С МУЛЬТИПОЛИГОНАМИ (раз уж без них жизнь не мила) должен быть на сервере. А на пользователей этот гемор вываливать не надо, пусть даже через редакторы.
Именно редакторами и ничем другим. Те, кто ломают мультиполигоны, ломают их только из-за редакторов.
Неважно, как оно там на сервере. Редакторы придется менять (встраивать валидацию) В ОБОИХ случаях, и в твоем, и в моем. Но в твоем нужно ещё и модель даннных менять (а случится это в далеком светлом будущем), и валидацию на серверной стороне делать, а редакторы можно поправить хоть сейчас.
Золотые слова!
А вот на стороне пользователя всё должно быть предельно просто и понятно. А не трёхуровневые структуры из одноранговых объектов.
Конечно там далеко до идеала. Я сейчас привязываю деревья по ходилке, лазаю на них, меряю диаметр кроны и ствола. Выбираю, как лучше картировать листья на ветвях. Серьёзный вопрос, я щетаю. По трекам листья к веткам привязать тяжело. Немного промахнёшься и более опытные товарищи сразу обвинят в рисовании домыслов и фантазий. А у меня подход сурьёзный, ага.
to chnav
Сначала ты обвинил меня в рисовании по Гуглу, теперь в реализации не имеющих отношения к реальности домыслов и фантазий. Будь последовательным - расскажи всем, наконец, что я поедаю христианских младенцев! Мы устроим эпик тред. Я буду в ответ краснеть и сбивчиво отпираться. Тысячи НЯКов придут в этот тред чисто поржать, а откроют для себя ОСМ. Да, что там! Сама газета “Жизнь” посвятит нам целый разворот и об ОСМ будет знать каждая бабушка у подъезда. Золотые настанут времена.
P.S. Если надо конструктива, их есть у меня. Но думается, что не надо.
Лёш, ну это всё переливание из пустого в порожнее, ей богу! Дайте хоть какую-то отсылку на серьёзный материал.
Я тут накопал, вроде на Гислабе доку:
“Спецификация реализации пространственной
информации OpenGIS® – Доступ к простой геометрии -
Часть 1: Общая архитектура.”
Но он внушает страх одним своим объёмом. Может, где-то всё таки разжёваны основы “для чайников”. За неимением, конечно почитаю.