То самое письмо:

Первые кривые домики:

… See full entry

Не высокая частота обновления спутниковых снимков, не всегда позволяет добавлять новые здания. В этой ситуации можно воспользоваться схемами с паспортов строек. При перерисовке схемы возникает проблема, состоящая в том, что фотографии схем содержат искажение перспективы, которое надо как то исправлять. Ниже предложен не сложный способ того, как можно это сделать с помощью растрового графического редактора GIMP, векторного - Inkscape, а так же JOSM с установленным плагином ImportVec.

… See full entry

junction:cluster:radius - тэг для указания максимально возможного радиуса влияния/отношения пересечения на окружающие объекты

---

Синтаксис

node.tags {
   junction:cluster:radius: number[1..N]
}

Применяется для объектов

Когда этот тэг применяется для объектов типа node, эта эта точка должна являться пересечением - junction. См статью про это. Тэг указывает радиус окружности в которую может быть вписана функциональная зона для данного пересечения. Это означает, что в данной зоне другие объекты (парковки, переходы, стоп-линии и так далее) могут отображаться или интерпретироваться как-то иначе. В какой-то степени это понятие соотносится с понятием функциональная зона перекрестка, только в данном случае - простейшего пересечения.

Главной мотивацией введения данного тэга было обеспечить возможность группировки нод соседних пересечений в обобщающее понятие “Перекресток”. Для этого у нас есть несколько различный вариантов, как это может быть сделано:

1. Relation: type:intersection, members[node1,...,nodeN, way1,..., wayM]
2. Атрибут у ноды который является ключом обобщения(имя-идентификатор кластера) junction:cluster = name or id
3. Радиус, который при наложении(union) окружностей даст общий полигон для некоторого множества нод junction:cluster = 5

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

Рассмотрим 3 способ.

• Очень геометричный, отражает площадные/линейные характеристики пересчения
• Не требует поддержки ссылочной целостности( как в 1) и контроля уникальности, для 2
• Можно найти зависимость или корреляцию с другими свойствами ноды (число полос)
• Просто числовое значение в метрах
• Формально нового объекта типа перекресток не появляется, но он всегда может быть получен простейшей операцией buffer + union
• То есть принцип бритвы Окамма - не плодим новых сущностей без необходимости

… See full entry

junction:radius - тэг для указания максимально возможной зоны конфликта на пересечении

---

Синтаксис

node.tags {
   junction:radius: number[1..N]
}

way.tags {
   junction:radius:lanes: number[1..N]|number[1..N]|...
   junction:radius:lanes(:forward|backward)(:start|end) number[1..N]|number[1..N]|...
}

Применяется для объектов

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

junction:radius - радиус окружности соотносящийся с зоной конфликта, в котором участвуют транспортные средства

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

Рассмотрим несколько примеров. На рисунках ниже голубая окружность в правой части рисунка и есть визуализация значения данного тэга.

Пример 1

junction:radius = 4 Зона конфликта не описывается окружностью указанного радиуса(ширина и количество полос), значение задано неверно.

… See full entry

junction:shape - тэг для указания характерной формы пересечения 2х путей

---

Синтаксис

node.tags {
   junction:shape: rectangle|oblique|staggered
}

Применяется для объектов

Этот тэг применяется только для объектов типа node и эта точка должна являться пересечением двух или 4х way. Для самых распространенных пересечений 2х дорог или одной дороги пешеходного перехода. Он отражает форму пересечения и отношения между воображаемыми или реальными стоп линиями конфликтующих путей в этом пересечении.

Причины введения

Две дороги могут пересекаться под совершенно разными углами, см примеры ниже, но углы пересечения иногда не отражает, как автомобили или пешеходы или другие транспортные средства, будут останавливаться перед этим пересечением. Форму задает проект организации дорожного движения и фантазия проектировщика.

Значения

• rectangle - стоп линии конфликтующих путей находятся под углом ~ 90 градусов друг относительно друга. Точки стоп линий для каждой полосы lanes откладываются по перпендикуляру от осевой. Стоп линия одна - общая линия для всех lanes (рисунки 1,4,5).

• oblique - стоп линии конфликтующих путей находятся под углом меньше чем 90 градусов (~ 30 - 70). Точки стоп линий для каждой полосы lanes откладываются по параллельно пути, который конфликтует с данным. Стоп линия одна - общая линия для всех lanes (рисунки 2,4,5).

