OpenStreetMap

Anton Khorev's diary

Recent diary entries

Как я отмечаю 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.

Как я отмечаю 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 будет написано в одной из следующих записей дневника.

Как я отмечаю POI – Пролог

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

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

Действительно, далеко не всегда присутствие точки на карте соответствует её существованию на месте. Вот случай, произошедший со мной в период моей неактивности в osm в середине 2010-х. Иду я в Сбербанк, а там выясняется, что не работает устройство, печатающее талончики, и надо вставать «в порядке живой очереди». А зачем мне это, если я могу дойти до другого отделения, которое рядом. То, что оно рядом, я знаю, ведь у меня в телефоне OsmAnd, и само это отделение, вроде бы, я лично ранее ввёл. Однако по прибытии на место выясняется, что этого отделения нет. Тогда я иду ко второму ближайшему согласно данным osm отделению. Его тоже нет. Обнаружилось только третье отделение, в котором выяснилось, что мне нужно идти именно в то, в которое я пришёл сначала, а не в любое, но это уже не проблемы osm. Проблемы osm заключались в устаревших данных poi, и эти проблемы я пытался начать исправлять как за несколько лет до случая со Сбербанком, так и после, но дело дальше планирования и сбора небольшого количества данных не уходило.

Первые свои poi я вносил вместе с данными о кварталах Адмиралтейского района СПб в 2011-2012 году. Это были данные обо всём подряд внутри квартала целиком. Контуры зданий, этажность, арки, проезды, проходы, газоны, деревья; позже – входы в здания с номерами лестниц и квартир. Большинство подобных объектов меняются редко, в отличие от магазинов и прочих poi, следовательно потом нужно будет заниматься отдельно обновлением исключительно poi. Делать это будет несколько легче, чем мапить всё подряд, в том числе и потому, что большинство магазинов видны с улицы, и не нужно пытаться пролезть в не всегда открытые дворы.

Этот маппинг всего подряд я выполнял по подобию того, что делал участник fserges, который тогда тоже занимался Адмиралтейским районом. Он рисовал южную часть района, а я – северную. Позже, при выборе места для очередной картовстречи, fserges напишет на форуме, что он уже всё отмапил на Красноармейских улицах, находящихся в его части района, и идти туда вроде как не нужно. С тех пор я там уже тоже всё, что видно с улицы, перепроверил и переобозначил по крайней мере один раз, но понятно, что всё это придётся неоднократно повторить. Как часто надо повторять – один из вопросов, на которые я пытаюсь найти ответ.

Если сейчас данные о внутренностях кварталов, парков и зданий я ввожу на месте в Vespucci, то в те времена приходилось рисовать на бумажке. И с poi было особенно неудобно разбираться, потому что для того, чтобы не загромождать схему местности на бумаге записями о точках, их лучше фотографировать. Для этого надо было взять в руку телефон, но обе руки были заняты ручкой и бумажкой. В итоге ввод poi не был тогда для меня приоритетной задачей, и я не пытался вводить их контактные данные, режимы работы и прочие подробности.

Осенью 2011 у меня появилась ещё одна задача: маршруты общественного транспорта. В Яндексе данные по остановкам были неточные, транспортного портала ещё не существовало, и получалось, что надёжного источника данных вообще не было. Что я по этому поводу делал – отдельная история, к poi прямого отношения не имеющая, так как здесь речь идёт о poi «магазинно-кафейного» типа, а не об остановках. На одном из этапов сбора данных о маршрутах я шёл как можно дальше вдоль основных улиц и смотрел, какие на них находятся остановки, и транспорт каких маршрутов по ним проезжает. Расстояние между остановками большое относительно расстояния между упомянутым выше всем подряд, следовательно, существенную часть времени я просто шёл. Ясно, что более полезно было бы заодно собирать какие-нибудь данные, и в некоторых случаях я так и стал делать.

Для сбора данных об общественном транспорте ручка и бумажка уже не нужны, достаточно делать фотографии и записывать их с помощью OsmTracker'а. На gps можно рассчитывать в большей степени, чем во дворах, кроме того, нужное место на фотографии можно сравнить с Яндекс-Панорамами. То же самое можно сказать и о сборе данных о poi, которые я и стал собирать, пока ходил от остановки к остановке. Но все эти данные о poi так и не попали в osm, потому что недостаточно их собрать, надо ещё их ввести, а вводить их дольше, чем собирать.

