Редактор iD

Отдельной темы по редактору не нашел, поэтому заведу новую.

Обнаружил глюк в русской версии: у многих пользователей, отмечающих грунтовки hw=track, добавляются такие теги:
tracktype=Мягкая:_неукатанный_грунт,_песок,_трава и т.п.

Т.е. вместо tracktype=grade1…5 в значение тега подставляется русскоязычное описание. Кто-то может поправить?

Нужно тикет написать сюда - https://github.com/openstreetmap/iD/issues

а поймут там касаемо русскоязычной версии?
эх, нет у меня регистрации на github…

Скорее всего эта проблема затрагивает не только рус. версию…

https://github.com/openstreetmap/iD/issues/3129

спасибо!

Только что обновили редактор на 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. Единственный нюанс в том, что этаж — не обязательно часть адреса, хотя не вижу проблемы делать его таковым «принудительно» (но кто-то видит).
Итог таков: текущий подход не даёт (даже потенциально) никаких увязок, а только вносит неразбериху и дезинформацию.