Поставим точку в вопросе «level=*»

Удобно использовать одну и ту же схему.

Как объявим схему, так и будем пользоваться.

Для наглядной визуализации.

Потому что удобно отсчитывать от уровня земли.

Про здания на сложном рельефе с уклоном (перепад > 1 этажа) можно просто договориться, что считать точкой отсчета.

Схему чего? Это разные схемы для разных сущностей.

Объявлена только методика получения информации для значения, НО не назначение тега. Выводить из методики назначение — глупость в квадрате (строительство дома, начиная с крыши).

Какой визуализации, вы на Земле всё ещё или куда-то улетели? Ответьте не в общем, что-то подразумевая (читай: не о чём), а конкретно.

Это мало того, что ни разу не удобно, так и не работает адекватно действительности. Потому что получается привязка к сферическому уровню земли (которого в OSM нет), а также в принципе не позволяет сделать хотя бы относительную привязку частей здания (по отношению друг к другу). Для такой привязки следовало бы отталкиваться от максимального уровня крыши.

Это что же, например?

Так им и флаг в руки. Они ж не идиоты и не обозначают свой ground floor «1» (потому что принято у них «0»). Сгоряча кто-то там придумал, что, дескать, берём значение в привязке к уровню «земли» методом подсчёта (на кой это было приплетено — загадка для меня) (в OSM это означает «привязка ни к чему, от балды»), потому что у него не хватило соображалки проверить, а соответствует ли такое «обозначение» (потому что оно уже становится неким вычислением, судя по указанному методу!) во всём мире (по странам) и повсеместно (локально) тем картинкам на планах/схемах/реальных_этажах_и_уровнях? Оказывается — нет. Но документация уже высечена в граните и не подлежит прикосновению всяких там. Ибо надо упереться рогом в этот гранит или биться о него головой, но не признавать разжёванной тут простой вещи: значение level ни при каких обстоятельствах не должно быть вычисляемым, потому что принимает в ряде случаев нечисловые, т. е. невычислимые значения. Берётся же оно в готовом виде по месту применения, что автоматически снимает все противоречия (попутно исключая всякий бред с уровнями земли, моря и стратосферы) и даёт адекватную информацию для реального использования в приложениях (что уже есть, кстати).
Итак, необходимо: исправить вики-страницу (как минимум — русскую) и перевод подсказки-рекомендации в iD.

Что значит вычислимый?

Если 13 этажа “нет в здании”, значит после 12 идёт 14.

Про системы нумерации всё на Википедии было сказано
https://en.wikipedia.org/wiki/Storey#Consecutive_number_floor_designations

NA convention вообще различается сама с собой (и с 0, и с 1)

Есть два тега
building:levels=* - кол-во этажей
level=* - что здесь вводится?

Нужно дописать что паркинговые этажи могут быть со своими номерами, отличными от 0, 1, 2:

LL3, LL2
B3, B4

На английской Википедии (не на вики OSM) как раз всё разжевано.

На OSM wiki нужно написать, что первый наздемный этаж (который на уровне с землёй, “Ground level storey”) в OSM принято считать 0 (level=0 у объектов), если на местности нет табличек с номером или идентификатором этажа.

На OSM wiki не сказано как тегировать метки этажей (11, 12, 14). Simple indoor страница говорит что level=* порядковые (11, 12, 13 или 10, 11, 12)

Не все торговые центры имеют фунциональные этажи на несколько пролётов (строительные).

Касательно “определенить этаж над землёй” я бы вообще не заморачивался.

Если на “цокольный” или подвальный этаж есть вход с земли, то он - 0.

Пологие выезды с парковок не считать за 0. Территория подземного паркинга это скорее всего level=-1, но сам въезд - под вопросом.

Если этажи идут в разнобой, то нужно определить самому где более подходящий “0” этаж (справа сверху) относительно менее спорного 0 (слева, сразу у входа)
https://wiki.openstreetmap.org/w/images/thumb/c/c8/Indoor2.0_buildingpart.svg/600px-Indoor2.0_buildingpart.svg.png