Помимо того, что на это нужно время, ещё одной причиной неввода стало то, что я представлял себе, какие мне нужны инструменты для решения определённых задач, связанных с редактированием poi. Вот одна из таких задач. Как это отчасти видно из приведённого выше второго поста fserges'а, обычной ситуацией является нежелание мапить уже отмапленное, несмотря на то, что, как видно из первого поста, ясно, что poi на местах меняются. Это можно объяснить так. Допустим, что poi в каком-то месте вообще не отмечены. Тогда никакой рендерер не рендерит их значков, и видно, что это место пустое. Теперь мы пошли и их отметили, и место стало непустым, на нём появились значки. Результат наших действий ясно виден, причём виден даже тем, кто не знаком с данным местом. Прошло какое-то время, и данные устарели, их надо вводить по-новой. Но значки с рендера от этого не исчезли, и незнакомый с местностью разглядывающий карту участник по прежнему будет видеть, что вроде как тут всё отмаплено. Если мы перемапим данное место, то подобный участник не заметит разницы: была куча значков и стала куча значков. То, что это куча значков новая – на ней не написано. Значит надо сделать так, чтобы было видно, где куча значков новая, а где старая.

Инструменты, конечно же, сами не напишутся (и всё, что я хотел, до сих пор не написано), а обновление данных я откладывал до написания инструментов. В 2013-2015 годах я несколько раз предпринимал попытки собирать данные, но в итоге за это время я не сделал вообще ни одной правки. Наконец мне просто надоело, что всё, что я тогда делал, было связано с сидением на стуле за компом, а osm – это, по крайней мере, не постоянное сидение на стуле, и я решил взяться-таки за ввод poi без предварительного написания инструментов. Тогда я думал, что дело будет выглядеть так: раз в неделю я буду где-то в течение часа в качестве «обеденного перерыва» ходить и собирать данные о точках внутри определённого муниципального образования, делать это я смогу по дороге в какое-либо место в промежутке между другими делами; таким образом я смогу поддерживать данные в состоянии полугодичной-годичной свежести. В итоге всё получилось, конечно, не так, особенно «в течение часа», да и область действия пришлось сразу поменять из-за того, что по дороге куда-либо я довольно быстро пересекал границы МО.

28 сентября 2016 года я отправился собирать данные, которые, наконец, попадут в osm. Ну а сейчас я собрался начать об этом писать, и в одной, а скорее всего более, чем в одной, из следующих записей я расскажу о том что, где, когда и каким образом я маплю в плане обновления данных о poi.

Maps.me для тех, кто не пользуется maps.me

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

Недавно в дневнике одного из участников была опубликована запись (теперь уже отредактированная) про модерацию в российском разделе форума. Ряд участников, обратив внимание на вклад автора, посчитал нужным отметить, что эта запись по сути является анонимной, что позволяет не относиться к ней серьёзно. Одной из высказанных в записи мыслей является то, что один из модераторов форума, Zverik, является также разработчиком maps.me, что может влиять на его действия при обсуждении этого приложения и, особенно, использования этого приложения в качестве редактора. Активным участникам всё это и так известно, и мне, казалось бы, нет необходимости упоминать здесь эту запись, однако некоторые комментарии к ней вызывают интерес. Автор записи, в частности, отмечает, что на форуме была закрыта тема «Ошибки пользователей редактора maps.me». Закрыта она была, так как модераторы посчитали, что обсуждать этот предмет надо в общей теме про maps.me, а обсуждение в теме ошибок имеет тенденцию переходить к оскорблениям в адрес модератора-разработчика. Тут следует заметить, что Zverik непосредственно перед публикацией записи сделал несколько неудачных высказываний на форуме, например о том, что одним из правил является недопустимость оскорблений особенно разработчиков, хотя понятно, что такого правила нет и быть не должно. Однако в комментариях к записи были сделаны и более радикальные замечания, в частности о том, что русский раздел форума вообще не предназначен для обсуждения maps.me. Сам Zverik с подобными утверждениями согласия не выражал.

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

