Карты для СитиГида

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

Хотя пробочная информация в два направления разная - значит, понятия “туда”, “сюда” в СитиГИДе есть.

В данном конкретном случае - да.

Получится несколько искусственно.

Условная схема: линия границы нарисована одной красной линией, линия дороги - двумя чёрными (примерно, как выглядит в мапнике: граница рисуется линией, дорога имеет некую ширину).

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

2. Посередине - граница, по бокам - два вея дороги. Не соответствует действительности, т. к. физически дорога одна; отрабатывается.

3. Посередине - линия дороги, граница в двух местах отходит в сторону, чтобы часть дороги чётко попала в полигон соответствующего населённого пункта. Не соответствует действительности, т. к. в реальности граница прямая; отрабатывается.

4. Посередине - линия дороги, граница сначала идёт с одной стороны дороги, потом - с другой. Не соответствует действительности; отрабатывается.

Вариант 1) - текущий. Варианты 2), 3), 4) не сложно реализовать, но тогда в каком-то месте ось дороги не будет совпадать с границей, то есть в каком-то месте будет иметься расхождение с реальностью. Поэтому хотелось бы, чтобы вариант 1) тоже как-то отрабатывался бы. Самое напрашивающееся - брать информацию из addr:city. Посему вопрос - насколько это реально?

Позволяет. Пункт меню “Разделить поток”.

Радует возможность, огорчает мой склероз (не может быть, чтобы я не натыкался на эту строчку в меню редактирования)… Спасибо за замечание!

В СГ разумеется, есть. Это ограничение “стандартного польского формата” там только одно число отвечает за скорость, причем задает скорость ступенчато.

В СГ одна дорога принадлежать сразу нескольким НП не может. Да и в реальности я думаю тоже. Пол-дороги принадлежит одному городу, пол-дороги другому.

Интересно, как они решают за чей счёт её ремонтировать?

Кстати, о ремонтах. Всё-таки нехорошо полностью фильтровать highway=construction. Когда ремонт/реконструкция заканчивается, было бы неплохо таки иметь возможность хотя бы вручную открыть нужную дорогу, не дожидаясь когда выйдет очередная сборка. Для ежедневных сборок проблем особых нет, но вот для пробочных картина уже другая - пауза затягивается на месяцы.

В официальных картах такие дороги рисовали пунктиром и закрытые нулевой скоростью. В итоге их легко можно было открыть корректурой в случае необходимости. Может и нам сделать что-то подобное?

Чтобы такое задышало, нужно, чтобы кто-то взялся вести эти самые корректуры. Пока никто не взялся.
А пауза да, что-то опять затянулась. Давайте уже что-ли обновляться. Но границу Петербурга что-то колбасит последнее время. Нельзя ли ее зафиксировать?

Вариант: дороги с разными maxspeed:forward и maxspeed:backward представлять как две линии с односторонним движением, проходящие по одним и тем же точкам.

Ну если 50 % “акций” дороги принадлежит одному городу, а 50 % - другому, это и есть “дорога принадлежит двум городам”

Действительно, интересный вопрос:)

На мой взгляд, отсутствие человека, готового вести ежедневные корректуры для пробочной карты, не является причиной для выбрасывания ремонтируемой дороги с карты.

Если ремонтируемая дорога обозначена на карте ребром с нулевой скоростью: а) работает адресный поиск; б) если пользователь видит, что какая-то дорога важная открылась, он может сам проставить на ней скоростные индексы ещё до выхода новой карты.

Если ремонтируемая дорога не обозначена на карте: а) не работает адресный поиск; наличие человека, готового вести корректуры, не поможет, т. к. на отсутствующее ребро скоростной индекс проставить сложно.

Вариант I: рисовать ремонтируемые дороги так, как рисуются дороги surface=ground, и ставить нулевые скоростные индексы
Вариант II: рисовать ремонтируемые дороги пунктиром так, как это делается в картах СитиГИДа для строящихся дорог, и ставить нулевые скоростные индексы
Вариант III: рисовать ремонтируемые дороги так, как рисуются highway=residential, и ставить нулевые скоростные индексы

Такое, к счастью, невозможно по многим причинам. Но зато польский формат допускает расширение пользовательскими атрибутами.

Заниматься такой хренью вряд ли из [некрасноглазых] пользователей кто-то будет. Пользователи уже сильно избалованы.

На данный момент это две самые большие претензии от простых пользователей на осм-карты.

1. Неполная адреска.
2. Отсутствие корректур.

Если желающих больше нет, по Питеру я могу взяться. У себя на пробочной карте я уже отмечаю где какие ошибки встретил (ну в OSM, разумеется тоже).

Cергей, если не ты, то кто? )
Пришли мне тогда корректуру, я протолкну ее в МИТ.
А потом будем обновляться. Там правда что-то фтп разломалось, свежие сборки на сайт не попадают. Но я надеюсь это скоро будет исправлено.

