OpenStreetMap

Diary Entries in Russian

Recent diary entries

Быстрый мапинг подъездов

Posted by danvyr on 18 September 2018 in Russian (Русский)

Общие советы как маппить подъезды

  • Можно мапить через подъезд и потом в JOSM за пару минут внести инфу в пропущенные. Потому что первая квартира в текущем подъезде = последняя в предыдущем + 1. И наоборот. Последняя в текущем = первая в следующем - 1.
  • А в типовых домах можно мапить только последний подъезд, копируя тэги с готовых подъездов. В типовых домах номера подеъздов и квартиры совпадают. Поэтому наносим тэги в последний подъезд просто для того, что бы знать тип дома.

Обзор подходов для маппинга подъездов

При маппинге подъездов есть 2 подхода:

  1. Сбор данных (фото или на бумагу) и потом их внесение с помощью JOSM. Тут может помочь gps трэк что бы восстановить маршрут.
  2. Непосредственное внесение Vespucci и последующая корректировка в JOSM

Попробовав оба подхода, могу заявить о преимуществах второго.

  1. На внесение данных в Vespucci тратиться почти тоже время что и на фото, но фотки надо потом просматривать и вносить с них данные.
  2. Вечером/ночью фото особо не по делаешь. Tак же если какие-то стрёмные люди стоят возле подъезда, фотографирование может вызвать вопросы.
  3. На месте проще привязать подъезд на карте - к подъезду в доме и ошибки в больших домах исключаются.
  4. Так же фото может получиться расплывчатым.
  5. Смысл использовать листик, если можно сразу вносить в карту.

Мой итоговый способ

  1. Нанести подъезды на карту. С тэгами entry entrance=staircase; access=private; add:flats=?? и ref=??
  2. Тогда они подсветятся на валидаторе подъездов, его можно подсматривать в браузере на смарте.
  3. Пользуясь Vespucci проехаться по району на велосипеде. За 3 часа получилось замапить подъезды 36 домов.
  4. Отредактировать данные с помощью JOSM. Так как данные внесены корректно и распознавать их на фото не нужно, то на этот пункт уходит минут 10.

И снова здравствуйте!

Posted by Medvezut on 9 September 2018 in Russian (Русский)

С 2011года не заходил сюда и вот накопился ряд замечаний. Если чего то перепутал не обессудьте ;))

Михаил http://osm.perm.ru/

Location: Индустриальный район, Пермь, Пермский городской округ, Пермский край, Приволжский федеральный округ, РФ

JOSM: Век живи, век учись.

Posted by Zkir on 6 September 2018 in Russian (Русский)

Как в JOSM сделать здание прямоугольным? Нужно нажать на Q, это все знают.

Но как сделать здание квадратным? Сперва сделать прямоугольным, а потом вымерять линейкой стороны? Нет ли более простого способа?

Оказывается, способ есть. Нужно нажать на O.

Вот так)

Пост

Posted by midrug on 30 August 2018 in Russian (Русский)

[quote=wowik][quote=literan]"Район" в name не писать, а перенести в тег official_status=ru:район[/quote] Вообще-то эти административные районы совпадают с муниципальными округами (см. alt_name), так что чей статус-то будет?[/quote]

Мне видится 2 варианта решения проблемы:

1) Писать только offcial_status:ru=район, поскольку район это часть административно-территориального деления, которое имеет более высокие уровни иерархии (вплоть до субъектов РФ), а также входит в систему органов государственной власти, а не местного самоуправления, как муниципальные округа.

2) Писать offcial_status:ru=район и делать новый тег alt_offcial_status:ru=муниципальный округ, т.к. названия у них совпадают. Это, конечно, усложнит систему тегов для таких подписей в городах федерального значения, но мы не обделим оба вида территориального деления. Плюс в этом случае можно убрать теги alt_name с названиями муниципальных округов. В первом варианте, что с ними делать — непонятно.

Клятва OSM

Posted by Sowa1980 on 22 August 2018 in Russian (Русский)

О великий создатель ОSМ, разработчики, программисты, маперы и т.д, поклянитесь, что ОSМ впитает в себя все самое лучшее. А именно карту, википедию, викимапию, пластичность, гибкость, экспорт и импорт из JOSM в 3д программы и обратно, простоту, 3D моделирование, вменяемую печать карт, и легкость создания последних) Вы возьмете всё это и приумножите, пронесете через века)) Исцелиться от алчных, жаждущих барыг и мелких, мышей которые растаскивают проект по зерношку))
И да канут в лета: яндекс , навител, мапсме, 2 гис и иже с ними)) аминь)) И не забудь OSM - мы когда то поверили тебе!!! И ты обещал перевести нас к звездам, так веди нас к ним)) Самыми кротчайшими путями, сами лучшими дорогами, по самым красивым и точным картам)) И мы клянемся плодиться и размножаться в тени, твоих деревьев в тех домах , что есть на твоей карте, и что когда мы исчезнем, придет новое поколение и продолжит наш путь грешников))

#Кривой_Рог_без_границ