Допустим, что мы решили, что две темы про maps.me на форуме – это нормально. В этом случае всё равно можно возразить, что одна из них имеет негативный характер, так как у неё в названии содержится слово «ошибки». А что, собственно, заслуживает обсуждения – правильные правки? В осме, например, есть обсуждения пакетов правок. Для чего им пользуются? Ну иногда для того, чтобы сказать автору правки, что он занимается вандализмом, ведением войны правок и всё ломает (это были примеры комментариев к некоторым моим правкам), но обычно это обсуждение реальных или потенциальных ошибок. Так что ошибки в осме обсуждаются, а если кто-то захочет перейти к замечаниям про вандализм и т.п. в форме, неприемлемой для форума, то на этот случай есть модераторы, которых помимо Zverik'а ещё два. Если вам кажется, что форум – не место для обсуждения ошибок, потому что существует упомянутое выше обсуждение пакетов правок, то вы должны быть и против темы «откаты правок». Вы можете сказать, что «откаты правок» - для тех случаев, когда обсуждение пакета не помогло. Ну так и в случае с правками из maps.me оно не поможет.

Ошибки в правках как особенности редакторов

Многие ошибки в редакторах, ориентированных на новичков, объясняются особенностями самих редакторов. Maps.me – это редактор не просто для новичков, а даже для тех, кто не понимает, где именно он редактирует данные, и даже что действия из редактора являются именно редактированием общих данных. Но ведь maps.me используют не только новички, но и опытные участники. Можно же им редактировать и не делать всего того, про что написано ниже? При определённых условиях можно, и я об этом писал (например, про перекрывание доступа в интернет для maps.me с целью последующей проверки пакета в josm), но нередко и опытные участники делают всё то.

Чтобы показать, что я не придираюсь именно к maps.me, рассмотрим для начала другой редактор – iD. Вы, возможно, видели, как в правках из этого редактора некоторые точки, например, точки дорог оказываются перетащенными на существенное расстояние. В результате получается ломаная линия, проходящая сквозь препятствия в виде зданий, пересекающая другие дороги без общей точки пересечения и т.п. Ясно, что это не имеет смысла, и у вас может возникнуть мысль про выполнившего данную правку типа «он что, идиот что ли?» Но он, скорее всего, не идиот, и здесь имеет место особенность редактора. Возьмём хорошо известный вам josm. Какой кнопкой мыши вы перетаскиваете точки? Левой. Какой вы перемещаете область редактирования? Правой. А что в iD? Точки перетаскиваются левой, область прокручивается тоже левой. Если вы предпочитаете josm и никогда не пользовались iD, то попробуйте, и вы заметите, что у вас тоже получатся случайно перетащенные точки. Ну а редактор iD на сайте openstreetmap.org предлагается тем, кто не пользовался до него вообще ничем, и кто перетаскивания не заметит.

Про iD можно было бы продолжать, и да, от каждой отдельной правки из этого редактора проблем может быть больше, чем от правки из maps.me, но пора перейти к рассмотрению последнего.

Особенности редактирования из maps.me

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

Создание дубликатов уже существующих точек

Бывает, что пользователь maps.me добавляет POI рядом с такой же точкой, уже существующей в данных osm. Как он мог её не заметить? На это есть две основные причины. Первая причина: у пользователя может не быть данных о недавно добавленных точках. При условии, что пользователь регулярно обновляет приложение, данные у него будут обновляться раз в месяц, но сами данные идут с задержкой. В результате имеющиеся у пользователя данные являются устаревшими в среднем примерно на месяц. Для сравнения у osmand данные обновляются раз в месяц практически без задержки, что даёт устаревание в среднем на пару недель. Ещё в случае с osmand нет необходимости обновлять само приложение для получения новых данных, что может положительно влиять на готовность пользователя выполнять обновления. Правда у maps.me, по идее, сам объём передаваемых данных должен быть меньше, потому что они шлют диффы.

В осме есть места, не редактирующиеся годами, для которых месячный возраст данных не будет иметь значения, но есть и активно редактирующиеся места. Если открылся новый магазин в заметном месте, то существует высокая вероятность того, что он будет отмечен несколькими пользователями. Одним из этих пользователей может быть представитель данного магазина. Иногда и оба пользователя могут быть представителями. Мне известен подобный случай, когда точка была добавлена через iD. Это, конечно же, не привело к её немедленному появлению в maps.me, которого, возможно, пришлось бы ждать полтора месяца, и точка была добавлена ещё и через maps.me. Так что если вы создаёте только что открывшийся магазин, вам может понадобиться следить за отредактированным местом, чтобы отлавливать дубли. Лично у меня случалось, что в добавок ко своей точке, я получал ещё две в течении нескольких дней. Одна из них в данном случае была создана из osmand, видимо, по подобным причинам.

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

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

