Smooth - приглашаем в социальный проект навигации на OSM

Посмотрел карту Екб. Действительно, на первый взгляд плотность тротуаров в центре Екб больше чем в Питере. Дороги, правда, так же имеют foot=yes, но их можно исключать по типу, или делать рёбра графа соответствующего дороге “дороже” (как сейчас происходит у нас).

Вы не в курсе с ками проблемами столкнулись в Екб при нанесении тротуаров? Может нам ребята посоветуют, было бы классно.

**Есть какая-то договорённость или рекомендация по установке флага Foot на дороге? ** Каким образом регулируется этот вопрос? Нам мой взгляд надо ставить foot, только там, где это как минимум не запрещено правилами. Соответственно на дорогах этот флаг должен быть снят. Возможно приняты какие-то другие правила.

Такая же ситуация с велосипедами - с одной стороны на них нельзя ездить по тротуарам, а с другой в России практически нет велодорожек. Мы общались с ребятами из “Велосипедизации Петербурга” по поводу навигации для велосипедов. Получается, что официально мы не можем предлагать ехать по тротуарам, а по дорогам их маршрут почти сопоставим с автомобильным. Есть идея создать навигацию умеющую выбирать наиболее безопасный путь для велосипедиста, т.е. сделать ранкинг путепроводов и прокладывать маршрут наиболее удобным и безопасным путём. Информацию об удобстве той или иной улицы получить от самих велосипедистов. Это уже тема отдельного разговора и проекта)

По идее должен быть foot=no для дорог, параллельно которым нарисован тротуар. Но это очень мало кто делает.

Проблемы - они общие для осм.
Не так много, кому интересно мапить конкретно %feature_name%.
Не понятно, надо это кому вообще или так из любви к исскуству делаем.

Про foot=no понял, спасибо. Соответственно там где его не нарисовано мы оставляем возможность его наличия. Логично.

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

Я немного другое имел ввиду. Так сложилось что тот кому надо, тот и понимает больше и вообще как-то крутится. Дорожки в лесу лучше всех рисуют те кто по ним ходит. Я не особо задумывался о ступеньках на тротуарах пока не покатал каляску.

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

Автомобильный граф более ли менее тестируют (просто в силу того что им часто пользуются) - тротуарно-пешеходный - скорее нет. Соответсвенно будьте готовы к тому что будет куча разрывов там где их нет и куча неуказаных препятствий.

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

Для меня всё ещё не ясен ответ на главный вопрос. Как должен выглядеть правильный процесс нанесния пешеходных путей?

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

На другие города (глобально на всю планету) планируете расширяться?

Так же как и нанесение любых других данных. Начните с прочтения вики http://wiki.openstreetmap.org/wiki/RU:Методы_картографирования и дальше http://wiki.openstreetmap.org/wiki/RU:Редактирование При редактировании учитывать это http://wiki.openstreetmap.org/wiki/RU:Good_practice

Так же выложите список тегов, которые влияют (или будут влиять если ещё что-то не доделали) на роутинг (желательно с указанием важности, например, что покрытие сильно влияет на маршрут, а ширина - незначительно) - что бы картографы обратили на это особое внимание. А так же что бы не вносить данные которые потом не будут использоваться.

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

Людей с ограниченными возможностями тоже можно привлекать к картографированию по фото и видео. Они более мотивированны должны быть, т.к. сами потом будут пользоваться этим.

https://www.youtube.com/watch?v=3jS9ftOTZBU , например.

А чт овас конкретно интересуют, необходимые теги или работа с геометрией?

Да, это правда. Вообще тут интересная ситуация получается. Такого рода препятствия действительно могут быть занесены как атрибуты в OSM и указывать их действительно трудоёмкая работа.

Интересная штука в том, что в нашем случае они не очень важны. Все препятствия на пути как раз будут агрегироваться и учитываться сервисом (smooth.city). Так как основная цель сервиса - это учёт всех препятствий на пути и прокладка маршрута в обход их, то механика для добавления и верификации препятствия там реализована намного проще. Для нанесения препятствий нам нужны сами пути. Потом, имея базу препятствий, они могут быть даже экспортированы уже в OSM. Таким образом, информацию от пользователей можно использовать дважды - для smooth.city и для OSM.