У нас есть еще какие-то проблемы, которые можно починить, кроме hw=constraction и философских?

http://files.mail.ru/NXBHX6

Но это только то, с чем я сам столкнулся.

Линии в польском формате имеют направления? Есть возможность прикрутить пользовательский атрибут “скорость в обратном направлении” (скорость, задаваемая по умолчанию - “скорость в прямом направлении”)?

Наверное, да, т. к. если пользователь лезет делать корректуру, то он уже, вероятно, становится красноглазым:).

Мне кажется, на отсутствие ремонтируемых дорог и на карте и невозможность найти что-то на них (т. к. ломается поиск), пользователи тоже могут жаловаться:)

игнорирование тега living_street=yes при простановке скоростных индексов отремонтировано?

По поводу ведения корректур. Одному вести их может оказаться сложно (если ежедневно изменений будет относительно много). С другой стороны - когда ведёт один, он знает, что он уже корректировал, а что - нет. Мне кажется, если бы удалось сделать сервис, позволяющий вести корректуры нескольким людям, то было бы проще.

Вариант:

1. Пользователи посылают сообщение об ошибке.
2. Один из проверяющих открывает его, на сообщении для других проверяющих появляется надпись “читается тем-то”
3. Проверяющий открывает карту, на которую нанесены метки, информирующие о тех ошибках, что уже рассматривались и проверяет, не обращались ли уже по этому поводу. Варианты: "отклонено, т. к. ", “исправлено в корректуре, исправлено в OSM”, “не может быть исправлено в корректуре, исправлено в OSM”, “в работе”.
4. На сообщении для других проверяющих ставится “обрабатывается тем-то”
5. Исправляется ошибка в OSM
6. С сервера загружается последняя версия корректуры
7. Вносится изменение в корректуру
8. Файл корректуры загружается на сервер
9. На сообщении для других проверяющих ставится “обработано”
10. В сервисе с метками ставится соответствующее сообщение.

Насколько реально ездить по пробочным картам? Тут получается замкнутый круг: а) пользователи не будут ездить по пробочной карте OSM, пока её будет обслуживать мало датчиков; б) датчиков не будет много, пока пользователи не начнут массово ездить по пробочной карте OSM.

Круг разорвётся либо если на официальной карте датчиков станет так мало, что от неё не будет толку, либо если вдруг на пробочной карте OSM появится много датчиков, либо если данные от пользователей, использующих официальную карту, как-то будут транслироваться на пробочную карту OSM. Но данная трансляция, надо понимать, вещь весьма непростая.

Какая, кстати, польза МИТу от поддержки пробочных OSM-карт? МИТ ведь теряет датчики для официальных карт.

Насколько я понимаю, датчики все же общие как для МИТ’овских карт, так и для ОСМ.

Да, датчики общие в рамках совпадения дорожного графа.

А нельзя ли и корректуры сделать общими “в рамках совпадения дорожного графа”

Сказано - сделано. Если посмотреть в окно информации для карты Питера, можно увидеть:

Имеют, конечно, откуда иначе брались бы односторонние дороги? Да, можно, вопрос в том, что бы поддержать это в конверторе.

Что бы сделать такой сервис, нужно расковырять формат корректур. Чтобы можно было посмотреть, кто чего намесил. А иначе будет бардак.

Сервис же я вижу так:

1. Специальный скрипт отслеживает изменения в OSM, в запретах поворотов/запретах движения/одностороннем движении по отношении к тому osm-файлу, на котором построена карта.

2.Для каждого отловленного изменения сервис открывает “багу” в неком собственном OpenStreetBugs.

3. Специально обученный человек эти баги смотрит, если нужно изменение в корректуре, вносит изменение в корректуру, а багу закрывает.

т.е. двигателем процесса являются изменения в OSM, а не просто ошибки, найденные одним конкретным человеком.

Интересно, в каком случае граф считается совпадающим. Ведь:

1. Линии не совпадают идеально
2. Одна и та же дорога на одной карте может быть обозначена одним ребром, на другой - несколькими
3. На одной карте две проезжих части могут быть обозначены отдельными рёбрами, на другой - одним

Я загрузил эту корректуру, переименовал в user.upd, закрыл запретами поворотов проезд по дорогам с access=no/destination в Ломоносове и Петергофе и сохранил - http://files.mail.ru/BTZ7TB

1. Отслеживаются изменения непосредственно в OSM или в dcm-файлах?
2. …
3. Если обученный человек будет видеть только разницу в OSM, не факт, что он сможет оценить, нужно ли “подтверждать” изменение или нет, т. к. он не будет знать, кто внёс изменение и с какой целью. Например, я встречал only_straight_on, где в роли from выступала, скажем, дорога, ведущая направо: что хотел сделать автор - разрешить движение только прямо или только направо? Когда карта корректируется по прямым запросам пользователей, по крайней мере, есть какое-то текстовое описание каждого запрашиваемого изменения.