Вторая причина незнания о существовании точки: у пользователя данные о существующей точке могут быть загружены, но он всё равно её не увидит, так как точка может просто не рендериться. Maps.me рендерит только то, что помещается целиком. Для POI это и иконка и подпись к ней, состоящая, обычно, из названия. Слишком большая подпись и другие точки рядом могут привести к тому, что данная POI видна не будет. Другими точками могут быть и данные не из осма, а например, из букинга – серьёзная проблема в центре Санкт-Петербурга – или ещё какая-нибудь реклама, какой были, например «артефакты» из некого фильма. Рендеринг рекламных точек является для maps.me приоритетным, а всяких апартаментов, зарегистрированных в букинге, в центре предостаточно, так что интересующая пользователя точка иногда может всплыть только в результате поиска. Если пользователь решит, что существующей в данных точки нет, и попытается её добавить, то у точки появляется второй шанс быть обнаруженной. В режиме добавления maps.me пытается рендерить всё, что есть, даже если оно накладывается друг на друга. Данные из букинга при этом не пропадают, и при достаточной плотности точек будет ничего не разобрать, так что шанс может быть упущен.

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

Создание заметок про отсутствие уже удалённых или заменённых точек

Встречаются заметки с просьбой удалить или просто с утверждением об отсустсвии того, чего рядом с этими заметками не обнаружить. Они могли быть поставлены на объект, существовавший в данных пользователя по первой причине создания дубликатов. Можно обратить внимание на то, что maps.me добавляет к тексту заметки, если он был введён пользователем, название точки, послужившей поводом к созданию заметки, её тип и дату-версию данных у пользователя. При этом пользователь не знает, что он создаёт именно заметку. Для пользователя эта операция может выглядеть как собственно удаление, так как она влияет на отображение точки. Кстати, отменить создание заметки-удаления невозможно, даже если пакет правок ещё не отправлен, в отличие, например, от создания новых точек. Ну и конечно же ни про какие пакеты правок и про то когда именно происходит загрузка данных, пользователь понятия не имеет. В датах-версиях можно заметить, что некоторые пользователи не обновляют свои данные год и больше. Имя и тип точки старые версии maps.me не писали, и заметки, относящиеся непонятно к чему со стандартным текстом «amenity doesn't exist» всё еще могут существовать.

Создание заметки при создании точки, при том, что в заметке не содержится никакой информации, которой бы уже не было в точке

Зачем может понадобиться делать заметку, по которой ничего сделать нельзя, да и не нужно? Но пользователи maps.me просто не знают о том, что они создают заметку. У них в интерфейсе добавления точки внизу есть поле, где раньше предлагалось ввести дополнительную информацию – из неё и создавалась заметка. Сейчас, кстати, там написано «Отправить сообщение модератору OSM», хотя никаких модераторов базы данных в осме нет.

Проблема, казалось бы, невелика. Мы просто закроем заметку и всё. Но выясняется, что некоторые решают эту заметку отработать, то есть создать запрашиваемую точку. Кто же будет создавать точку, если она уже создана, не считая, конечно, пользователей maps.me? Но maps.me – не единственный редактор, позволяющий работать с устаревшими данными, и ещё один из подобных редакторов выше уже был упомянут. Но ведь, чтобы создать дубль в этом случае, надо иметь свежие данные по заметкам и старые по точкам, а такого не может быть? Выясняется, что может. В принципе вы даже из josm можете редактировать старые данные, например детально отрисовывая какое-то место так, что промежуточный результат выкладывать не имеет смысла, но заметки решили загрузить свежие, но это вряд ли. А вот из osmand создание дублей по подобным заметкам я видел. Если вы видите заметку, поставленную из maps.me, не забудьте обновить у себя данные под ней.

Задание несоответствующих друг другу тегов на одной точке

Иногда это явление происходит в очевидно бессмысленном виде: компьютерный магазин «Столовая». Можно догадаться, что на этом месте раньше был магазин, а потом открылась столовая. Пользователь поменял name, но почему он не поменял amenity/shop? Потому что редактор этого сделать не даёт. Бывают и менее очевидные случаи, например, когда ресторан помечен как ночной клуб. Ведь вполне возможно, что на самом деле это также ночной клуб. Но нет – это пользователь maps.me обновил name у точки на месте бывшего клуба.