• staggered - некое промежуточной состояние между rectangle и oblique, угол пересечения может быть любой, главное отличие в том, что для каждой lane своя отдельная стоп линия на разных расстояниях от node (рисунок 3,5).

Примеры

… See full entry

connect - ключ для указания связности полос на пересечении

–

Синтаксис

way.tags {
   connect(:lanes(:forward|backward)): number;number;...||
}

Применяется для объектов

Этот тэг применяется только для объектов типа way и может быть расширен двумя широко применяющимеся суффиксами :lanes и :forward|backward

Причины введения

Сейчас в OSM существует способ для точного задания связности между полосами с помощью отношений. relation:connectivity

Основным недостатками этого являются, то что это:

1. Очень громоздко, создавать отношение или даже несколько для одного way (from)
2. Отношения очень хрупкие и их легко сломать, постоянно нужен контроль их целостности
3. Для выходов из одного way в разные стороны (несколько way назначения) может понадобиться несколько relation - нельзя сделать одним объектом
4. Повышенные требования к редактору и опыту маппера
5. Лишняя сущность, нарушает бритву Оккама, с поворотми(turn:lanes) получилось же без relation.

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

За основу можно взять существующий подход с поворотами:

way.tags:
    lanes:forward = 3
    turn:lanes:forward = through|through;right|right

Отлично, всем понятно и широко применимо. Непосредственно для объекта типа way задается несколько тэгов со связным содержимым. От количества полос зависит количество секций на которые будет разбито значения тега turn:lanes:forward из каждой полосы мы задаем направление поворота.

Можем ли мы наследовать этот подход, но при этом задавая что-то, что будет адресовать полосу приемник?

Например, таким образом

way.tags:
    lanes:forward = 3
    turn:lanes:forward = through|through;right|right
    connect:lanes:forward = 0|1;2|3

… See full entry

OSMPIE - OSM Perfect Intersection’s Editor

Введение

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

OSMPIE состоит из двух главных компонентов:

1. Это рендер движок дорог, который превращает объекты дорог OSM (атрибутированные way,nodes,relations) в новое множество геообъектов топологически и геометрически связанных между собой и исходными OSM объектами.
2. Это специализированный редактор/вьювер для быстрого и удобного картирования дорог и перекрестков в OSM.

Начало:

… See full entry

Пересечения и перекрестки

Описание пересечений в OSM как и многое достаточно хаотично и лоскутно. См Key:junction Чтобы готовить перекрестки более совершенными надо систематизировать существующие тэги и …. добавить еще немного хаоса)))

node: 
    junction = controlled|uncontrolled|inout|joint 

Продолжая развивать тему тэгирования точек, в настоящее время существуют и применяются тэги junction=yes, junction=uncontrolled При работе над рендером мы провели классификацию пересечений, которые вероятно стоит различать и предлагаем расширить этот список, но саначала…

Основные признаки пересечений

• Участники - точка принадлежит 2м и более way
• Размер - неотъемлемым, хотя и невсегда явным атрибутом пересечения будет являться некая фигура, площадь, многоугольник - нечто что будет соотносится(описывать,вписывать) с реальными линейными размерами места, где будет(не обязательно) происходить конфликт участников движения. В OSMPIE мы предложили использовать окружность и соответсвенно радиус, как аттрибут см junction:radius
• Связность - появляются такие понятия(точки) входа и выхода в пересечение и необходимости указания(атрибуции) их связи друг сдругом. См connect:lanes, relation[type=connectivity], turn:lanes
• Конфликтные точки - необязательный, часто присутствующий признак - конфликтности одних связей с другими и место(координаты) этого конфликта.

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

Самым оптимальным вариантом атрибутирования, который бы мог управлять процессом и соответственно результатом кластеризации тоже является радиус окружности - см. тэг junction:cluster:radius

Классификация пересечений:

… See full entry

JOSM + плагины:

• FastDraw,

• reltoolbox,

• buildings_tools,

• CustomizePublicTransportStop,

• UtilsPlugin2

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

Реестр парковок г. Калуги

Реестр сведений о парковках общего пользования, расположенных на территории муниципального образования “Город Калуга”.

Ссылка

Комплексная схема организации дорожного движения города Калуги

Содержит перечень дорог с их категорийностью и другими характеристиками (см. файл Отчет КСОДД).

Ссылка

