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

То есть в месте пересечения двух ЛЭП в разных уровнях верхние провода должны проходить только по мосту, согласно валидатору? :smiley:

нет, это касается дорог.

Исходя из предложения LLlypuk82, возможна следующая схема: в level пишется фактическое обозначение. Рисуется полигон indoor = level, на который проставляется также layer. level:ref не используется. POI привязываются к полигону indoor = level через попадание в его контур и одинаковый level.
Плюсы:

  1. в level пишется фактическое обозначение
    Минусы:
    1)необходим полигон indoor = level для каждого этажа. Без него схема неработоспособна;
    2)необходимо учитывать также объекты, расположенные над и под зданием;
  2. параллельное использование данной схемы и SIT => неоднозначность значения level, что особенно проблематично именно для данной схемы.
    Итого: зачем это всё? Ради одной-единственной мнемоники level?

Вероятно, бесполезно всё это писать, но… Для освежения в памяти смотрим примеры по ссылкам из этого поста.
Принимаем за факт, что на текущий момент рабочей и описанной схемы тегирования, покрывающей и такие случаи, нет.
Если хотим выстраивать последовательность и взаимное расположение поэтажных планов через level с числовыми значениями, то прописываем это прямым текстом в справке (в обязательном порядке убирая белеберду с «землёй» и делая акцент только на соответствии значений в привязке к иерархии этажей между собой). Вводим обязательное обозначение наименований этажей через level:ref (беря значения по месту, которые принимают вид не только числовой и не имеют стандартной понятной последовательности). Оповещаем разработчиков действующих сервисов и приложений о внесённых корректировках и согласованиях.
Это позволит:

  1. Унифицировать схему тегирования, позволяя покрывать большинство известных кейсов применения.
  2. Не трогать уже внесённые данные по level (а лишь дополнить их level:ref).
  3. Малыми усилиями адаптировать приложения для корректной работы.

У нас на всю страну 34к тегов и 99.999% из них - целое число. То бишь не наша это печаль. Вот устранить «белеберду с землёй» надо. Вопрос как. Принять новую схему (тоже эпичный квест) означает заново вносить все значения. Если предположить, что level=0 внесли маперы, которые читали вики и это первый этаж, и все отрицательные значения тоже верны т.к. просто означают подземные уровни, то это даёт нам >50% условно достоверных значений. Можно массово заменить 0 на 1, а на остальное навесить fixme. Но кто ж на такой вандализьм решится…

Ничего в существующих данных исправлять не надо. Нули и единицы (с минусом и без) в значениях level будут влиять только на логику взаимного расположения этажей (и соответствующих элементов интерфейса приложений). При этом подписаны (маркированы) эти элементы будут через level:ref. Также и в свойствах POI будет указано значение level:ref.
Сейчас то, что кое-как работает, может выглядеть корректно только благодаря удачному совпадению маркировки в зданиях и собственно «традиционному» обозначению иерархии (выше/ниже) через «нули и единицы с минусами». Потому что по факту level выполняет двоякую роль (2-в-1): и маркера, и распределителя очерёдности следования. Что в корне неверно и давно требует исправления.

Лично я вношу по вики (для первого этажа level=0). Основной аргумент, который мне говорили противники такого решения: «В OsmAnd отображается неправильно», поэтому считаю необходимым добавить issue чтобы level:ref перезаписывал level для POI (думаю это будет сделать не очень сложно). А пото́м (со временем) проверим все ранее внесённые данные. Думаю чтобы это самое правильное решение.

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

Вот только для этого нужно принять новую схему, адаптировать софт и с нуля заполнить новый тег, который в большинстве случаев будет дублировать level.
Альтернативный вариант - считать, что по-умолчанию level=layer, а для редких исключений использовать вымышленный level + level:ref в качестве метки. Но при этом требуется коррекция данных. По крайней мере для нашей страны. Вопрос - что проще.

Альтернатива всегда есть: не делать ничего и расписаться с несостоятельности.
Дополнения нужны самые минимальные (и в схеме, и в софте).

А всё потому, что нет нормальной системы голосования за изменения. Вот бы чем следовало заняться в первую очередь…

Именно для этого и нужен этот тег.
Изначально тег level вводился для обозначения этажей, но:

  • он используется в случаях, если обозначения этажей начинается с 0 (то есть 0, 1, 2, …). Если счёт начинается с 1 (как в России), то многие пишут не по вики, а чтобы в навигаторе отображалось “как им хочется”);
  • в случае пропуска этажей (в некоторых странах пропускают нумерацию этажей, например 4 или 13);
  • часто некоторые этажи обозначают не цифрами, а буквами (например для подземной парковки B1, B2, C, …).
    Опять же, если указывать level в соответствии с вики, то тег level:ref существует именно для того, чтобы решить эти проблемы и чтобы можно было указать то обозначение этажа, которое нужно.

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