Помимо типа точки, который пользователь видит, но не может поменять, есть и такие теги, которые пользователь даже и не видит. Это все теги, которые не вписались в шаблон для редактирования, то есть большинство использующихся тегов. Их пользователь обновлять не будет. Не прочитает он и заметки для редактирующего в note. Все редакторы можно поделить на те, которые не скрывают теги, на те, которые сначала скрывают, но могут показать, и на те, которые не могут. josm относится к первым, iD – ко вторым («все теги» обычно свёрнуто), maps.me к последним. Последние проще для неподготовленного пользователя при добавлении новых данных, зато совсем не годятся для редактирования существующих. Можно подумать, что никаких проблем быть не может, если надо всего лишь поменять значение website или opening_hours. Но представьте себе, что на точке также стоит fixme, в котором сказано, что текущее значение неправильное. После редактирования без учёта fixme, неправильным становится уже сам fixme.

Ещё бывает, когда в одном из языковых вариантов name написано одно, а в другом (или в основном name) другое. Основной name в интерфейсе запрятан подальше, так что обычный пользователь его не найдёт. Если понадобится поменять название, то будут отредактированы какие-то языковые варианты, возможно не все. Какие именно поля для языковых вариантов будут показаны пользователю – зависит от географического положения точки и системного языка. Иногда они заполнены значением, иногда пустые, точно не знаю, по какому принципу. Строго говоря, я не знаю, как в текущей версии maps.me обстоит дело с редактированием названий (например, должен ли я стереть автозаполненное название, если считаю его неправильным), потому что не хочу ставить эксперименты, чтобы определить что именно куда запишется. Знают ли это обычные пользователи maps.me, думаю, понятно.

Что вам надо делать в подобных случаях, а лучше – всегда при редактировании существующих точек: смотреть историю. Если в истории редактирования точки есть правка из maps.me, особенно если в этой правке меняется name, то это является основанием для того, чтобы не доверять остальным тегам. Придётся их либо перепроверять, либо удалять.

Создание новых точек вместо редактирования существующих либо без удаления старых

Собственно удалять из maps.me нельзя. Но и редактировать уже существующие точки, как было сказано выше, тоже нередко нельзя. Получается, что типичное явление, когда закрывается один магазин, и на его месте открывается другой, ввести из maps.me нельзя. Но это не значит, что пользователи не будут пытаться, с соответствующим результатом. Конечно, нередко пользователь не знает, что новый магазин появился вместо, а не дополнительно к старому. В этом случае добавление новой точки и ничегонеделание со старой будет ошибкой самого пользователя без какой-ли помощи со стороны maps.me, если только maps.me старую точку не скрыл, см. вторую причину дубликатов. Но что пользователь мог бы сделать со старой? Ну, например, поставить на неё заметку, о том что её нет. На самом деле ему бы следовало этой заметкой и ограничиться, а про новую точку написать в комментарии, но до всего этого надо догадаться, а пользователь не знает даже о существовании заметок и о различии записи в node и в note.

Создание точек с неподходящим типом

Бывает, что в городе вдруг появляются водопады и прочие объекты, которых не может там быть. Это пользователь maps.me захотел обозначить что-то, для чего доступного для выбора типа в maps.me не нашлось. Список доступных типов ограничен, а один из них выбрать обязательно нужно. Можно было бы догадаться поставить заметку, но на пустом месте это сделать не получится, так что, если заметка и появится, то только вместе с водопадом. Скорее всего, однако, заметка не появится, и вам придётся либо угадывать, что имел в виду пользователь, либо откатывать.

Спам

К сожалению, спам не ограничивается известным случаем с тегом banner_url. Рассмотрим историю редактирования одного уже удалённого здания. Как видно, в версии #10 помимо этажности я задал название и сайт. Как мне это удалось, если maps.me не даёт редактировать названия у зданий? Конечно же я ничего, кроме этажности править не собирался, но у maps.me свои соображения на этот счёт. Есть агентство недвижимости на букву Ц, рекламу которого можно увидеть в приложении в общем и на некоторых зданиях в отдельности, во всяком случае в Санкт-Петербурге. Редактирование этих зданий может привести к попаданию в правку рекламы Ц. Если вы видите подозрительные name и website на здании, то надо опять же проверить историю редактирования на предмет наличия в ней правок из maps.me. Если они есть, то возможно следует их откатить.