Posted by ID`s on 21 August 2018 in Russian (Русский)

Всем доброго времени суток!

Вот, в конце-концов, решил в дневнике ввести в курс дела, к чему я вообще стремлюсь в плане мапинга. Живу я практически всю свою сознательную жизнь в городе Кривой Рог. И никогда не мог подумать, сколько может быть завораживающих мест в одном городе. Много кто, даже из коренных жителей (а я приезжий, так как родился в Киеве), не догадывается о красивейших местах этого города. Недавно я себе купил велосипед. И тут все начинается) Основной задачей перед собой я ставлю залезть туда, куда вряд ли полез кто-то другой. И, благодаря велосипеду, "зона моего покрытия" значительно увеличилась. Я не строю планов, не прокладываю путь, а просто ставлю для себя одну точку где-то на другом конце географии, куда мне нужно как-то добраться и как-то вернуться назад. Конечно, эти места чаще всего в как раз из тех, "о которых я где-то слышал, но где это - никто особо не в курсе".

И вот, вооружившись GPS, я отправляюсь в путь! Убедительная просьба не особо обращать внимания конкретно на мои треки. А именно не пытайтесь строить по ним пути на бездорожье. Как можно понять из того, что я написал ранее, довольно часто мой путь лежит по откровенному бездорожью. Да - кое-как там пролезть можно, но скорее всего только со встречей с зарослями шиповника. Моя задача - в как раз и проложить пути так, что бы было максимально безболезненно добраться до классного места. Так что просто не нужно.

Все свои треки я все равно буду выкладывать в открыты доступ, так как много езжу и по дорогам общего пользования. А пакеты правок, связанные с этими путями, буду отмечать хештегом #Кривой _Рог _без _границ. И таким же тегом буду отмечать и фото, которые делаю на интересных местах, и всевозможные новости (к примеру на странице в Вк).

Если дочитали до этого момента, значит я не зря тут распинался. Спасибо за ваше внимание!

Location: 47.910, 33.392

Валидатор садовых участков

Posted by CupIvan on 20 August 2018 in Russian (Русский)

Сделал отображение садовых участков для переноса статусной части в отдельный тег. Попутно обнаружилось, что некоторые отмечают придомовые территории как садовые участки, надо исправлять. http://osm.cupivan.ru/allotments/#508/?z=16&lat=56.20097488596246&lon=43.80772590637207

POI как оно есть.

Posted by Stud555 on 24 July 2018 in Russian (Русский)

ПОИ

ПОИ в городе...

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

А вот тут наткнулся на дневник https://www.openstreetmap.org/user/Anton%20Khorev/diary и что-то захотелось сделать.

Взялся поглядеть на ПОИ в своём городе. Ужас! Где ПОИ указаны на точках, где на целых зданиях. Непорядок!!!

Нужен валидатор!

Для начала выкачиваем исследуемый город:

wget -O istra.osm "https://api.openstreetmap.org/api/0.6/map?bbox=36.8110831,55.8931931,36.9062064,55.9363811"

затем выковыриваем ПОИ, которые представляют собой точки:

osmosis.bat --read-xml istra.osm --node-key keyList="shop,amenity" --write-xml istra_shop_node.osm

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

Вот такой, практически "ручной" получился валидатор. Надеюсь дальше буду автоматизировать, с процентами, с категориями и т.д.

У кого есть какие мысли, буду рад любым комментариям.

Location: 55.914, 36.861

Торговые центры на карте

Posted by CupIvan on 14 July 2018 in Russian (Русский)

Продолжаю экспериментировать со своим минидвижком OSM. На сей раз попробовал вытащить на карту торговые центры и прикрутить минимальный валидатор, можно теперь их размечать в едином формате. А также проверить может это и не mall вовсе, а department_store

Ссылка на просмотр: http://osm.cupivan.ru/mall/#478/?z=13&lat=56.1432543123371&lon=40.392780303955085

В планах сделать ещё несколько парсеров сетевых POI (например Пятёрочки или Лукойла), положить их код и результат деятельности в удобном JSON на гитхаб. А потом как-то всё сопоставлять с OSM... JSON может ещё кому-нибудь понадобился бы, благо с гитхаба легко подключать его будет.

Также в чатике кто-то спрашивал про реки, прикольно было бы сделать, чтобы при нажатии на реку писалось куда впадает и так можно по цепочке дойти до морей. Либо какой-нибудь текстовый валидатор, раньше вроде был, а сейчас что-то не работает :-(

Как я отмечаю POI – Что? Где? Когда?

Posted by Anton Khorev on 13 July 2018 in Russian (Русский)

Можно уже перейти к рассмотрению того, что я отмечаю при своих проверках POI, а заодно где и когда. Сразу надо предупредить, что если здесь написано, что я какие-либо объекты не отмечаю, то это не значит, что я их совсем никогда не отмечаю, это значит, что я не стремлюсь их отмечать при проведении проверок POI. Тем более это не значит, что я считаю, что они не нужны, и буду их удалять, когда они мне попадутся.

TL;DR

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

Где: в данный момент – на территории Адмиралтейского и Центрального районов Санкт-Петербурга в первую очередь вдоль официальных улиц (согласно rgis), далее во дворах и ТК.

Когда: в какой-либо момент со вторника по пятницу с 11:00 по 18:00, при необходимости в другое время.

Что?

Целевые теги

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

  • amenity – некоторым. Этот ключ соответствует разнородным объектам, как урнам, так и университетам. Университеты при данных проверках мне нужны, а урны – нет. Урны у меня относятся к особому виду проверок – урново-скамеечной картографии, для которых более-менее годится maps.me как редактор, но сейчас речь не о них.

  • club – всем. Это редко используемый тег, про который часто непонятно, стоит ли использовать именно его.

  • craft – всем, какие заметны в городской среде, а это те, которые предоставляют услуги населению, например, ателье.

  • highway – никаким. Этот ключ вообще не должен бы использоваться для POI, но он таки используется, например, для остановок транспорта. Но остановки не подходят по критериям, приведённым выше.

  • landuse – так сложилось, что некоторые крупные объекты, которые удовлетворяют критериям, например заводы, обозначаются этим тегом. Если я их могу обнаружить, то я их обозначаю, но в результаты проверки не включаю.

  • leisure – некоторым, например leisure=playground не подходит. Детские площадки я обозначаю при детальной отрисовке дворов, так что если я пойду искать во дворе POI, то чтобы отдельно туда не ходить за всем остальным, я отмечу и детские площадки.

  • office – всем, но большинство из них никак о себе не сообщают, и я такие не обозначаю.

  • shop – всем. Самый очевидный ключ для данных проверок.

  • tourism – некоторым. Музеи нужны, а viewpoint'ы – нет.

Видно, что невозможно придумать фильтр для типов точек, которые меня интересуют, так как в любой момент может войти в употребление новый тег из семейства amenity, leisure или tourism, и будет неизвестно, интересует ли он меня. То же самое с другой стороны выглядит как невозможность сформулировать определение интересующего меня множества объектов на местности на основе тегов осм.

Требования к POI

Как я уже писал, я определил интересующее меня множество POI по степени находимости и скорости изменений. Скорость изменений – это то, из-за чего в принципе приходится заниматься обновлением данных отдельно для POI. Но и среди того, что обычно относят к POI, скорость изменений разная. Некоторые из точек способны меняться быстрее, чем типичный магазин. Отсюда следует моё требование стационарности. Как я его обычно определяю: обозначаемое мной место не должно быть на колёсах и не должно быть переносимо парой человек. Такие точки могут не иметь постоянного местонахождения или запросто исчезнуть. На колёсах часто бывают фургоны «выпечка» или «кофе с собой».

Кофе с собой

Не подходит, так как на колёсах

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

Продажа симок

Поставите ли вы здесь office=telecommunication?

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

Закрытый ларёк

Этот ларёк не работает только сейчас или в принципе?

Всякие банкоматы, платёжные терминалы, торговые автоматы, для отсечения которых даётся требование наличия персонала, не угодили мне не только тем, что многие из них нестационарны, но и тем, что их сложнее найти. Типичный платёжный терминал находится в типичном магазине, и обнаружить его можно только зайдя в магазин. Помимо обнаружения присутствия для поддержки актуальности данных нужно и обнаружение отсутствия, а это ещё сложнее. Это значит, что я не ищу терминалы и т.п. на территориях определённых мной участков, не перепроверяю их, если они обозначены, хотя могу их удалить, если обозначены они были давно, и поменялось или закрылось содержащее их заведение. Заодно требование персонала отсекает много лишнего из amenity типа скамеек и почтовых ящиков.

Платёжный терминал

Типичный платёжный терминал в типичном магазине

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

Что ещё обычно заметно только в виде таблички:

  • мини-отели – у некоторых нет даже и таблички, а у которых есть – таблички мелкие, так как располагаются на обычной двери жилого дома, и самих отелей часто бывает несколько. В этом случае цель существования таблички – информировать о коде домофона.

  • мелкие услуги типа изготовления ключей и ремонта всякой всячины.

  • всё, что находится в бизнес-центрах, а это не обязательно офисы. Не в каждый БЦ можно свободно войти.

  • заведения социальной направленности, которые не могут или не хотят быть слишком заметными.

Если искать строго только те заведения, которые непосредственно видны, то иногда придётся пропускать даже крупные места типа больниц. Откуда я знаю, что там, где написано «больница», действительно больница, если я в ней не был? В случае с магазинами и кафе можно в окно заглянуть или, если непонятно, зайти внутрь. В общем, если вводить только непосредственно видимое, можно лишиться довольно широкого класса заведений.

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

Этим «где-то в интернете» обычно является сайт заведения или его страница в какой-либо соцсети, когда их нет, могут помочь всякие официальные документы. Понятно, что из «где-то» приходится исключить чужие базы данных типа 2ГИС, а также то, что поисковики любят показывать справа от результатов. Несколько раз я добавлял офисы компаний потому что про них сообщалось в СМИ, что бывает в связи с имущественными спорами с различной степенью криминальной составляющей.

Возможные офисы

Есть ли за этой дверью офисы, с учётом того, что на сайте соответствующих организаций про них не написано?

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

Предпочтения одних видов POI другим

Отдаю ли я предпочтение каким-либо точкам внутри обозначенного выше множества? Я не стал проверять в первую очередь «наиболее важные» POI. Как их в принципе можно было бы определить? Ну, например по нахождению на более оживлённой улице. Но я решил обойти все улицы в интересующих меня районах. Можно решить, что более важные заведения это те, которые более узнаваемы, а более узнаваемыми будут те, которые принадлежат крупной сети. Но я не ввожу в приоритетном порядке точки крупной сети только потому, что она крупная, хотя и штучным заведениям я не отдаю предпочтение только для того, чтобы поддержать их в борьбе с предполагаемым капиталистическим врагом.

Вопрос предпочтения определённых POI другим довольно легко переводится некоторыми в политическую плоскость. Например, смотрят на долю женщин среди участников, видят, что она мала, а затем делают утверждение типа «вы делаете карту, не отражающую потребностей половины пользователей». Дальше удаётся добраться до обвинений широких слоёв участников в каком-нибудь -изме, или даже в том, что они больше зарабатывают за счёт осма по сравнению с менее привилегированными классами. В данной записи на эту тему дальше рассуждать я не хочу, но могу попробовать рассмотреть упомянутое отражение потребностей тех или иных групп пользователей.

В критериях выбора POI у меня никакие социальные группы не упоминаются. Это, конечно, не означает, что мои данные будут одинаково нужны всем. Кого-то POI в принципе меньше интересуют, чем, например, состояние дорог. Можно себе представить велосипедиста, для которого я не отмечаю ни велодорожки, ни велопарковки, ни станции проката. Велосипедист может обвинить меня в том, что я поддерживаю сложившуюся ситуацию, когда предпочтение отдаётся автомобилям, ведь по моим критериям не подходят даже остановки общественного транспорта.

Автобусная остановка

Остановка не подходит, так как нет персонала

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

Некоторые участники, кстати, чаще отмечают POI определённого типа внутри обозначенного мной множества. Например, Pavel47, вводит почтовые отделения и ящики, а GaM – супермаркеты и прочие продуктовые магазины. Можно заметить, что эти точки, за исключением мелких продуктовых магазинов, отличаются большей стабильностью по сравнению с обычными магазинами, так что у маппинга отдельно «Пятёрочек» и «Дикси» смысл не только в том, что они для кого-то важнее. Несмотря на это, я пока не собираюсь придумывать дополнительные критерии для разделения POI по вероятной скорости изменения.

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

Где?

Географическое где

Ещё могут быть предпочтения географические. Обычно они звучат так: «вы отмечаете богатые районы (города, страны) более активно, чем бедные». Это уже ближе к моему случаю, ведь я маплю в основном центр, а не Купчино или Гражданку, хотя далеко не все места в центральных районах можно назвать богатыми. Объясняется это просто: я действую там, куда мне легче добраться, и до Невского проспекта мне добраться легче, чем до Невского района. Ещё я надеюсь, что центр нужен большему числу пользователей.

Адмиралтейский район

Западный край Адмиралтейского района

Систематически отмечать POI я начал с Адмиралтейского района. До того у меня была идея собирать данные по муниципальным округам. В Петербурге они меньше районов, например, в Адмиралтейском районе шесть округов. Так я делать не стал, потому что их границы неудобно для меня проходят, да и запоминать их мне лень. Между районами границы проходят более естественным образом, например, по Неве. Правда, этого нельзя сказать про границу между Адмиралтейским и Центральным районом. Например, станция метро «Адмиралтейская» находится именно в Центральном районе. В итоге после того, как я обошёл один раз все улицы Адмиралтейского района, я добрался и до Центрального.

Граница Адмиралтейского района

Железные дороги – ещё один вариант естественных границ районов

Прочие места Адмиралтейского района, где есть POI, я обхожу параллельно с улицами Центрального района. Эти прочие места, то есть дворы и всяческий indoor, уже нельзя мапить без предварительной подготовки, которая может заключаться в выяснении доступности для посещения самого места и скачивании данных в Vespucci. Этот процесс более растянут по времени, чем обход улиц, соответственно ждать, пока я обойду все дворы с POI в одном районе, прежде чем приступать к другому, непродуктивно.

POI в других местах я обычно вообще не трогаю и могу в случае несоответствия данных осма с реальностью оставить заметку с помощью maps.me, которую я сам закрывать не буду. У некоторых по этому поводу возникают вопросы, мол, раз я знаю, что тут что-то не так, то почему я не делаю правку? Ответ: потому что мне и в своих районах хватает данных для ввода, и эти данные – не только POI.

Геометрическое где

Имеет смысл объяснить здесь, как я рисую участки. Рисуются они так, чтобы внутри оказалась примерно половина ширины улицы, вдоль которой идёт проверка, и примерно половина ширины выходящих на неё зданий. Это линии вдоль «длинных» сторон участка. На его «коротких» сторонах граница участка должна проходить через угол здания, находящийся на перекрёстке улицы участка и пересекающей её улицы. Здесь может возникнуть упомянутая в прошлой записи проблема, из-за которой участки могут перекрываться: на самом углу может быть вход в POI. По ряду причин, о которых будет написано в следующих записях, мне нужно, чтобы вход был внутри участка, а угловой вход должен быть внутри двух участков, поэтому границу участка надо отодвинуть от угла в направлении от улицы метров на пять. То же самое надо сделать и для участка пересекающей улицы, и между границами этих двух участков будет часть здания, находящаяся одновременно в этих двух участках.

Прямой и срезанный угол в JOSM

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

Упомянутое выше «может быть вход» не значит, что вход обязательно есть. Это даже не значит, что есть дверь. На углу может быть и окно, а переделать на первом этаже окно в дверь достаточно легко, и это часто происходит. В итоге «может быть вход» означает «угол срезан или скруглён так, что вход там либо уже есть, либо может возникнуть без перестройки стен здания». Можно было бы перерисовать границы, когда вход появится, но хотелось бы, чтобы они были более-менее стабильны. Конечно, стабильными они не будут, если двигать и сами здания, а пока такие места, где бы их стоило подвинуть, имеются и в Адмиралтейском и в Центральном районе. Сейчас из-за этого границы участков мне приходится пододвигать, но со временем количество мест, где это приходится делать, и расстояния, на которые приходится двигать, должно уменьшаться.

Окно на первом этаже

Бывает, что дверь превращается обратно в окно

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

Прямой и срезанный угол в JOSM

Граница участков проходит через более острый угол здания

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

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

Цель этих правил – чтобы было понятно, где границы участка, не глядя на их изображение.

Когда?

Регулярные проверки

Теперь можно рассмотреть регулярные проверки, до которых я обещал добраться ещё в прошлой записи. Это те проверки на местности, при которых я выясняю, присутствуют ли и работают ли POI на всём участке целиком, и которые я делаю в те дни недели и то время суток, когда ожидаю, что большинство из POI работают. Дни недели это будние кроме понедельника, так как есть достаточно много POI, не работающих по выходным, а из будних дней самый популярный, чтобы не работать, это понедельник. По понедельникам любят не работать специализированные магазины для узкого круга покупателей, например shop=hifi. Время суток для проверки – между 11:00, когда уже открылись все, кто открывается до обеда, и 18:00, когда работающие в обычное рабочее время уже начинают закрываться. Зимой приходится заканчивать ещё раньше, потому что быстро темнеет и фотографии становится делать сложнее.

Проверки в указанное время не гарантируют, что удастся застать работающими все POI. Есть заведения, у которых в плане времени работы всё наоборот. Это всякие бары и клубы, которые могут открываться только к вечеру или из будних дней работать только в пятницу. Также бывают магазины, в которых, видимо, не ждут покупателей раньше обеда, и которые открываются, например, в час дня.

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

Гараж

Это заведение раньше пяти вечера вы не заметите

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

Нерегулярные проверки

Нерегулярные проверки – это все проверки, при которых я не пытаюсь обойти весь участок. Пока я никак не записываю их результаты, кроме ввода данных в осм. Сначала я их делать не собирался, поскольку хотел всё вводить систематически, с записью какие когда участки проверены. Но в ходе проверок для некоторых точек не удаётся собрать необходимые данные. Например, выясняется, что плохо получилась фотография, и на ней не прочитать название заведения. Иногда, особенно если вводить данные существенно позже проверки на месте, возникает подозрение, что заведение больше не работает. В этих случаях надо сходить на место ещё раз, но задерживать ввод данных всего участка до этих дополнительных проверок неудобно. В итоге сначала у меня появился список мест для повторной проверки, впоследствии превратившийся в маркеры в maps.me. После того, как разработчики maps.me «переизобрели закладки», маркеры перешли в OsmAnd.

Также к нерегулярным проверкам относятся и все случаи, когда я заметил, что открылось что-то новое или закрылось то, что я уже вводил. Сначала я это игнорировал, так как опять же хотел вводить систематически. Однако так получалось бы, что ради своего процесса ввода я оставляю неправильные данные. Данный способ обновления информации я всё равно не считаю достаточно хорошим, в связи с чем возникают организационные вопросы типа «Стоит ли продолжать вводить таким образом замеченные POI?» или «Стоит ли смотреть на магазины мимо которых проходишь, когда не делаешь регулярную проверку, а то вдруг заметишь изменения?»

Требования ко времени были для регулярных проверок, а нерегулярные можно проводить когда угодно. Проверки типа «обратил внимание на изменившуюся точку и решил записать» проводятся когда угодно по естественным причинам. Сложнее с проверками возможно закрытых или невидимых в обычное время заведений. В этом случае бывает нужно идти в определённое время, когда заведение должно работать, и это время может отличаться от обычного, например, для упомянутых выше баров.

В связи с определённым временем проверок возникают ещё организационные вопросы, например, «Что делать, если в нужное время проверку вообще не получается?» До рассмотрения этих вопросов я доберусь, видимо, через пару записей в дневнике, а в следующей записи будет рассмотрено, как я отмечаю POI.

Города на карте

Posted by CupIvan on 29 June 2018 in Russian (Русский)

Сделал карту с населённых пунктов, раскраска по населению: http://osm.cupivan.ru/place/#493/?z=7&lat=55.50&lon=42.978

На карту попадают объекты city/town/village. Можно посмотреть сколько у нас городов миллионников :-)

Надо также подумать над синхронизацией населения с википедией, есть куча устаревших данных в OSM...

UPD: добавил подсветку городов, у которых несоответствует статус place=*

Схемотехника 17, 17 июля

Posted by Sadless74 on 29 June 2018 in Russian (Русский)

Летняя встреча любителей картографии и пользователей открытых ГИС пройдёт во вторник, 17 июля 2018.

Встречаемся в 19:00 в офисе «Башня на набережной» Пресненская наб., 10, Москва, самой высокой из них. Обязательно зарегистрируйтесь, чтобы выписать пропуск. Приглашаем выступить! Напишите Илье aka Zverik тему своего доклада, чтобы попасть в программу.

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

Location: 55.746, 37.536

Сервис для построения интересных пешеходных маршрутов на базе OSM данных

Posted by Егор Смирнов on 24 June 2018 in Russian (Русский)

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

Вот пример, вместо кратчайшего пути через дворы (как поведет любой другой навигатор, что Яндекс, что Гугл, что дефолтный GraphHopper) мой ведет мимо исторического музея, Чесменской церкви и дворца и дома Советов. Примерно на 10% длиннее, но гораздо интереснее, сам таким маршрутом предпочитал ходить. Слева еще показывает список достопримечательностей со ссылками (если у объектов есть теги wikipedia или url или website):

скрин маршрута

Пока только веб-версия тут: http://sightsafari.city

Как работает: выдираем из OSM данные о достопримечательностях (объекты с тегами tourism, а так же парки, набережные и исторические здания), строим области видимости (простой raycast алгоритм), затем берем библиотеку GraphHopper для роутинга, уменьшаем веса ребер графа там где видны какие-то достопримечательности, тем самым притягивая маршруты к этим точкам.

Конечно в реальности там вагон и маленькая тележка нюансов, часть из них я описал на хабре

Пока работает только в нескольких городах (на карте выделены красным пунктиром), по заявкам добавляю новые. Можно тестировать и писать отзывы в группе ВК

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

Пройдемся еще раз по лесу и его проблемам разметки на карте.

Posted by Sowa1980 on 23 June 2018 in Russian (Русский)

Пройдемся еще раз по лесу и его проблемам разметки на карте.

Визуальное отображение деревья на карте и в редакторе JOSM

Posted by Sowa1980 on 23 June 2018 in Russian (Русский)

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

И как тут не вспомнить фильм 5 элемент, когда Руби Род после эфира спрашивает у ассистентов: "Как прошло?", а они ему: "О, зелено!", он им: "Как зелено!!!?", они ему: "О, зелено, зелено, зелено!!!!!! " :-)

Что бы хотелось видеть, это визуальное отображение данной информации на карте и в редакторе JOSM

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

Что это дает:

  1. Первое это улучшенное ориентирование на местности.
  2. Упрощает редактирование карты.
  3. Достижение конечных целей и поставленных задач, к примеру, при по ходе за грибами, так как грибы произрастают в конкретных лесах определенного типа.
  4. Важный аспект при планирование отдыха или занятиями спорта, знания лесного массива его породной составляющий для людей с заболеваниями сосудистого-сердечного-легочного характера, для которых переизбыток кислорода или нехватка токового может оказаться под час причиной летального исхода. Не в меньшей степени это касается и здоровых людей, ведущих не активный образ жизни, городских жителей. Многие леса просто не предназначены для некоторых видов спорта, или же недостаточно хороши для них.
  5. Это размножение, миграция, насекомых, животных и птиц в определенные сезонные периоды времени, а также их заболевания – эпидемии, что может повлечь за собой неблагоприятные последствия как для людей так и животных.

И напоследок очень хотелось бы видеть данный стиль встроенным в редактор JOSM по умолчанию и данную информацию о деревьях на карте,

В качестве послесловия обращение к разработчикам :

Пусть мама услышит пусть мама придет Пусть мама меня непременно найдет :-)

Из мультфильма «Мама для Мамонтёнка, песенка мамонтенка.

Как я отмечаю POI – Метаданные

Posted by Anton Khorev on 19 June 2018 in Russian (Русский)

Почему пришлось взяться за POI

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

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

Мы знаем, что объекты на местности могут меняться, причём разного рода объекты будут меняться с разной скоростью. Из перечисленного выше, улицы меняются редко: иногда появляются новые, иногда продлеваются старые, иногда у них меняется название, и можно считать, что они практически никогда не исчезают. Правда, они могут закрываться на ремонт, что важно для навигации, но за этим не так сложно уследить, потому что самих улиц мало относительно других перечисленных выше объектов. Здания тоже меняются редко: иногда строятся новые, иногда перестраиваются старые. Во временных масштабах существования осма, отрисовка зданий – почти одноразовое дело.

Другое дело – магазины, кафе и т.п. По весьма примерным подсчётам их «время полураспада» составляет 5 лет. То есть если вы их все отметите и подождёте 5 лет, половина из них уже не будет существовать. И если их много, то найдётся какой-нибудь магазин, который закроется или откроется практически сразу после вашей проверки. А их очень даже может быть много – так много, что они на рендер не поместятся. Значит, просто один раз сходить и отметить подобного рода точки, а затем считать, что дело сделано, не выйдет.

Я хочу, чтобы данные о POI в осме были как можно ближе к действительности. Ясно, что для этого придётся перепроверять уже однажды проверенные места. Решать вопрос, куда и когда идти проверять можно по-разному, но при этом не обойтись без информации о том, когда производилась предыдущая проверка. Есть ли в данных осма такая информация?

Время проверок

Первое, что можно вспомнить, это время создания пакета правок. Однако, это время вовсе не обязательно совпадает со временем, когда редактирующий участник видел точку на месте. Строго говоря, оно всегда не совпадает, потому что правка делается позже проверки. Можно, конечно, пытаться делать правку сразу, но часто бывает некогда. Например, я сначала ставил себе задачу вводить данные на следующий день после проверки, потом срок превратился в две недели, теперь я рад, когда отстаю меньше, чем на два месяца. Иногда правка точки вообще не означает, что участник её видел или проверял каким-либо другим способом, например, сдвиг здания вместе со всем его содержимым или замена url. Короче, время проверки надо брать из какого-то другого места.

Вторая идея – пользоваться тегом check_date. Для POI он редко используется, так что первый недостаток – то, что придётся тегировать под x, где x – организация процесса обновления данных о POI. Может возникнуть вопрос, а уместна ли в принципе простановка на точки, линии и отношения тега check_date и подобных ему метаданных. Если нет, то мы могли бы его ставить на пакет, ведь у пакетов тоже есть теги. Тогда, правда, придётся аккуратно делать пакеты, чтобы они не затрагивали лишнего. Такая же проблема была бы и при использовании даты создания пакета, но проблема эта не единственная.

Другим источником проблем является то, что проверять приходится не сами точки, ну или не только сами точки, а ещё и места, где эти точки могут быть. Изначально в данных осм точек нет, так что и check_date искать не на чем. Допустим, мы ставим дату проверки на пакет, и список пакетов, в которых её надо искать, мы составим вручную, чтобы не просматривать все пакеты, затрагивающие интересующее нас место. Но что нам делать, если мы пройдём по месту, и увидим, что в соответствующих ему данных ничего менять не надо. Например, там как не было POI, так и нет. Тогда и правок делать не надо, пакет создавать не из чего, дату проверки писать некуда и читать неоткуда. И, вообще-то, мы так и не определили, что такое интересующие нас места. В осме таких объектов точно нет.

Места проверок

Становится понятно, что придётся задать информацию о местах за пределами данных осма, и информацию об их проверках тоже хранить не в осме. И подобное уже реализовано в MapCraft. Но эти нарезки носят одноразовый характер: вот вам участок, где что-то не нарисовано, пойдите нарисуйте, затем отметьте, что задача выполнена и всё. А у нас – не всё, нам надо перепроверить участок через некоторое время, и сами участки должны быть определены с учётом таких перепроверок.

Нарежем всю территорию, которую хотим проверять, на участки по-своему. Участки нам нужны достаточно небольшие, чтобы каждый из них можно было целиком проверить за один заход. Большинство интересующих нас POI видны с улицы, следовательно в качестве участков подойдут части кварталов, выходящие на определённые улицы. Так можно будет проверить весь участок, даже если он не являлся целью похода. Просто идём мимо, вдруг появляется желание помапить, и начать мапить можно, дойдя до следующего перекрёстка.

Естественное желание – сделать участки непересекающимися, чтобы любая точка попадала только в один из них. Но так не выйдет, потому что некоторые заведения находятся на углу квартала, причём даже вход в них находится прямо на углу. Да и физически POI не являются точками, а значит никто не мешает рисовать их полигонами, а полигон запросто может пересечься с несколькими участками. Полигоны для POI, правда, обычно не используют, к причинам этого мы ещё вернёмся. Итого наши участки могут перекрываться, особенно на углах кварталов, и POI может находиться одновременно в нескольких участках.

Помимо POI, выходящих на улицу, есть ещё POI во дворах, подземных переходах, торговых комплексах, бизнес-центрах. С ними иметь дело сложнее, и они для меня являются второстепенной задачей. Первая сложность тут ещё со сбором данных: их не видно с панорам улиц, и gps рядом с ними не работает, значит пройтись на месте с OsmTracker'ом, а вводить уже потом за компом не получится. Поэтому я пока не брался за ТК и не решил, на какие участки их делить. Весь ТК как один участок – это, наверное, слишком много с точки зрения «целиком проверить за один заход». Если делить, то, видимо, на этажи, хотя тогда получатся не просто перекрывающиеся участки, а полностью совпадающие в проекции на плоскость, а это по ряду причин неудобно.

Со внутриквартальными POI есть свои сложности. В центре Петербурга, как правило, зайти во двор можно через арку, а далее пройти можно только в ограниченную часть квартала. Часто из двора определённого дома никуда попасть нельзя, кроме как обратно на улицу. В этом случае можно сделать участком весь этот двор. Но если таким образом доступна большая часть квартала, да и сам квартал большой, то делить на участки придётся как-то по-другому. В новостройках придётся, видимо, делить вдоль внутриквартальных проездов. Мне это предстоит делать уже и в Центральном районе рядом с Московским вокзалом.

Метаданные проверок

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

Информация о том, когда была произведена проверка, представлена в виде даты. Точнее даты время мне знать не нужно, соответственно я не слежу за тем, во сколько часов сколько минут я начал проверять определённый участок, главное, чтобы это было время регулярной проверки, об этом позже. Другой вопрос – не нужно ли специально хранить менее точные данные, например, из соображений privacy. Когда я начну принимать данные от других участников, мне, возможно, придётся вернуться к этому вопросу. По поводу намеренного предоставления менее точных данных есть две точки зрения. Одна из них – что для недавнего времени надо давать менее точную информацию, а позже её можно уточнить. Другая – что наоборот по прошествии времени данные надо делать менее детальными. Мне больше подходит первый вариант, в том числе потому что он получается сам собой. Собранные данные я ввожу не сразу, так что если вы захотите узнать, где я сейчас нахожусь, глядя на предоставляемые мной данные о проверках участков, то я уже давно оттуда ушёл. Вторая точка зрения связана с тем, что при точных данных о том, где кто когда был, идущих далеко назад по времени, можно сделать вывод, какие места данный человек имеет обыкновение посещать, например, в определённый день недели. Но те места, информацию о которых я ввожу в рамках данных проверок – это не те места, в которые я хожу с какой-либо другой целью. В большинство проверяемых заведений я вообще не захожу.

Что касается третьего элемента в записи – номера пакета правок, то как мы уже знаем, его может и не быть. Соответственно, уже с самого начала его указывать было необязательно. Тут можно поинтересоваться, зачем в принципе записывать пакет, ведь дата проверки берётся не из него. В данный момент это просто средство для меня, чтобы искать пакеты правок, относящиеся к определённому месту. По обычной истории правок это делать неудобно. В идеале хотелось бы иметь способ получить всю информацию по POI, признанную мной правильной на момент проверки, и она содержалась бы в пакете, если бы правки в обязательном порядке затрагивали все точки и, желательно, ничего кроме точек. Но это не так, хотя отчасти я пользуюсь записанными пакетами в качестве временного средства сделать snapshot данных. (примечание на июнь 2018: кое-что поменялось между написанием и публикацией; собственно snapshot уже делается, и полей в соответствующем csv-файле уже не три)

Далее обнаружилось, что не всегда реально сделать правки для всего участка за один заход. Соответственно, пришлось разрешить указывать множество пакетов правок для одной проверки. Связано это с тем, что попадаются участки, на которых может быть хоть пятьдесят POI, например, Лиговский проспект между площадью Восстания и Транспортным переулком (1, 2), и это если исключить из него Московский вокзал и «Галерею». Придумывать особенный способ деления на участки поменьше для «POI-плотных» мест мне не хочется, так как при текущем способе деления границы участков очевидны даже без разглядывания картинок, где они нарисованы, тем более, что изначально они не были нарисованы.

Метаданные участков

Сначала данные об участках содержались в первую очередь в их названиях. Названия эти состоят из названий улиц и диапазонов номеров домов. Названия улиц не уникальны во всём субъекте федерации, но уникальны внутри центральных районов. В районах, включающих разные населённые пункты, типа Пушкинского, подобной уникальности может уже не быть, но ими я пока систематически не занимаюсь. Если к названию улицы добавить номера домов, то так можно задать сторону квартала, выходящую на определённую улицу – тот тип участков, которые я проверяю в первую очередь. Проблема тут в том, что номеров по нужной улице может не существовать. Улицами здесь я называю всё, что в Петербурге официально ими считается, и отображается зелёными линиями в rgis. Это включает и площади, а по ним часто не бывает номеров, тогда в название участка приходится вместо них писать, какая это сторона, например, юго-западная. Даже если номера и есть, то они не всегда очевидны, их может не быть в осме и так далее. Дополнительно к номерам я решил давать текстовое описание, которое позволит в сочетании с именем участка найти его, даже если я ошибусь с номерами. Сначала это привело к появлению ещё одного csv-файла с записями (название участка, описание).

Через некоторое время это стало неудобно, ведь по прежнему не было никаких машиночитаемых данных о расположении участков. Расположение можно задать, нарисовав полигон, покрывающий участок. Несвязные участки, для которых это не сработает, скорее всего, не понадобятся. Так как я ввожу данные из josm, то и участки легче рисовать в нём же. Поскольку участки не являются данными осма, то их можно держать в отдельном слое. В нём можно рисовать полигоны и задавать им теги name и description для того, что было в csv-файле. Данные самих проверок, в принципе, тоже можно было бы сохранять в тегах полигона, но это менее удобно, и пока я этого не делаю. Слой с участками сохраняется в файл, а не закачивается в базу осма.

Недостатки у работы со слоем-файлом такие:

  • А вдруг его случайно закачаешь, тем более, что josm будет предлагать это сделать, если вносить изменения. К счастью, вскоре после того, как я перешёл к использованию слоя, в josm была добавлена возможность запретить закачивать слой, если в его файле есть xml-атрибут upload='never', поставленный на корневой элемент. Достаточно один раз его вручную поставить, и этот недостаток исчезает.

  • А вдруг в него случайно скачаешь данные осма, ведь их в нём быть не должно. Операцию скачивания ещё и нельзя отменить, так что приходится следить, какой слой выбран, и хранить версии файла, например, в git, чтобы в случае скачивания и сохранения лишних данных можно было бы откатиться к «чистой» версии. Впрочем, недавно был добавлен и атрибут download='never'.

  • josm всё-таки предназначен для редактирования данных осма, и у всех объектов должен быть осмовский идентификатор. А какие идентификаторы у объектов, которых в осме нет и не будет, то есть у наших участков? Всему, что не закачано, josm даёт временные идентификаторы – отрицательные числа - но нет гарантий, что они постоянны. А если мы начали пользоваться системой контроля версий, то изменения идентификаторов для нас нежелательны. Можно попробовать переустановить идентификаторы перед записью в git так, чтобы изменений было поменьше, но пока я этим не занимаюсь.

Теперь у нас есть набор метаданных, пригодный, например, для визуализации свежести данных POI. Про сами эти не-мета-данные POI будет написано в одной из следующих записей дневника.

Обновление 4.3

Posted by Валерий Семенович on 13 June 2018 in Russian (Русский)

Подскажите кто - нибудь, почему на обновленной версии 4.3 навигатор Ситигид не подводит непосредственно к адресу ? г. Великий Новгород

Смостоятельная конвертация карт для Garmin

Posted by LLlypuk82 on 10 June 2018 in Russian (Русский)

Преамбула

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

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

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

Подготовка необходимых программ и файлов

  • Windows 7/8/10 (желательно x64) (можно и linux-систему, но там свои особенности и заметка не об этом)
  • Java (желательно именно x64 под соотв. Win, чтобы иметь возможность выделить приложению более 3Гб оперативной памяти)
  • Собственно конвертер mkgmap
  • Обработчик границ splitter
  • Сами границы в виде архивов bounds.zip и sea.zip (скачать там же), это специально подготовленные файлы для корректной обработки адресной информации и контуров морей (подробностями не владею, но, в общем, в них и нет необходимости, а почитать можно на сайте разработчиков)
  • Исходные («полусырые», т. е. уже специально обработанные) osm-данные вашего региона или страны в формате pbf можно скачать [1] или [2] (тут, к сожалению, периодически возникают технические проблемы, как на момент создания заметки, прерывающие ежедневное обновление файлов, что наводит на мысль научиться самому выполнять и данный промежуточный этап конвертации, дабы в ещё меньшей степени зависеть от сторонних сервисов) Небольшое (но важное) дополнение: знающие люди подсказали, что можно обновлять уже имеющийся (скачанный однажды) pbf-файл с помощью программы osmupdate (к ней также необходимы osmconvert и wget) Всё работает и можно получать самые свежие данные (вплоть до минутных изменений, считая от начала запуска обновления). Таким образом можно поддерживать исходный файл всегда в актуальном состоянии и не зависеть от проблем у сторонних сервисов (кроме osm.org, конечно)
  • Файлы, отвечающие за стиль (графика и текст) готовой карты. Здесь могут быть варианты, поскольку существует множество кастомных наработок. Я брал за основу стиль stranger, ветка форума от автора, и дорабатывал его под себя (добавил или поменял некоторые значки, текстуры, добавил направление водотоков, отображение подъездов с номерами квартир и т. п.), что при желании может делать каждый, немного покопавшись в исходных файлах (и в этом ему поможет утилита TYPViewer), но это отдельная тема, углубляться в которую не буду. Вот ссылка на мои исходные файлы, касаемо стиля (заодно и bat-файл, запускающий конвертацию со всеми параметрами) для примера и основы

Конвертация

Итак, всё необходимое скачано, архивы распакованы. Желательно выделить под это отдельную папку и в ней раскидать в подпапки с названиями, набранными латиницей (нето могут возникнуть проблемы, т. к. утилиты просто не умеют читать кириллицу и не смогут воспринимать пути в конфигах, выдавая ошибки вида «file not found»)

Далее надо подкорректировать в bat-файле все директории в соответствии с вашими файлами и папками, после чего запустить его. В указанной вами папке (у меня это output-dir="%BASEDIR%\output\my Stranger") вы получите набор файлов, из которых понадобится только gmapsupp.img Его надо просто скопировать (можно переименовать при необходимости, не меняя расширение после точки) в память навигатора или на флешку в папку Garmin.

Примечания и дополнения

Ключ --copyright-message влияет только на выводимую надпись о правах (она не обязательна, если вы делаете карты сугубо для своих нужд), то же касается и ключей --series-name, --family-name, --description, --country-name, --country-abbr. А вот --product-id и --family-id могут повлиять на совместимость с другими уже установленными картами (у меня бывало так, что совместно некоторые не хотели определяться навигатором eTrex20) Ключи --charset=cp1251 и --code-page=1251 отвечают за кодировку для шрифтов. Также обратите внимание на --name-tag-list=name,name:ru,name:be,int_name, что задаёт последовательность выборки и присваивания названий для всех объектов (если не отыскивается первое значение, то ищется следующее и т. д.)

Ещё важные моменты: для сплиттера указывается ("%BASEDIR%\pbf\belarus.osm_24.05.18.pbf") директория исходного файла и директория для результата нарезки (--output-dir="%BASEDIR%\input"), она же станет исходной для mkgmap.

Если добавить ключ --gmapi, то дополнительно будет создана папка «Название стиля.gmap», а в ней будут файлы, которые можно использовать в BaseCamp или Mapsource для просмотра карты на компьютере. Достаточно скопировать папку "*.gmap" по указанному ниже пути (в зависимости от ОС компьютера): для WinXP путь C:\Documents and Settings\All Users\Application Data\GARMIN\Maps для Win7/8/10 путь C:\ProgramData\Garmin\Maps или скопировать туда же ярлык на вашу папку (не важно, где она была создана), и потом выбрать из списка карт в BaseCamp вашу. Это позволит заодно и протестировать её, не загружая в навигатор.

Вообще, вместе с mkgmap есть справочные файлы (на английском), где расписаны значения ключей (doc/options.txt) и есть manual по программе.

PS

Надеюсь, данная заметка поможет читателю освоить, в общем-то, несложный процесс конвертации карт под свой любимый garmin. Ведь повозиться с наладкой/подготовкой придётся лишь единожды, а потом будет достаточно заменить исходный файл pbf на свежий и прописать его название в bat-файле. Поскольку у меня это происходит нечасто, я делаю это вручную, равно как и запуск конвертации (хотя, умельцы могут и автоматизировать все эти процессы).

Северо-Западный велорейд

Posted by StrangeStranger on 7 June 2018 in Russian (Русский)

Всё-таки свершилось!

Осматриваюсь на предмет укусов всяких кровососущих и репяхов, лёжа на диване, побаливают от усталости глаза, постанывают ноги... Потому что поехал немного дальше и свернул, куда не планировал: чёртово любопытство!

Откуда-то на дачах взялся асфальт. Сам удивлён; в итоге занимался, по большей части, им.

Затем поехал по делам в город, посетив место потерянных тегов. Как чуял перемены. Дорожки "мои" понемногу зарастают, но до смены тега с грунта на траву ещё далеко. Кое-где зачем-то настелили шлак. Снесли наполовину старый сад, там теперь стоит сельхозтехника.


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

Организационно-правовая форма, право на жизнь данного тега в базе OSM,

Posted by Sowa1980 on 7 June 2018 in Russian (Русский)

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

Вопрос к сообществу какой тег лучше и правильней применять для этого: согласно Google Переводчик Организационно-правовая форма переводится как "Organizational and legal form" отсюда правильным можно считать operator:ref:olf=* , но исходя из сокращений принятых и используемых в русском языке должно получится так , operator:ref:opf=* по аналоги с сокращением для ИНН.

пока вношу аналогичными в базу, страница в форуме на обсуждение https://forum.openstreetmap.org/viewtopic.php?id=62579

По итогам обсуждения на форуме и чата были выработаны теги: для полного названия legal_form= Акционерное общество; для сокращенного названия legal_form_short=АО