Вот и получается свистопляска с нулями. Это надо иметь перед глазами вертикальный разрез здания, правда, зачем нужен результат сих трудов — никто не сказал (как и то, откуда брать вертикальные разрезы).
Именно. А что мы имеем в результате плясок с нулями? Чехарду.
Количество знать незачем (и оно получается, при необходимости, из простого сложения разных level или layer).
Данных о срезе никаких не получится, потому что отталкиваемся от «пустоты» в виде несуществующей «нулевой земли» (она есть только в реальности, на рельефе и умозрительно или на планах со срезами и т. п.), грубо говоря, все сооружения «висят на плоскости» и смоделировать нормально в таком 3-d эти уровни не получится. Сегодняшнее OSM 3-d выдаёт лишь приближённое подобие формы здания в отрыве от земли (рельефа). Так что к ней ничего при всём желании привязывать категорически нельзя (по-хорошему), это привязывание ветра солнечным лучом.
Порядок «что над/под чем» можно задавать через layer (тоже, кстати, нетривиальная задача в нестандартных условиях, но это чисто техническая, сортировочная информация для «раскидывания» этажей по условной шкале «выше/ниже» и привязки к ним объектов).
Для всего этажа (и он такой всегда один, и обозначен по всему зданию одинаково). На фига козе баян кому-то знать уровень_над_плоскостью_земли_в_данной_части_здания, как предлагается это сейчас?
Но прикол-то заключается в том, что для indoor там, где с «0» считают (и обозначают!) — всё прекрасно ровно до тех пор, пока не появляются на сцену всякие LL, GR, B1 etc. Никто там, просто, лбом больно не «ударился» об эту «новость», потому что мало практикуется сама схема indoor с многоуровневыми интерьерами. А «классические» (для них) «параллелепипеды» выглядят красиво. То же место в гугле можно заценить, кстати.
Также хочу, чтобы была полная ясность в текущем положении дел. Надо понимать и не забывать, что в реальности, на местности, существуют различные уровни земли (по отношению к постройкам, как минимум) в зависимости от рельефа. В виртуальности (OSM) существует только один «уровень земли» (уровень не понятно чего, если честно).
Из-за этой особенности и при существующем подходе априори невозможно построение правильной модели здания, стоящего не на ровной поверхности, а с перепадами высот «нулевого уровня». Части такого здания попросту не «срастутся» (в OSM-модели) друг относительно друга и будут перекосы (смещения), не соответствующие действительному взаимному расположению. И эти перекосы будут тем больше, чем больше перепады высот настоящего рельефа.
По этим же причинам и в этих же условиях заведомо невозможно согласование схемы Simple 3D buildings и Simple Indoor Tagging
Simple Indoor Tagging также становится неадекватной при наличии иных обозначений (как можно видеть из примеров выше).
Всё описанное — отрыв от действительности и полёт в облаках, который приятен до тех пор, пока не упираешься в «потолок реалий». Иными словами, это не рабочие и не согласующиеся подходы в целом. И они не рабочие, взятые по отдельности. Есть только иллюзия работоспособности, созданная на базе «отдельных макетов» (будь то 3D или indoor) и при выполнении определённых условий («тепличных»).
Это надо исправлять?
Надо идти не от сферического коня, а от конкретных задач.
Хочу сделать план второго этажа — делаю выборку всего с level=1.
Соответственно всё, что должно попасть на этот план, должно быть помечено с помощью level=1.
Если что-то не должно попасть, то значит у него level другой.
Если в двух частях здания, сдвинутых друг относительно друга по вертикали, “этажи” воспринимаются людьми как один, пусть и не ровный, то значит и мапить его надо единым level, даже если “уровень земли” у какой-то части окажется на третьем этаже.
Уж определитесь, пляшете от “этаж” воспринимается, или от уровня земли, а то двойные стандарты и все дела. Ну и интересно, что делают буржую когда этажей этак 50+, с земли же не видно?
Продолжу
Факт № 1: Уровня земли (или рельефа поверхности Земли) в OSM нет (т. е. способа оцифровки через некое значение или их набор в БД)
Отсюда факт № 2: Забываем обо всём, что имеет попытку отталкиваться от «ничего» (см. факт № 1)
Факт № 3: С этим надо считаться и трезво смотреть на вещи.
Всё, что нам по силам (как мне видится) пока что — взаимная относительная привязка элементов (имеющих внятное обозначение, сопоставимое с реальными сущностями). Также, как относительное расположение проекций объектов на условную поверхность Земли (попросту — «домиков» и т. п.)
Поскольку разумно оперировать осязаемыми категориями, то для level напрашивается роль метки (под названием «этаж» или «уровень»), показывающей на местности и в устройстве, на каком этаже размещён объект. Значение берётся из реального мира с соответствующих табличек/табло/и т. п.
Для indoor важно взаимное расположение level-ов, для этого подойдёт, например, layer со значениями в виде порядковых числительных от 1 до бесконечности (считая с низу здания, допустим). Так мы можем получить условные плоские срезы-планы этажей в правильном схематическом порядке и с адекватной маркировкой. При этом подходе мы опираемся на реальное взаимное следование этажей здания и реальную их маркировку. Более того, можно вообще проставлять значения layer строго относительно друг друга (полностью по аналогии с эстакадами на дорожных развязках), тогда нет необходимости знать, где же там самый нижний этаж и сколько их всего. Если (при уточнении данных) появляется ещё один нижний этаж/-жи (что весьма маловероятно), то придётся прибегнуть к шкале с нулевыми или отрицательными значениями, чтобы не ворошить уже готовое и не нарушать последовательность.
С 3-d всё гораздо печальнее, но об этом можно поговорить в соотв. теме.
P. S. Ориентироваться надо не на мнения, а на факты, отражающие рассматриваемую ситуацию. Тогда возможны конструктив и подвижки.
Ага, значит порядок взаимного расположения объектов этот тег не показывает? А порядок рисования от чего зависит и что показывает сама отрисовка — можно озвучить?
Вот глас разума! Мне кажется тут возможен отличный компромисс: level:ref для указания надписи, на которую нужно ориентироваться человеку (надпись на кнопке лифта), level - для указания этажа в геометрическом смысле, в большинстве случаев в России level + 1 == level:ref. При этом стоит рекомендовать в первую очередь указывать level:ref т.к. используемое людьми название этажа важнее к хранению (этот пункт впрочем спорен) и его проще определить. Если случай сложный и не понятно, какой нужно указывать level в данной ситуации, то и фиг с ним.
Какие-нибудь соображения мешают остановиться на такой трактовке? Может стоит задокументировать в русскоязычном разделе вики?
а я бы предложил вместо building:levels использовать нечто с перечислением этажей вроде levels_above_ground=1-10,service,10-24 и levels_under_ground=0,-1,-2. или levels_under_ground=А,B,C. Перечисляем этажи от уровня земли вверх и вних так, как они обозначены в здании. А service, например, будет технический этаж.
Точнее — в смысле порядка следования этажей относительно друг друга.
Надо постучать в дверь ребятам, занимающимся indoor, чтобы они переосмыслили ситуацию с level, а также стали обрабатывать level:ref.
addr:floor мне попадался в существующих данных, level:ref - нет. Если надо будет “этаж” от “уровня” отделить, тогда “level” лучше не писать в качестве части ключа обозначения этажа. addr:floor также подходит как собственно часть адреса.
По-моему, предложение об использовании level:ref=* (и addr:flat) дельное. Это устранит неоднозначность в тех случаях, когда хочется только указать номер этажа POI, и нет цели построить 3D-модель здания. Правда, неоднозначность и level=* всё равно остаётся, и, похоже, мы ещё не раз к этому вернёмся
А building:levels является эрзацем (неполноценным, между прочим) для тэга height и с ним есть заморочки (и хитрые обозначения), связанные с пресловутым уровнем земли (которого — напомню: в OSM нет, как сущности, поскольку всё расположено на одной плоскости, как на бумажной карте).
building:levels годится только для того, чтобы нарисовать в 3d окошки в здании и некую усреднённую высоту вывести. Никакого отношения к обозначению level этот тэг не имеет, равно и наоборот.