Ввод данных с точностью плюс-минус дом

Пользователи maps.me ставят точки мимо нужного здания несколько чаще, чем пользователи других редакторов. Объясняется тем, что им приходится рассчитывать на gps, находясь рядом со зданиями, отсутствием спутника/аэрофотосъёмки в качестве подложки и невозможность подвинуть свои точки после добавления. Например, один пользователь, входящий в топ-10 редактирующих из maps.me, идёт вдоль улицы и вносит все POI подряд, не зная, что вместо дома n их надо было ставить в n+2, вместо n+2 – в n+4 и т.д. Дойдя до конца квартала, он, конечно, поймёт, что ошибся, но исправить ошибку уже не сможет. Это не очень хороший повод для доверия к точности координат точек менее топовых пользователей. Мимо точки ставят и без maps.me, да и магазины, бывает, в действительности перемещаются в соседний дом, но если вы видите точку не на том здании, на каком считаете, что она должна быть, её создание правкой из maps.me – аргумент в вашу пользу. Ну и некоторые вообще в здание попасть не могут, и ставят на проезжую часть. Может быть они ожидают, что в интерфейсе добавления в нужное место надо ткнуть, а не тащить его под «прицел».

Нелогичное объединение правок в пакеты

Пакеты правок, создаваемые пользователями maps.me могут быть как «атомарными», содержащими одну точку, так и «планетарного масштаба», с правками в разных частях света. И зачем пользователи так разбивают свои правки на пакеты? А они их и не разбивают, это за них делает приложение. Правки с одной точкой будут у тех, у кого с интернетом всё в порядке, «планетарные» будут у туристов, экономящих мобильный трафик. Я видел пакет, в котором помимо создания дублей в СПб, было создание дублей во Франции (и коллегам оттуда приходилось делать suppression d'un restaurant en doublon) и, может быть, не-дублей на Шри-Ланке. Пакеты могут быть и пустыми – это если соединение оборвётся.

Прочее

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

Насколько это плохо и что с этим делать

Вкратце можно сказать, что в хорошо отмапленных местах от всего этого вреда не так много, но и пользы от правок maps.me гораздо меньше, чем хотелось бы разработчикам. Я даже скажу, что если бы в Адмиралтейском районе СПб пользователи maps.me не сделали ни одной правки, то вы бы разницы не заметили. Ну, допустим, некоторые точки появились бы попозже. В Центральном районе, может быть, эффект от maps.me побольше. Так что выпиливать все правки maps.me в этих местах не нужно. А вот как обстоят дела в местах, где доля правок из maps.me выше, было бы интересно узнать. Более подробные рассуждения на эту тему придётся оставить на потом, так как эта запись получилась слишком длинная.

"Mapping Well With Mapsme"

Posted by Anton Khorev on 1 October 2017 in Russian (Русский)

После прочтения этого топика на форуме возникает желание прокомментировать упомянутый там доклад Mapping Well With Mapsme.

"Вместо того, чтобы собственно редактировать данные, можно добавлять метки"

Чего не было сказано: метку может не получиться поставить в нужное место, особенно если оно занято площадным объектом - это может проявляться по-разному в зависимости от зума. Можно попробовать ставить метку на фиктивный объект, для чего сначала надо добавить любую точку, затем поставить на неё метку, затем удалить точку. Удалить точку можно только если она не отправлена, см. ниже.

Подобным образом ставить метки вряд ли удобно и делать это надо осторожно. Я попробовал для примера создать фиктивную точку, но тут проявилась такая особенность maps.me - показывать последнее известное местонахождение, даже когда об этом никто не просит. В итоге вид съехал ко входу в метро, перед которым я выключил gps, а я не помнил, куда я поставил точку. Хорошие новости: даже добавленные пользователем точки попадают в результаты поиска.

"При добавлении места выдаётся длинный список типов, но мы типа об этом подумали и у нас есть поиск"

Это всё равно неудобно, если надо многократно добавлять однотипные объекты, ведь если пользоваться для этого поиском, то выполнять поиск придётся перед вводом каждого объекта. В vespucci есть такое решение - часто используемые заготовки становятся быстродоступными. В maps.me же есть только один список, который не меняется - если только не переключить язык ввода для поиска. Этим переключением приходится пользоваться: например, вы хотите отметить несколько скамеек, но "скамейка" по-русски ближе к концу списка, который надо долго прокручивать. Можно, конечно, отметить одну скамейку, а дальше оставить заметку о том, что их на самом деле несколько, а можно догадаться переключиться на английский. "Bench" скорее всего будет доступна вообще без необходимости прокрутки списка.

"Maps.me отсылает данные, когда приложение закрывается"

К этому ещё надо добавить, что maps.me не показывает, есть ли неотосланные данные и сколько их, и занимается самостоятельным сочинением комментариев к пакетам правок. Но отослать данные maps.me не сможет, если нет доступа к интернету. Этим можно пользоваться, специально перекрывая доступ в интернет, и разрешая его только тогда, когда мы готовы проконтролировать результат, например с помощью нормального редактора. Пока пакет не отправлен, вместо кнопки "места не существует", будет кнопка "удалить", позволяющая собственно удалить объект, а не подвешивать на него заметку.

Если нужно включить интернет, а только для maps.me его не перекрыть, то перед включением интернета можно для гарантии прибить maps.me через диспетчер приложений. А если ещё и на карту смотреть хочется, то у вас наверняка установлен osmand. Ещё надо проверить вариант помехи отправки данных посредством разлогинивания.

Обратной стороной всего этого является то, что если какой-нибудь турист будет пользоваться maps.me по назначению, т.е. как оффлайновыми картами, он запросто может создать пакет (никак не связанных) правок в разных точках планеты, когда, наконец, вернётся домой к своему интернету.

"Обычное имя, которое без языка, защищается, чтобы его не грохнули туристы"

Сам рассказ про редактирование названий сопровождается скриншотом, где поле "English" заполнено по-японски - maps.me имеет обыкновение самостоятельно его заполнять. Докладчика это не смущает, хотя для пользователя наверняка важно, запишется это всё в name:en или нет. Когда я подобное заполнение поля "English" русским названием удалял, в результате не создавалось и name:ru. Я до сих пор не уверен, что именно произойдёт при редактировании имени, и логика там, похоже, менялась в недавних версиях.

Защиту "настоящего" name можно охарактеризовать и по-другому: не даём пользователю ожидаемого способа полностью переименовать точку. В результате этого в разных name будут разные названия. Тогда зачем вообще давать редактировать название, ведь можно было бы давать только добавлять новые языковые варианты. Например, можно было бы показать "настоящее" нередактируемое название, а рядом поставить кнопочку "добавить перевод". У некоторых объектов название менять и не дают, например у зданий и, следовательно, у poi, совпадающих со зданиями. В этом случае под редактирование подставляется номер дома, хорошо, что там валидатор.

"Если попытаться создать точку очень близко к другой точке, то вместо этого будет выполнено редактирование"

Допустим, у точки был задан вебсайт. Я создаю поверх неё новую точку, у которой сайт не указываю. В результате в осмовских данных сайт останется старый, а в видимых мне мапсмешных данных сайта не будет. При этом сайт - один из видимых в maps.me тегов, а есть ещё и невидимые. В итоге получится точка со смесью старых и новых тегов. Или получится вторая точка, если я промахнулся - ведь я её поставил с помощью сенсорного экрана мобильного телефона - но об этом имеет смысл рассуждать, если я знаю про возможность редактирования посредством простановки новой точки поверх. Большинство пользователей скорее всего об этом не знают и не собираются ничего редактировать при добавлении новой точки.

Так отредактировать, не зная того, что это именно редактирование, можно даже невидимую из maps.me точку. В докладе утверждается, что это редко происходит, но происходит. И зачем оно происходит? Тут можно подумать, что это защита от всем известных мапсмешных дублей, но если бы эта защита работала, то дубли не были бы всем известны. Работать она так не сможет, потому что никто не мапит с сантиметровой точностью, и дубль спокойно разместится метрах в трёх от своего предшественника.

"Если вы при добавлении точки не можете найти для неё правильный тип, то поставьте неправильный и напишите заметку, а правильный поставьте потом"

Здесь докладчик даёт вредный совет. Не удивляйтесь, если подобные действия будут считать вандализмом. Поскольку правильный тип из maps.me вы и позже не поставите, это тот случай, где на вопрос "как правильно редактировать из maps.me" ответом является "никак". То есть из maps.me придётся либо редактировать неправильно, желательно задерживая загрузку данных способом, описанным выше, либо не редактировать, а ставить метку, с возможными проблемами, описанными ещё выше.