Я делал, пока ездил на велосипеде. Указание съезда с поребрика напрямую влияет на удобство в том числе и велопокатушек. А пандусы я маплю и сейчас, когда не лень.

Какие для этого есть теги?

Безусловно, мы планируем привлекать как людей с ограниченными возможностями, так и любых других добровольцев. Но большинство из этих людей точно не будет иметь никакого опыта редактирования OSM. Поэтому нам нужно написать подробную инструкцию для них, чтобы с одной стороны упростить участие, а с другой минимизировать ошибки. Один из важных моментов - источники данных. Карты и спутник Google/Yandex использовать нельзя. Но вроде можно панорамы Яндекс (без геоданных), или это не так?

Какие данные нужны. Главное — сами пути. Это критически важная информация. Из тегов будет оцениваться Покрытие, Ширина, wheelchair_accessible. У переходов тип и sloped_curb/kerb (вопрос - что из этого использовать при нанесении). Возможно мы не знаем о каких-то потенциально полезных тегах. Будем рады предложениям.

Для поребриков использую пропозал по kerb. Допустимо линией по контуру, но я предпочитаю точкой на пешеходном вее. Размечаю как flush / lowered / raised, использую для ускорения самописный пресет.

Разметка для пандусов сейчас входит в дефолтные пресеты для разметки лестниц, тег ramp:wheelchair=yes (корень неймспейса слишком общий - не всякий пандус подойдёт для колясочника без сопровождения).

Также предлагаю смуферам учесть, что существует тег доступа wheelchair=assisted. Он не общепринят, используется крайне редко, но для России является чуть ли не самым полезным, т.к. обозначает наиболее распространённый вариант “пандуса нет, но есть кнопка для вызова сотрудника”. Такую же функцию, похоже, выполняет значение on_request. Неплохо бы определиться с единым значением для такого варианта. А потом написать его в вики и пропиарить.

Всё верно. Учитывайте, что в миллионниках панорамы могут устаревать.

С точки зрения кода, сервис масштабируется очень просто везде, где есть OSM. Если в городе есть хорошо прорисованная пешеходная сеть, то его можно подключить очень быстро и пешком можно будет гулять по всему городу.

Далее всё зависит от того, как в других городах организовано предоставления данных о наземном общественном транспорте и метро. В Питере мы получили данные с портала комитета по транспорту. Мы общались с комитетом по информатизации и просили их о некоторой дополнительной информации. В итоге мы можем очень точно предсказать прибытие конкретного автобуса на остановку и знать оборудован ли он системой подъёма или нет. Как я уже писал тут где-то мы знаем ребят, которые запили очень хорошую навигацию по метро, так что в тех городах, где она есть, её прикрутить легко. В Европе есть проект про метро - metro4all.org Они там очень хорошо описывают графы метро.

В России можно взять любой город, например Екатеринбург, т.к. там хорошо прорисованы пешеходные пути и сделать навигацию там. Возможно в связи с меньшим размером процент качественного покрытия будет больше. Но, т.к. мы из Питера, начали отсюда)

Не обольщайтесь на счёт “очень точно”, точность там частенько хромает.

** Ребят, у кого-нибудь есть опыт организации картовстреч? **
Я хочу, выбрать какую-то область города и покрыть её в режиме коллективного прохода. Изначально договориться о том, кто что проходит и согласовать правила нанесения. Дать информацию в СМИ о том, что с помощью OSM реализуется социальный проект.
Перед этим согласуем с опытными мапперами инструкцию по нанесению объектов. Тут уже были конструктивные ответы, мы их просто соберём и запостим тут.

** Кто-нибудь есть из Питера кто готов поучаствовать в этой движухе? **

В Киеве у Eway точность - ну конфетка просто, не знаю как у всяких Яндексов там, тем более в других городах…

В данном случае это информация от комитета по транспорту. Кто её интерпретирует особо не имеет значения - Яндекс или кто-то другой. У нас друг делал проект тоже на хакатоне по определению прибытия автобуса к любой официальной остановке в городе. Получалось достаточно точно. Во время высокого трафика точность была ниже, но в целом достаточно что бы спланировать свой путь.

Текущие положения - да, общие у всех, с сервера перевозчика, но вот алгоритмы “предсказания” прибітия могут различаться. Допустим они могут учитівать/не учитывать текущие пробки, или вносить поправку на время суток и день недели и т.д.