АО “УКОН”

Информация о городских ярмарках и банях.

Ссылка

Время чтения: 10 минут.

Введение

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

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

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

Немного терминологии:

1. GNSS - Global Navigation Satellite System

Глобальная навигационная спутниковая система. Именно ее большинсво людей называют ошибочно GPS. В мире есть несколько систем GNSS: ГЛОНАСС - Россия, Navstar GPS - США, Beidou - Китай, Galileo - Европа, IRNSS - Индия и другие. Полное покрытие имеет только ГЛОНАСС, GPS и Beidou. Все (или почти все) современные модули геолокации смартфонов используют несколько систем навигации одновременно. Как правило, это: GPS, GLONASS, Galileo, Beidou.

2. Альманах

• вид данных, которые передаются спутником на землю. Содержит информацию об орбитах всех спутников. Эта информация хранится на смартфоне и позволяет спрогнозировать примерное местоположение спутника в течении времени. (Например: Дня) Эта информация достаточно долго хранится, но на ее основе будет не точное определение геопозиции.

Альманах для GPS транслируются каждые 12,5 минут, ГЛОНАСС каждые 2,5 минуты. Албманах может потерять свою актуальногсть, если на смратфоне сбилось время или местоположение изменилось на 100-200-300 км.

3. Эфемерида

… See full entry

Зачем же? Поправить мои правки!

Не так давно я добавил магазины сети Батон на карту, а сейчас начал расставлять магазины сети Русский Разгуляйка.
Проблема? Я расставлял POI с точностью до адреса дома, а не до двери. Поэтому, если кому то нечего делать, приглашаю вас рассмотреть мои пакеты правок^[3][4][5][6], и обращаясь к Яндекс Панорамам (или любым другим источникам данных) разметить POI’шки точнее, к дверям.
Буду рад помощи, и спасибо!

upd 14.03.2025

самостоятельно поправил магазины сети “Батон”

В iD появилось поле “ID изображения в Panoramax”, которое отвечает за тег panoramax=*. Все, кто по моему совету заливал фото/панорамы на Panoramax теперь могут пометить POI (и не только) тегами с ID их фото на этом сервисе.

Нам нужно больше пользоваться сервисами для панорам, такими как Panoramax.

Яндекс это конечно отличный сервис, но он все же не самый дружелюбный к OSM’у, и права на его панорамы могут отозвать в любой момент. Призываю всех неравнодушных людей у которых есть файлы уличных панорам (или даже фотографии уличных объектов) зайти на https://panoramax.openstreetmap.fr/upload и загрузить их туда. У iD есть отдельный слой для панорам с этого сайта, и у людей которые картируют с него будет больше открытых данных с которых будет удобнее брать информацию.

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

Мы пережили отключение серверов!

А теперь я быстренько залью свои правочки пока они опять не легли :)

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

Итак, начнем с расширения наименований.

В OSM принято вносить в name= имена собственные, и во многих случаях, мы же вынуждены нарушать это правило, внося и name что то вроде “Москва река”, “Собачий пруд”, “ Парк Дубки”, “Строительство дороги Москва - Петушки”, “Детский сад Умка”, или “ГБОУ Школа №1234”. Схема получается противоречивая, генерирующая довольно грязные данные. Было бы правильно, разделять описание сущности объекта, и его имя собственное. Разделять можно двумя способами.

1- Добавить отдельный атрибут для сущностной части. Получаем:

name:type=Детский сад name=Умка

2- Вводить всё в name, но разделяя специальными символами, например так name=[Детский сад]<Умка>

Мне могут возразить, что всё это уже есть, ведь leisure=park, или water=pond, и выполняет эту задачу, описывая сущность объекта. Но нет, наших схем тэгирования не всегда хватает для красивого и правильного составления названия. Может быть, было бы лучше расширить схему наименования, для того, что бы не зависеть от костных и ограниченных существующих схем.

Ассоциированные входы.

… See full entry

Перевел статью из вики ОСМ на русский.

Первая переведенная мною статья , надеюсь идея HD разметки дорог будет развиваться дальше.

Павильон Росси в Михайловском парке, Санкт-Петербург, 122 части, третье место в СПб. Это один из наших архитектурных шедевров, и представляет собой одновременно и пристань, и садовую беседку для романтических чаепитий.

Я его уже показывал, но теперь он загружен в OSM и отображается на F4 :

… See full entry