Иногда ТЦ довольно тупые и если снаружи 4 строительных пролётов можно отличить, то и внутри 4 разных level=*.

Иногда “не везёт” и ТЦ отделывают так, что не понятно: сколько этажей внутри - по фасаду здания, однако, местный всё так же хорошо определит общее кол-во этажей. Отсчитать от 0 нужную цифорку это мелочи.

Не нужно забывать что level=* это уже indoor схема тегирования. indoor в первую очередь нацелен для схем зданий по этажам и навигации.

Грубо говоря level=* нужно тегировать так, чтобы каждый вертикальный срез здания:

  1. количество разных level=* - отвечало сколько этажей в этом срезе или вертикальной части здания
  2. отвечал какие объекты внутри среза выше других
  3. порядковые числа (12, 13, 14; -1, 0, 1), а не метки этажей (12, 14, LL1, LL2) для них - нужен отдельный тег т.к на
    http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging они не упоминаются, а только простые случаи идут как -1, 0, 1

Возникло недопонимание что level=* должен быть логичен для всего здания одновременно: все level=3 на одном уровне земли - нет, такого не было соглашения, если я правильно всё помню.

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

Ничего не указывать — самый оптимальный вариант.

Вот и получается свистопляска с нулями. Это надо иметь перед глазами вертикальный разрез здания, правда, зачем нужен результат сих трудов — никто не сказал (как и то, откуда брать вертикальные разрезы).

Именно. А что мы имеем в результате плясок с нулями? Чехарду.
Количество знать незачем (и оно получается, при необходимости, из простого сложения разных level или layer).
Данных о срезе никаких не получится, потому что отталкиваемся от «пустоты» в виде несуществующей «нулевой земли» (она есть только в реальности, на рельефе и умозрительно или на планах со срезами и т. п.), грубо говоря, все сооружения «висят на плоскости» и смоделировать нормально в таком 3-d эти уровни не получится. Сегодняшнее OSM 3-d выдаёт лишь приближённое подобие формы здания в отрыве от земли (рельефа). Так что к ней ничего при всём желании привязывать категорически нельзя (по-хорошему), это привязывание ветра солнечным лучом.
Порядок «что над/под чем» можно задавать через layer (тоже, кстати, нетривиальная задача в нестандартных условиях, но это чисто техническая, сортировочная информация для «раскидывания» этажей по условной шкале «выше/ниже» и привязки к ним объектов).

Для всего этажа (и он такой всегда один, и обозначен по всему зданию одинаково). На фига козе баян кому-то знать уровень_над_плоскостью_земли_в_данной_части_здания, как предлагается это сейчас?
Но прикол-то заключается в том, что для indoor там, где с «0» считают (и обозначают!) — всё прекрасно ровно до тех пор, пока не появляются на сцену всякие LL, GR, B1 etc. Никто там, просто, лбом больно не «ударился» об эту «новость», потому что мало практикуется сама схема indoor с многоуровневыми интерьерами. А «классические» (для них) «параллелепипеды» выглядят красиво. То же место в гугле можно заценить, кстати.

А теперь смотрим на обозначение:
Бразилия1
Бразилия2
USA1
USA2
Австралия1
Австралия2