Нет, если он дублирует, то вносить его не обязательно. Основная проблема в том, что многие люди уже внесли “неправильно” (не по вики). Если было бы можно исправить всё в “по вики”, то либо тег level:ref перезаписывает level, либо при постобработки для России (и для других стран) если level >= 0, то увеличиваем значение на +1.
Сейчас в России около 17 тысяч значений level > 0, часть из них внесено неправильно. Если бы была возможность проверить каждое значение, то мы сможем привести базу к единому стандарту. Но, опять же, задача достаточно сложная и не знаю как сообщество отреагирует на это.

Да, всё так. Видимо я неправильно понял фразу «добавить issue чтобы level:ref перезаписывал level для POI». Мы говорим об одном и том же.
Но снова про неправильность, перезапись и постобработку. Это не будет иметь никакого значения. Автоматически, по умолчанию мы получаем рабочую схему, потому что level влияет только на очерёдность этажей (мы тогда видим только сам результат: правильную очерёдность, забываем про несовпадение маркировки и про поиски и вычисления «земли»). Плюс к этому мы имеем правильную маркировку. Поэтому перезаписывать тоже ничего не нужно, эти данные важны и будут важны для правильной привязки соответствующих этажей к элементам интерфейса (подписанным через level:ref)

Проект международный, а в разных странах принята разная схема нумерации этажей. В Чехии тоже нумерация идёт от нуля. Т.е. первый этаж - přizemi (пршисеми, приземный), второй этаж - první (првни, первый), подземный этаж (например, гараж) - podzemí (подземи). Поэтому в лифте нужно разбираться, чтобы уехать не туда куда не надо.

Читал что для чехов этаж - это куда нужно подниматься по лестнице. Т.е. для них этаж это сколько лестничных пролётов им нужно преодолеть. Т.е. первый этаж == подняться на 1 уровень по лестнице.

Ну а поскольку проект родился в Англии, где нумерация идёт от 0, то именно эта схема была выбрана как базовая. Тем не менее, такая схема имеет распространение и за пределами Англии.

Обсуждаемая проблема лежит вне плоскости «кто как считает или называет этажи». Проблема не затрагивает «уровни земли».
Смотрим на »примеры« из реальности.
Проблема в том, что обозначение этажей и их взаимное расположение нельзя обозначать через один и тот же параметр.

Я, если честно, не очень понимаю, в чём проблема.

  1. Что этажи начинаются с 0 и 1-й и -1-й это просто этажи выше или ниже нулевого? Ну таково default value для проекта.

  2. То что есть здания, построенные на рельефе и сложно сказать сколько в нём этажей? Но это ничем не отличается от случая разноэтажного здания на плоском фундаменте. Только здание “перевёрнуто”. Переверните его “вверх ногами” и получите то же здание на котором проще считать этажи. Только для 3D редактора придётся повозиться, но это самостоятельная тема.

  3. То что внутри здания некоторые части могут иметь самостоятельную нумерацию этажей типа театров или других зданий со сложной конфигурацией? Ну там мапьте эти части раздельно. Фактически это несколько объёмов под одной крышей и понятие “этаж” не совсем применимо к зданию в целом а относится к конкретной части здания.

  4. ?

Вот ещё примеры (никаких глупостей и выдумок, чётко и понятно):

  1. https://yandex.by/maps/157/minsk/?feedback=map%2Fedit&feedback-context=map.controls&ll=27.549470%2C53.908545&z=18.41
  2. https://yandex.by/maps/213/moscow/?ll=37.655643%2C55.776553&z=19.12
  3. https://yandex.by/maps/213/moscow/?ll=37.659773%2C55.757215&z=18.37
  4. https://yandex.by/maps/12/smolensk/?ll=32.043246%2C54.794765&z=19.24 (с нулевым)
  5. https://yandex.by/maps/213/moscow/?ll=37.630476%2C55.744546&z=19.56
  6. https://yandex.by/maps/213/moscow/?ll=37.581775%2C55.747536&z=19.36 (с нулевым)
    Есть ноль — значит есть, нету — и не нужен, всё прекрасно работает.

Особенно важные ключевые примеры:
7. https://yandex.by/maps/213/moscow/?ll=37.479834%2C55.705348&z=18.56
8. https://yandex.by/maps/213/moscow/?ll=37.467011%2C55.702602&z=19.16
9. https://yandex.by/maps/2/saint-petersburg/?ll=30.379474%2C59.870122&z=19.2
10. https://yandex.by/maps/2/saint-petersburg/?ll=30.255097%2C59.988588&z=19.8
11. https://yandex.by/maps/2/saint-petersburg/?ll=30.314008%2C60.048633&z=18.19

В Испании ещё круче:

https://www.youtube.com/watch?v=gEGVTFPME4o&t=218s

В зависимости от дома “первый этаж” может быть от физического первого до четвёртого. :slight_smile: