Как обозначать? (Part 1)

Вы не путайте, пожалуйста, объективное существование свойства и объективность его оценки. Это совершенно разные вещи. Хрестоматийный пример, который дан в Вики на тему субъективности свойств, под такую ситуацию тоже подпадает: понятия “узкий” и “широкий” или “низкий” и “высокий” объективно существуют, но пока не определен объективный критерий их разграничения (после какого размера “узкий” становится “широким”), вносить такие понятия в OSM - бессмысленно. Но, тем не менее, для группы товарищей объективное существование свойства (но не объективность его оценки) уже причина, чтобы пытаться на глаз что-то отмечать: “ну я же вижу, что это есть, чё бы это не отметить?”

Свойства с субъективным критерием оценки не обладают также качеством подтверждаемости (verifiability), потому что Вася посмотрит, и на глаз скажет, что это “ровно”, а придет Петя и возмущенно скажет “какая ерунда, это же совсем не ровно”.

Вот и удивляйся потом, что люди в описании education 2.0 простых вещей понять не смогли. Тут - та же фигня. Логика предельно простая.

Никто ничего не путает (где на это хоть намёк?). Чёткие критерии и системы оценки — это одна реальность (по большей части теоретическая, почти виртуальная). Практика (картирование в рамках массового проекта — в данном случае) — иная, более приземлённая реальность.
Кто-то может с применением систем RTK и прочих профессиональных плюшек разметить дорогу, привязать снимок (предварительно проведя и его подготовку, а может и съёмку даже) с точностью в несколько сантиметров, а кто-то использует привязанный по обычным трекам снимок (имеющий меньшее разрешение, не прошедший соотв. обработки и т. п.) с точностью результатов в несколько метров (в лучшем случае). Разница — на порядок, но это не отменяет возможности картирования с пом. тех ресурсов и инструментов, которые доступны и не требуют спецнавыков, оборудования и ПО, хотя и дают заведомо худший результат.
Тут ещё уместно спросить, а кто-то где-то занимается картированием с особой точностью? (OSM имеется в виду). Проскакивала заметка о человеке в Германии, кажется, применяющем RTK-систему (что именно он картирует — не помню) и на форуме показывал результат Sergey Astakhov, если не ошибаюсь (бордюры, заборы, газоны и проч. «мелочи»).
Совершенно не важно, придёт ли Петя после Вани и скажет ли «да эта дорога ровная и твёрдая, а не разбитая и рыхлая». С таким же «успехом» придёт Йохан после Дуни и скажет: «та у фас тут стание уехало на 5 метроф». И это — заметим — при возможности оценки в конкретных значениях.
Иными словами: точность — это прекрасно, верифицируемость — замечательно, объективные методики измерений — сказочно. НО кто будет этим заниматься? Вносить, перепроверять, уточнять. Это сделают какие-нибуть роботизированные системы будущего (если на тот момент в этом будет надобность).
На субъективном (столь ненавистном ув. BushmanK) уровне это уже применяется (smoothness, tracktype) и даёт вполне ясное представление о качестве дорог для учёта в планировании маршрутов.
ВАЖНО: да, линейкой ты не сверишь глубину выбоин (не с чем сверять), но зато ощутишь расколбас подвески (или позвоночника) на smoothness=very_bad или smoothness=horrible, а потом побегаешь за техпомощью в виде трактора или др. тягача, когда сядешь на брюхо.

Тут ещё уместно спросить, а кто-то где-то занимается картированием с особой точностью?
А почему бы и нет http://www.openstreetmap.org/traces/tag/rtklib
На субъективном (столь ненавистном ув. BushmanK) уровне это уже применяется (smoothness, tracktype)
Ну а могло быть всё куда лучше: есть поперечные трещины уже не excellent, есть ямы больше 30см - значит bad. Zverik, кстати пытался предвнести критерии, но не взлетело.
Смысл в том, чтобы можно было уточнять, если есть “инструменты”, а не устраивать войну значений.

Если здесь, то не заметил чего-то объективного.

Нет, смысл в реализуемости тех или иных целей. Если цель — помечтать и разойтись, то открываем раздел «Фантазии и сладкие мечты о прецизионной точности». Если цель — накопление достаточно полезных данных (отдавая себе отчёт о степени адекватности), то используем субъективную оценку.
«Достаточно полезные» — данные, на основе которых я могу сделать вывод: «нет, вот в эту Ж я не полезу, а обогну крюком в N км». Если какой-то человек (не супермен, вероятно) обозначил кусок дороги как «очень хреновый», то мне (как такому же обыкновенному человеку) начхать, какого диаметра там выбоины, и насколько широки трещины, и насколько увязают колёса. Мне (о ужас! все в шоке) довольно субъективной характеристики и я избегаю проблем на маршруте (заранее, а не провалившись по колено в луже с глубиномером-палкой в руках и рулеткой в кармане).

Если конкретно расписаны значения и даны примеры (как со smoothness), то объективность уже есть. Другое дело, что точность оценивания свойств будет плавать, но она всегда плавает. Даже совершенно объективные параметры, такие, как ширина тропы (width) в метрах, тоже вносятся “на глаз” с погрешностью. С линейкой никто же не измеряет. Так и со smoothness и с любыми другими значениями, смотрим на описание и пишем значение, с погрешностью плюс-минус одна ступень. Да что там, даже указывая количество этажей у здания можно легко ошибиться на один этаж. Параметр объективный, способ измерения объективный, значение целочисленное, но погрешность от человеческого фактора все равно есть.

Такое будет, если нет расписанных критериев оценки.

Например:
“хорошо укатанный” - колёса горного велосипеда не зарываются в песок, ехать легко
“укатанный с рыхлыми участками” - переднее колесо начинает зарываться, можно проехать, с усилием удерживая руль
“рыхлый” - колёса зарываются, ехать крайне тяжело, требуются навыки езды по сыпучей поверхности
“очень рыхлый” - проехать на горном велосипеде невозможно

И еще дописать примеры про автомобиль. И субъективность исчезла. Разве нет?

По поводу того, что после дождя по мокрому песку можно проехать: ну, в России иногда асфальт в зависимости от времени суток может превратиться в говно, а зимой так вообще surface не к месту. Но мы же описываем то, что есть “в общем случае”, а по правку на погоду пользователь уж пусть потрудится сделать сам. (Сюда же дороги с surface=mud, которые при хорошей засухе могут высохнуть.)

Вот не надо демагогии про то, что “BushmanK ненавидит субъективные критерии”. Не я придумал, что это плохо. Это обоснованное правило, которое закреплено в документации. Так что не сводите это все к личной неприязни или мнению - я всего лишь отстаиваю существующие требования, мешая вам комфортно на них забить. Мне, с одной стороны, не жалко, если кто-то будет отмечать субъективно что-нибудь - мне лично, например, на проблемы велосипедистов просто наплевать, более того, если они потом передерутся из-за того, “хорошо укатанный” тут песок или “рыхлый”, я с удовольствием за этим злорадно понаблюдаю. Но чем больше таких тегов появляется, тем в большей степени это становится нормой для проекта, то есть протолкнуть какой-нибудь еще подобный тег, ссылаясь на существующую практику в духе “ну вот, оно есть и ничего, а документация нам не указ и вообще - херня”.

Что касается критериев оценки - в теории, действительно, можно придумать практические критерии (вместо строгого метода измерения), но как только в этих критериях появляются слова “легко”, “трудно” и т.п., а также для измерения требуется специальное оборудование (горный велосипед вместо обычного, например, или наоборот), вся условная объективность этих оценочных критериев разваливается.

Какие последние веяния по обозначению адресации в микрорайонах ? Конкретно интересует чтобы поддерживалось в программах навигации и номинатиме. Это не мне нужно, хочу подготовиться к беседе с новичком.

Osmand и 7 дорог отлично поддерживают addr:place. Номинатим также поддерживает, (проверил сегодня)

про песок тут всё расписано http://wiki.openstreetmap.org/wiki/User:Danidin9/Variants_of_smooth_surfaces

для ваших целей будет достаточно две градации. good и horrible.

