OpenStreetMap

Diary Entries in Russian

Recent diary entries

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

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: Москва-Сити, Пресненский район, Центральный административный округ, Москва, Центральный федеральный округ, РФ

Сервис для построения интересных пешеходных маршрутов на базе 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=АО

Материал зданий или материал стен, что мы тегируем? Неправильные теги в OSM !!!

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

building:material согласно Google Переводчик переводится - строительный материал и чисто логически это материал из которого построено здание, но в OSM в этот тег принято пихать бог весть что, от отделочного материала стен, до материала из которого построено само здание. А между тем это разные вещи. Предлагаю закончить этот бардак и исправить сложившуюся практику, для указания отделочного материала стен предлагаю применять тег facad:material=материал.

Элементарный пример новое здание построенное из силикатного кирпича, Вы затегировали , как building:material=silicate brick, через какое то время, здание решили оштукатурить или закрыть фасад каким то другим способом, к примеру сайдингом, и вот новый мапер берет и затирает ваши теги, как неправильные. Первое вы потратили свое время в пустую, второе, это то что здание не соответствует действительности, здание как было так и осталось построенное из кирпича, но лишь приобрело новый материал отделки стен с целью защиты самого здание от влаги и разрушения, так как всем известно силикатный кирпич, разрушается от влаги. Пришел еще один мапер глянул батюшки, а этот тег не верен, так как его хозяин заменил , пластиковый сайдинг пришедший в негодность отделочной плиткой, и вновь затер тег, и так может продолжаться до бесконечности, я буду тупо ставить туда материал здания, другой, матерьял отделки стен. А человек на местности тупо будет видит не ту картину. И мало того придется вечно править мне и отслеживать , эти изменения, пустая робота - мартышкин труд, так кажется это называется. Для того и хочется что бы уже все стало на свои места в тег building:material=* вписывать материал самого здание , в тег facad:material=* указывать отделочный материал фасада здания.

Что это даст : 1 - это четкое понимание что , вы затегировали, 2 - избавит ой войны правок. 3- Отобразит реальную картину вещей. То есть все станет на свои места и будет разложено по полочкам.

Прошу OSM сообщество вынести это на обсуждение. И закрепить это в https://wiki.openstreetmap.org/. За собой оставляю пока право разграничивать и пользоваться такой схемой. По выше описанной причине. Страница для обсуждения на форуме https://forum.openstreetmap.org/viewtopic.php?id=62582

Упорядочивание проектов

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

Сегодня наконец-то дошли руки до сортировки веев в отношениях при отрисовки контуров на карте, теперь домики рисуются корректно, а не как каляки-маляки в некоторых случаях :-D

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

1_06_2018

Posted by Profesor on 31 May 2018 in Russian (Русский)

С первым днём лета!

Намечается мапперский велорейд

Posted by StrangeStranger on 28 May 2018 in Russian (Русский)

Произошло нечто подозрительное: у некоторых дорог послетали теги smoothness и даже surface. Причём слетели они так, будто их никогда и не вводили. История правок тоже подталкивает к этому выводу, хотя и неверному.

Уверенность в этом потому, что из навигаторов использую только OsmAnd. У меня полная версия (не Маркетом единым живёт Ведроид), обновы карт качаю самое редкое раз в месяц (OsmAnd Live - хоть ежечасно, хотя данные для brouter обновляются трижды в месяц), поэтому данные актуальны. В профиле для велосипедизма с самого начала настроил отображение тегов surface и smoothness, чтобы перед поездкой проверять сгенерированные маршруты на адекватность. В нашем городе сложилась традиция указывать на дорогах, тем более важных, оба этих тега; любое отклонение от неё видно на дисплее сразу же. Собственно, так и обнаружилась пропажа. Предположительно, это произошло в уходящем месяце.

Пока писал текст, вспомнилось: где-то в начале мая был какой-то сбой в OsmAnd Live: скачивание обновлений не работало несколько дней. Не глючу ли я сам? Или это как-то связано со случившимся?

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


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

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

Сезон в разгаре

Posted by StrangeStranger on 24 May 2018 in Russian (Русский)

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

Хотя по своему, теперь уже горячо любимому, спуску я проехался повторно, всё никак не доберусь до его тегирования по горно-велосипедной части. Инструментальные измерения там можно проводить только пешком; живу я оттуда далековато; велосипед оставлять без присмотра опасно как наверху, так и внизу. Видимо, прибегну к данным SRTM.

Спуск с горы


Осмографировал местность до недавнего времени рейдовым способом, унося данные в собственной голове, и без того всё время перегруженной оперативными данными. Начал осознавать, что вскорости перестанет помогать даже мнемотехника (наряду с космоснимками), посему задумался о некой записной книжке, где бы рисовал обследованные (чаще с приставкой пере-) объекты. Но ведь подчас удобнее вносить правки сразу на месте! Вот так и вспомнил про Vespucci. Хотя рисование на тачскрине сродни вертелу в пекле, для мелких уточнений вполне сносно. Зато тегировать - рай: хочешь - заготовки применяй; желаешь набирать по буквам - соседняя вкладка и набирай хоть до дыр в экране; рядышком - отсылка в вики по тегам... Поэтому всё больше оперативных правок карты у меня с телефона.

Вот только josm я не брошу. Почему - ни для кого здесь не вопрос. Тем более привык я к нему и некоторым модулям: по-прежнему наблюдаю за обновлением космоснимков (раз уж взялся); соскучился по применению gpsblam. Эта парочка-связочка ещё потрудится.


...Ну а пока - пока!

У фонтана

Курск

Posted by vitaliy_casper on 13 May 2018 in Russian (Русский)

Привет всем. Я облагораживаю центр города Курска, в основном мелкие детали и обновляю данные об объектах, т.к. жизнь не стоит на месте...

Location: Казацкая, Центральный округ, Курск, городской округ Курск, Курская область, Центральный федеральный округ, 305000, РФ

Полное редактирование города Торжка.

Posted by Sergey_sheglov on 10 May 2018 in Russian (Русский)

Цель задания - восстановление объектов "на свои места". Исправление ошибок необозначенных зданий, Удаление несуществующих зданий, проведение исследования при помощи GPS трекера для вырисовки дорог невидимых с космоса.

Location: Торжок, городской округ Торжок, Тверская область, Центральный федеральный округ, 172000, РФ

Родники "Мурованка"

Posted by alexandr1271 on 5 May 2018 in Russian (Русский)

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

Location: Мурованка, Молчадь, Молчадский сельский Совет, Барановичский район, Брестская область, 22530, Беларусь