Нужно тикет написать сюда - https://github.com/openstreetmap/iD/issues
а поймут там касаемо русскоязычной версии?
эх, нет у меня регистрации на github…
Скорее всего эта проблема затрагивает не только рус. версию…
спасибо!
Только что обновили редактор на osm.org, где баг поправлен. Также там кнопка «сохранить» меняет цвет с накоплением несохранённых правок.
Есть поле «этаж» (level) с пояснением вида: «первый=0». Что не является верным во всех случаях и вводит в заблуждение => ошибочное указание этажей. Уместнее было бы «подсказывать»: «нумерация, применённая в здании». Очевидно, что если в ТЦ повсюду надписи «1, 0, -1, -2» — это один случай (в каких-то странах это повсеместно, вероятно). Но преимущественно в странах СНГ (и не только, полагаю) это далеко не так, а встречается двоякая система отсчёта этажей. При этом, обычные жилые здания (или офисные) чаще не имеют «нулевого» этажа (и лифтовые кнопки об этом красноречиво намекают). Офисы/гостиничные номера часто нумеруются «101, 235, 502», где первая цифра указывает на этаж (без учёта «нулевого»).
Почему в заблуждение? В тег level пишется же не то, как этаж называют в здании, а его расстояние от поверхности земли. Это и пытаются сказать пояснением.
А кому это надо? Чтобы совсем ясно было: как это использовать? Вот как использовать адекватное местности (зданию) обозначение: смотрим в свойствах искомого объекта «этаж N», находим по местным обозначениям «этаж N» и на нём — искомый объект.
Из-за того, что в каких-то странах (или на каких-то отдельных объектах) принято вести отсчёт этажей (и нумерацию на табличках), начиная с 0 — теперь всем остальным бегать вокруг здания и определять, где там «поверхностные» этажи начинаются, а потом пальцем отсчитывать нужный или проводить перерасчёт с учётом «погрешности»? Что-то не улавливаю здравого смысла в такой затее.
категорически поддерживаю LLlypuk82
Тогда такой вариант: на работе стоит здание на склоне относительно центрального входа у него три этажа и два подвальных, но т.к. здание стоит на склоне, то с нижнего “подвального” этажа есть нормальный выезд в нижнюю часть склона. Вопрос от какой “земли” вести нумерацию этажей ??
Есть еще в городе подобный торговый центр, с подвального этажа есть выход на парковку в низу склона.
На мой взгляд level должен отображать реально имеющуюся нумерацию этажей.
Думаю, прежде всего — для поэтажного и прочего 3D-моделирования. Иначе нет шансов определить, где именно в конкретном здании находится этаж, тем более, что часть их может быть вообще обозначена буквами, а не номерами. Например, где находится этаж, обозначенный на табличках и лифте как “M”? Где его размещать в 3D-модели? Схема обозначения этажей — она специфична для каждого отдельного здания, а не местности (особенно это заметно в торговых центрах). К конце концов, для указания этажей в локальных обозначениях есть addr:floor.
Начинать нумерацию от нуля, единицы или какого другого числа — особой разницы в общем-то нет, лишь бы это было глобально единообразно, а не менялось от здания к зданию. От нуля это даже логичнее, потому что тогда номер — это просто расстояние от поверхности земли. А поверхностные этажи все равно обнаружить придется, если планируется указать building:levels.
Здания на склонах — это всегда проблема, что для подсчета количества этажей, что для их номеров, к ним все равно требуется индивидуальный подход. И видимо, какую-то сторону придется принять за более важную.
Ориентированность на 3-D модель — хорошо, но, всё-таки, не за счёт ухудшения для 2-D, которая входит в явное противоречие с таким подходом.
Если на то пошло, то и количество этажей в «советских» (да и всех остальных) 5-этажках надо проставлять как «building:levels=4» и т. д. Для единообразия. Что-то здесь не клеится.
Для ранжирования по вертикальной шкале — если обозначения буквенные — никакие системы отсчёта не помогут, я полагаю.
dair, ваш вариант решения поставленной задачи?
По крайней пере, можно для этих целей использовать layer, а level оставить сугубо, как маркер-значок, привязанный к местной «системе координат».
P. S. Ох уж эти «первопроходцы»…
Нужно всем, кто не хочет гадать что именно имелось в виду маппером, а использовать значения. Потому что система обозначений одна для всех и должна обозначать одно и то же. В принятой схеме этот тег обозначает физический номер этажа. Первопроходцами были британцы, поэтому закрепилась их система нумерации. Нам может и не очень удобно, но лучше делать единообразно, чем городить разнобой. Удобство физической схемы в том, что она удобнее для использования, для рендеринга и конвертации. Например её легко можно сконвертировать под разные предпочтения пользователя карты.
Использовать же логические номера - это будет хаос, аналогичный тому, что возникает в name без указания языка.
По building:levels »здесь« неплохо расписано (было бы круто и русскую версию актуализировать).
Вообще, во всей этой «кухне» переплетаются понятия «исчисление (подсчёт количества)» и «нумерация (по сути — маркировка)», а также «дифференциация по расположению» (чистый низ/подвал-середина-чистый верх/мансарда). Не затронуты только полуподвальные помещения, которые обсуждались на форуме чуть-чуть, помнится.
Т. е. для building:levels мы ведём, всё-таки, подсчёт (и тогда с 5-этажками всё в порядке), а для level — нумерацию (сиречь маркировку).
Схемка про level Все эти хитросплетения с разрезами здания имеют сомнительную применимость на практике — во-первых, а во-вторых — снова не ясно, для чего это делать.
Русская страница level (всё правильно замечено про неработоспособность, а также упоминаются 0.5 и 1.5 значения)
А »тут« ещё и про максимальные/минимальные этажи и про «несуществующие» (так что маркировочка это, на большее не тянет, как ни крути).
Помимо layer, можно применять, например, такой тег «levels=B;G;1-3», приняв за правило, что ранжир снизу-вверх и слева-направо соответственно. Подсмотрел »здесь«. Будет хорошо согласовываться с level и показывать очерёдность следования для 3-D поэтажного планирования.
А какая задача поставлена-то? Про это вроде не было ничего. Если она в том, что указать способ найти этаж, на котором, например, расположен магазин в торговом центре (какую кнопку нажать в лифте, не задумываясь о геометрии здания), то addr:floor. А сугубо геометрические теги, типа level (который есть просто Z-координата, но измеренная не в метрах, а этажах) оставить для 3D.
Если мы моделируем отдельно взятое здание в вакууме, как сейчас делают indoor-рендереры, то этого, действительно, достаточно. Если же мы пытаемся смоделировать чуть больший участок пространства, например, в общем рендере с элементами 3D в стиле f4map, то этого уже не хватит — требуется увязать здание с окружающими объектами.
Глядя на приведённую наглядную схему, не ясно, как вы собираетесь это делать. Есть некая корреляция с рельефом, но сам он не линеен и слишком заковырист (в отличие от этажей), и вообще о нём нет данных (и пока не известно, появятся ли они).
addr:floor в такой ситуации ни чем не лучше и не хуже level. Единственный нюанс в том, что этаж — не обязательно часть адреса, хотя не вижу проблемы делать его таковым «принудительно» (но кто-то видит).
Итог таков: текущий подход не даёт (даже потенциально) никаких увязок, а только вносит неразбериху и дезинформацию.
Есть два разных тега - building:levels и level, они друг с другом реально никак не связаны, к большому сожалению.
Вторая проблема - исчисление/нумерация в любом случае идет от уровня земли, хотя здание может стоять на склоне, обе его части могут иметь одинаковое количество надземных этажей, однако здание целиком образует ступень. Для такого случая вообще не существует способа моделирования, который не вносил бы ложную информацию (форму здания можно смоделировать, если выбрать общую точку отсчета для всех building:part, но часть этажей будет обозначена ложно, как подземные). В этом Simple 3D несовершенна.
Мой подход к этому вопросу - использовать 3D там, где это не порождает противоречия, а где порождает - не использовать, до лучших времен.