Также хочу, чтобы была полная ясность в текущем положении дел. Надо понимать и не забывать, что в реальности, на местности, существуют различные уровни земли (по отношению к постройкам, как минимум) в зависимости от рельефа. В виртуальности (OSM) существует только один «уровень земли» (уровень не понятно чего, если честно).
Из-за этой особенности и при существующем подходе априори невозможно построение правильной модели здания, стоящего не на ровной поверхности, а с перепадами высот «нулевого уровня». Части такого здания попросту не «срастутся» (в OSM-модели) друг относительно друга и будут перекосы (смещения), не соответствующие действительному взаимному расположению. И эти перекосы будут тем больше, чем больше перепады высот настоящего рельефа.
По этим же причинам и в этих же условиях заведомо невозможно согласование схемы Simple 3D buildings и Simple Indoor Tagging
Simple Indoor Tagging также становится неадекватной при наличии иных обозначений (как можно видеть из примеров выше).
Всё описанное — отрыв от действительности и полёт в облаках, который приятен до тех пор, пока не упираешься в «потолок реалий». Иными словами, это не рабочие и не согласующиеся подходы в целом. И они не рабочие, взятые по отдельности. Есть только иллюзия работоспособности, созданная на базе «отдельных макетов» (будь то 3D или indoor) и при выполнении определённых условий («тепличных»).
Это надо исправлять?

Надо идти не от сферического коня, а от конкретных задач.
Хочу сделать план второго этажа — делаю выборку всего с level=1.

Соответственно всё, что должно попасть на этот план, должно быть помечено с помощью level=1.
Если что-то не должно попасть, то значит у него level другой.

Если в двух частях здания, сдвинутых друг относительно друга по вертикали, “этажи” воспринимаются людьми как один, пусть и не ровный, то значит и мапить его надо единым level, даже если “уровень земли” у какой-то части окажется на третьем этаже.

Уж определитесь, пляшете от “этаж” воспринимается, или от уровня земли, а то двойные стандарты и все дела. Ну и интересно, что делают буржую когда этажей этак 50+, с земли же не видно?

Это же OSM, тут сколько людей, столько мнений плюс один.

Продолжу :slight_smile:
Факт № 1: Уровня земли (или рельефа поверхности Земли) в OSM нет (т. е. способа оцифровки через некое значение или их набор в БД)
Отсюда факт № 2: Забываем обо всём, что имеет попытку отталкиваться от «ничего» (см. факт № 1)
Факт № 3: С этим надо считаться и трезво смотреть на вещи.
Всё, что нам по силам (как мне видится) пока что — взаимная относительная привязка элементов (имеющих внятное обозначение, сопоставимое с реальными сущностями). Также, как относительное расположение проекций объектов на условную поверхность Земли (попросту — «домиков» и т. п.)
Поскольку разумно оперировать осязаемыми категориями, то для level напрашивается роль метки (под названием «этаж» или «уровень»), показывающей на местности и в устройстве, на каком этаже размещён объект. Значение берётся из реального мира с соответствующих табличек/табло/и т. п.
Для indoor важно взаимное расположение level-ов, для этого подойдёт, например, layer со значениями в виде порядковых числительных от 1 до бесконечности (считая с низу здания, допустим). Так мы можем получить условные плоские срезы-планы этажей в правильном схематическом порядке и с адекватной маркировкой. При этом подходе мы опираемся на реальное взаимное следование этажей здания и реальную их маркировку. Более того, можно вообще проставлять значения layer строго относительно друг друга (полностью по аналогии с эстакадами на дорожных развязках), тогда нет необходимости знать, где же там самый нижний этаж и сколько их всего. Если (при уточнении данных) появляется ещё один нижний этаж/-жи (что весьма маловероятно), то придётся прибегнуть к шкале с нулевыми или отрицательными значениями, чтобы не ворошить уже готовое и не нарушать последовательность.
С 3-d всё гораздо печальнее, но об этом можно поговорить в соотв. теме.
P. S. Ориентироваться надо не на мнения, а на факты, отражающие рассматриваемую ситуацию. Тогда возможны конструктив и подвижки.

Не стоит layer впутывать. Это же просто порядок рисования.

Ага, значит порядок взаимного расположения объектов этот тег не показывает? А порядок рисования от чего зависит и что показывает сама отрисовка — можно озвучить?

Внутри одного этажа level может случится несколько layer.

Вот глас разума! Мне кажется тут возможен отличный компромисс: 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.