В случае, если мы игнорим building:part=* получается фигня. Представь, 12 этажное здание с выступающим первым этажом с магазинами и ты тегируешь это здание как одноэтажное. Хотя спроси любого прохожего, тебе подскажут, что тут всё таки двенадцатиэтажное здание.
А есть что под андроид для отображения этих красот?
А где получается фигня? На плоскости (2-d картах) «фигня» по умолчанию, этажность и/или высоты не учитываются. В 3-d всё прекрасно.
Фигня же заключается в том, что мы — в угоду мифической совместимости (чего и с чем — не понятно) — теряем удобство, простоту и наглядность там, где это действительно необходимо: в 3-d тегировании.
P. S. Под андроид — пока не встречал. Приложение от OpenScienceMap, отличается от он браузерной версии рендеринга.
И ещё ОРУ-карты 3D
ОРУ-карты 3D
LLlypuk82, а почему в случае с бубликом не затегировать это как положено через relations, а не вешать левые теги на линии? Зачем там вообще на линиях теги, когда это должны быть отношения? У меня вообще сложилось впечатление что если какая-то линия будет использована больше одного раза, то где-то тут должно быть отношение.
Если речь о мультиполигонах, то: они=complex, предлагаемое=simple, полностью заменяющее первый вариант.
Мультиполигоны не всегда оправданны, не всегда обязательны, всегда сложнее. А теги — самые обыкновенные, можно сказать, стандартные.
Фигня получается в данных, причём тут 3Д. Я тыкаю в дом, а там написано 1 этаж. Я подымаю голову, а их там в 12 раз больше.
А где (в каком приложении) надо тыкнуть, чтобы получить описанную ситуацию?
В любом деле которому чхать на 3Д. Представь, что я собираю статистику жилых многоэтажек.
И я так до конца и не понял зачем это vertical/horisontal? Никакой смысловой нагрузки не несёт, всё и так понятно из частей.
Да, тег building:parts не явлется обязательным.
Нет, я выше пояснил, почему так делать нельзя. Отношение из 4 варианта не может быть мультиполигоном. По смыслу оно более всего близко к отношению type=building, но у него отсутствует outline, и вместо этого все теги здания расположены на отношении. То есть, это вообще ни к селу ни к городу.
Я перечитал вики и да, я был неправ, такой вариант и правда допускается. Но он ничем не лучше https://img-fotki.yandex.ru/get/4425/19662219.9/0_11c00c_415bc89f_orig.png
И там, и там будет по два полигона и одному отношению, то есть никакого выигрыша в простоте обозначения нет. По сути, предлагается “вычитание” частей вместо “сложения”. Добавление новых частей тоже ничего не изменит. А здания на стилобатах вообще методом вычитания мапить получается сложнее, чем сложением нижней части и башен. Но если кому-то нравится, пожалуйста, пользуйтесь.
Да, все отношения на моей картинке - мультиполигоны.
Полностью поддерживаю. На здании должны стоять теги максимальной этажности и высоты, в том числе и для этого.
Изначально vertical/horisontal - личная инициатива Dinamik’а. Он сам предложил и сам написал статью в вики. До него никто этого не использовал. Сейчас использую я, но только чтобы пометить здания с частями. Разделение vertical/horisontal/mixed мне самому кажется малополезным и в ряде случаев неоднозначным.
Проблема совершенно воображаемая, вообще-то…
“Просто” и “сложно” - понятия субъективные. Для кого-то “просто” - это единообразно (в т.ч. со всем остальным), для кого-то - “минимум тегов”.
Нынешняя схема вместе с классическими мультиполигонами позволяет описать что угодно. И “бублики” - тоже. И обеспечивает нормальную обратную совместимость.
Прискорбно, что я оказался неубедительным. Труднее всего обращать внимание на очевидные вещи в устоявшейся сфере.
Безусловно. Однако, полный набор функций/приёмов/возможностей и неполный — объективный параметр (в сравнении двух систем, подходов, инструментов). Сейчас выбор схемы не может быть равновероятным. Приходится склоняться либо только к мультиполигонам, либо комбинировать. И это при том, что для решения «поставленной задачи» достаточно «протолкнуть маленькую поправку», что, в свою очередь, встречает стойкое сопротивление заинтересованного сообщества. Мне это кажется иррациональным, сродни «традициям и устоям».
Чтобы быть убедительным, нужно строить свое объяснение по вполне простому принципу, принятому в научной среде (да-да…).
- описать существующее положение дел
- описать свою гипотезу, дав ей предварительное объяснение
- описать выводы из своей гипотезы (предложить решение)
- проверить, на сколько это решение реально соответствует искомому результату.
То, что вы предлагаете (“маленькая поправка”) во-первых, не до конца вяжется с существующим принципом работы с геометрией, во-вторых, порождает ситуацию конкурирующих методов.
Нарушать стереотипы (по которым действует куча людей) ради элегантности решения, ведущего к умножению методов - непродуктивно, потому что: а) существующая схема не является идеальной, но она не является негодной, б) есть куча людей, которые вполне законно привыкли пользоваться существующим методом, в) умножение числа методов - плохо с точки зрения использования (потому что нужно определять, какой метод используется и вообще держать несколько, а не один в голове при разработке), г) элегантность решения не является самоценной, а должна служить только реальному улучшению и т.п.
В том, чтобы сохранить используемый метод я не вижу ничего плохого и неправильного.
Вы можете провести простое, по пунктам, сравнение того, что вы предлагаете и того, что уже существует? Это будет куда понятнее “заинтересованному сообществу”.
Можно попробовать сопоставить, расставляя гирьки-аргументы на чаши весов.) Будет проблема весомости аргументов (для каждого своя), но от этого никуда не деться.
Мультиполигоны универсальны, применимы не только в разрезе топика. Они появились значительно раньше, имеют широкую поддержку, описывают любую плоскую геометрию (отношениями и тегами мы придаём ей объём).
Предложенная позже Simple 3D Buildings — узконаправленна. Но в этом и её плюс, т. к. в ней ничего лишнего (наоборот — даже нехватка). Лишним я считаю чрезмерное усложнение структуры мультиполигона-здания. Выражается оно в необходимости сильного дробления линий на сегменты, из которых в итоге «собираются» те же линии, проделывается условно двойная работа. Это направлено на исключение накладывающихся точек (и линий, из них состоящих), но создаёт сложную иерархию отношений, привязанных к сегментам.
Фактически более-менее сложное здание превращается в адский набор мультиполигонов-франкенштейнов, состоящих из лоскутов, неоднократно задействованных в разных, но сопряжённых частях здания. Т. е. мультиполигоны внутри мультиполигона («финального») — опять условно двойная работа. Во всём этом великолепии трудно ориентироваться даже «первоисточнику», не говоря о стороннем «наблюдателе» (речь о людях-редакторах). Реально трудно — не стоит бахвалиться и заниматься самообманом или показухой.
В Simple 3D Buildings постарались избежать дублирования многих операций и сущностей, «заплатив» за это лишь дублированием точек (и линий), а также внесли элемент интуитивности, гораздо большей прозрачности структуры. Прозрачность — в блочном принципе: «один блок здания - один полигон» и все они — в одном отношении building.
Что-то помешало разработчикам пойти до конца и не оставлять схему в шаге от завершения (который напрашивается сам собой).
Сейчас мы наблюдаем ситуацию, когда картографы «тянутся» к упрощённой схеме (это естественно), но вынуждены прибегать к гибридному способу совмещения двух схем отрисовки. Причины две:
- несамодостаточность Simple 3D Buildings
- принцип «максимальная этажность на внешнем контуре» (хотя, это и не причина, скорее — рудимент старой системы)
Первая легко решается вышеприведёнными поправками. Вторая — надуманная «проблемность совместимости», или «сбора статистики», или «точности данных». Не ясна сфера совмещения (чего и с чем?), а данные — вполне себе точные (они точнее, чем в «традиционном» подходе!) — ничто не мешает извлекать из простых отношений building.
Как-то так
Ух я, во всей схеме, как таковой.
Вам кто-то, грешным делом, обещал документальное подтверждение самоочевидной последовательности появления той или иной схемы картирования зданий? Это был точно не ух я. Мне неитересна точная дата принятия какой-либо из схем. Достаточно тезиса, закреплённого в названии Simple 3D Buildings, что как бы намекает на уже существующее (в документации или на практике) нечто «не Simple»
P. S. Хамство (ага) и левые требования ведут в непродуктивное русло обсуждения.
Я таки уточню, что до Simple 3D Buildings ничего, претендовавшего на массово поддерживаемую схему маппинга трехмерных зданий просто не существовало - были отдельные теги. А эта схема явилась результатом вот этого http://wiki.openstreetmap.org/wiki/2nd_3D_Workshop_Garching Предвосхищая вопрос, а что же делали на первой встрече по 3D, приведу ссылку http://wiki.openstreetmap.org/wiki/3D_Workshop_Garching (переводя на русский - “просто обсуждали”).
Я против рисования отдельными линиями. Когда натыкаешься на такое здание (лесенка, к примеру, хотя она проста, там за ступеньку можно зацепиться), то хрен разберёшь из скольких частей оно состоит и как зацепить нужный тебе полигон. С отношениями всё гораздо проще, там сразу видно куда входит данная линия (ну ладно, не видно, только idшники, но это уже упрощает). Ну и соответственно “как бы здание” высотой 0 этажей, это всего лишь здание, которое расположено под землёй, в то время как на самом деле там в лучшем случае асфальт.
Максимальная этажность избыточна как для карты, пока тебе не нужны допсведения, среди которых и может быть этажность. Вытянуть из входящих отношений можно, но долго.
И вообще, мультиполигоны это хорошо. Пока в JOSM торчат кишки наружу, новичку и будет сложно. Но это его (josm или другого редактора) забота всё порезать на кусочки при необходимости и создать отношение с теми тегами, что пользователь добавляет. Особенно если пользователь нарисовал прямоугольник по уже существующим линиям
Я одно время “развлекался” починкой мультиполигонов, которые “улучшали” в потлаче и айди.
Там не то что кишки наружу, там вообще кровищщща во все стороны! Самый простой и быстрый способ починить - снести всё к чертям и нарисовать заново.
Так что я б поправил фразу. Создавать мультиполигоны - хорошо. Редактировать (особенно если он уже невалидный) - плохо. Этакая write-only штука получается…
Тоже посмотрел, что все концы ведут в этом направлении. Тем более странно останавливаться на достигнутом.
Об этом и речь.