делить более чем на две градации степень рыхлости песка - это безумие. :slight_smile:

ну, может быть, максимум три градации… good/bad/horrible

для велосипедиста тег surface=sand уже многое говорит.

Существуют ли теги для обозначения маршрута машины для вывоза мусора и графика ее движения? Т.е., мусоровоз по определенным дням объезжает определенные точки, останавливается там на определенное время, загружает мусор от благодарных жителей и уезжает. Как это перевести на язык OSMа?

Никак, не нужно эти маршруты в OSM вносить. Точки сбора мусора с указанием времени - их можно, но вроде как индивидуального тега для них пока не изобрели. А разве это ещё практикуется? Мне казалось уже везде контейнеры используют, с ними всем проще.

“Везде” это где?
В США в определенный день машина забирает содержимое контейнеров, которые у людей обычно стоят на участке, а перед днем сбора их выставляют на дорогу. В Японии мусорные мешки с разными типами мусора также выставляют, при том разные типы мусора забирают в разные дни. Ну и так далее.

В России. В данном форуме по умолчанию обычно её обсуждают.

Ну и при чём тут это? Из описания я понял что имеется в виду другой способ, отличный от “выставления”, который практиковался во времена СССР - приезжает машина в определённое время, стоит пару минут и едет дальше. Жильцы к этому времени выходят с вёдрами и вытряхивают их в мусоровоз. Сам в детстве так мусор выносил. Преимущество у данного способа - отсутствие выставленных контейнеров/мешков (и прилагающимся к ним запахам/живности), но недостатки обычно перевешивают.

А ничего, что проект OSM - международный?

Как уже сказали, вряд ли имеет смысл рисовать маршрут движения мусоровоза. А точки сбора я бы обозначил точками на линиях дорог, теги такие:
amenity=waste_disposal
opening_hours=Mo-Fr 7:00, 14:00, 20:00; Sa-Su 9:00, 19:00

opening_hours не тот смысл, лучше посмотреть в сторону времени выемки писем из почтовых ящиков.

Да, лучше использовать collection_times. На странице тега в примерах даже есть amenity=recycling.

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

ОСМ не очень хорош для обозначения невизуальной информации. Такого рода вещи важны для каких-то специализированных рендеров, например рендер пожарных служб, рендер мусоросборочного холдинга. Кроме того ОСМ не очень хорош для отображения частной инфраструктуры - туалетов на участках, например.

Я например, не проставляю часы работы POI. На самом деле в районе я даже не успеваю обновлять POI по району - 1-2 года и объект съехал, редко кто “в деле” находится больше двух лет. Что тут говорить про часы работы. Я никогда не использую часы работы POI в ОСМ так как вероятность того что она актуальна - крайне невелика. Чтобы такая информация была бы верна нужно прозванивать все организации в округе и выяснять есть ли у них изменения. Опять же, время работы может зависеть от времени года. Вот в библиотеке в которую я сейчас хожу - летнее расписание, в супермаркете в который я хожу перед Новым годом - своё расписание.

А “передвижные” объекты - ещё более сложный объект. Я знаю где у меня находится пункт продажи ёлок перед Новым годов, арбузов в сезон. Но зачем это на карте? Карта нужна чтоб ориентироваться, а не запутывать. Зачем информация о ёлках в июле, арбузах в январе?

Пункты сбора мусора с расписанием? Я жил в городе где водовозка развозила воду по расписанию, у нас в селе по расписанию ездит автолавка, заезжая на определённое время в каждую часть села, почтальон разносит почту в определённое время, пенсию по определённым дням. Но кому нужна такая информация? Тому кто живёт? Он её и так знает. Приезжий? Я бы спросил у местных и последнее место где бы стал искать такую информацию - в ОСМ … если я конечно не разработчик специализированного рендера для мусоросборочного холдинга который хочет напечатать карты и вывесить их на всех тучках мусоросбора.

Про мусор, месяц назад нашел у соседей http://www.openstreetmap.org/way/415182502
Удалять-исправлять не стал,кому-то нужна эта информация. Другое дело оформить бы его в нормальный маршрут…