Users' diaries

Recent diary entries

Route Planning with OSM

Posted by bufferclip on 4 February 2018 in English (English)

I wrote an overview about route planning with OSM:

example route

Ashgabat's western suburbs

Posted by apm-wa on 4 February 2018 in English (English)

Ann and I celebrated my completion (more or less) of drawing the boundaries of Ashgabat's four boroughs (etraplar) with a Sunday drive to some of the villages across the border in Ahal welayat (province) to the west. We collected a few POIs and street names, and did some ground truth. The battery died on our Samsung Galaxy we use for collecting Mapillary imagery and the backup battery was also not fully charged...sorry about that (note to self: remember to recharge ALL batteries the night before).

Location: Köpetdag, Nowata, Ahal, Turkmenistan

Доклады про OpenStreetMap на FOSDEM 2018

Posted by Sadless74 on 4 February 2018 in Russian (Русский)

На FOSDEM 2018 начинаются доклады в секции GeoSpartial про OpenStreetMap. Смотреть можно на сайте Смотреть или слушать в любимом плеере

А Илья будет в 17:00 по MSK

Представьте что вы на европейской конференции :)

ЕженедельникОСМ 393

Posted by Sadless74 on 3 February 2018 in Russian (Русский)

ЕженедельникОСМ 393 (23.01.2018-29.01.2018)


Posted by Ali Mohamud on 3 February 2018 in English (English)


Location: Stubenviertel, KG Innere Stadt, Innere Stadt, Vienna, 1010, Austria


Posted by vyacheslavdimov on 3 February 2018 in Russian (Русский)

село на казанском тракте

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

Open Mapping in Manila, for Open Data Day 2018

Posted by GOwin on 2 February 2018 in English (English)

The Free Software and Open Data advocates of Manila is going to celebrate international Open Data Day 2018 on March 3, Saturday with an afternoon of Open Mapping workshops in San Juan Campus of the Polytechnic University of the Philppines, in Metro Manila.

The event is open to everyone, with parallel activities available, depending on your experience and interest:

  • [Workshop] Introduction to Open Mapping with OpenStreetMap
  • [Workshop] Intermediate+ Mapping on JOSM
  • [Unconference] Open (geo)Data for Disaster Preparedness and Resiliency.

In the beginner's workshop, a computer laboratory will be available for your use. Limited seats are available.

In the intermediate workshop, participants are required to bring their own laptops, with JOSM already installed. This workshop is intended for participants with some JOSM experience.

No computers are necessary for the unconference. Just bring some enthusiasm, and an open mind.

Registration is free. Just head over here to get your free ticket:

Refreshments and swags are to be given away, for registered participants.

Location: Alvir Compound, Little Baguio, Isabelita, District 2, San Juan, Metro Manila, 1500, Philippines

Releasing Turn Restriction Detections

Posted by daniel-j-h on 1 February 2018 in English (English)

We are releasing 10.4k turn restriction detections located across 5.2k intersections for the OpenStreetMap community.


Raw GeoJSON data

These turn restriction detections were sourced by applying our machine learning computer vision models to Bing Streetside imagery. Mapbox has acquired the right to contribute these detections to OSM.

“Detections” are not really the same thing as turn restrictions. Rather, they are suspected, but unverified turn restrictions. We are planning to manually verify these turn restrictions, and our data team is working through the list, but the first pass produced thousands of candidates, so verification will take a while. We do think these can be useful to the OSM community, who may wish to move faster on improving OSM based on these detections.

To be clear, the Streetside imagery is not available for direct editing by the community at large. However, subject to its terms and conditions, it can be used for personal reference for examining the source of the detections, so we have included URLs to the image associated with each detection.

Examples from the Streetside Imagery API:

antigua data on a garmin gpsmap64s

Posted by Lee De Cola on 1 February 2018 in English (English)

downloaded osm data to use while driving on/sailing about the island. simply a lifesaver while driving in an area with many narrow, potholed, unmarked roads!

2 problems:

*the map display was generally dark, monochrome, and difficult to read while bouncing around.

*it seemed like where ever i wanted to go that took me from north to south i was often routed thru St Johns, the capital, with narrow hard-to-navigate streets - any idea why?

thanks for a great service!

Location: Reston Town Center, Reston, Fairfax County, Virginia, 20194, United States of America

Не работает

Posted by Kapkan95 on 1 February 2018 in Russian (Русский)

В том году навигатор работал без интернета теперь он не работает без интернета и даже с ним он с трудом находит место где я нахожусь

ЕженедельникОСМ 392

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

ЕженедельникОСМ 392 (16.01.2018-22.01.2018)

OpenStreetMap Carto release v4.7.1

Posted by kocio on 31 January 2018 in English (English)

Dear all,

Today, v4.7.1 of the openstreetmap-carto stylesheet (the defaultstylesheet on the OSM website) has been released. Once changes are deployed on the it will take couple of days before all tiles show the new rendering.

This is a bugfix release, the only change is a code fixing this rendering problem:

Thanks to all the contributors for this release.

For a full list of commits, see

As always, we welcome any bug reports at

nombre de calles

Posted by karen corvalan on 31 January 2018 in Spanish (Español)

como puedo ver el nombre de todas las calles ,ya que según la escala me muestra cierta cantidad de nombres y necesito verlo todos.

Relazioni autobus urbani AMT e altri dettagli

Posted by Ale_Zena_IT on 31 January 2018 in Italian (Italiano)

Ci siamo quasi! Ad oggi in OSM sono presenti 328 relazioni delle linee AMT. Ogni linea ha il percorso d'andata e quello di ritorno. Molte, ma non ancora tutte, hanno anche le linee barrate. Qui un link a una query overpass che mostra il risultato.

Per ogni linea è stata creata una relazione route_master nella quale stanno tutti i percorsi di quella linea. Entro una quindicina di giorni vorremmo completare il lavoro. Se qualcuno si vuole unire è ovviamente il benvenuto. Stiamo preparando anche una tabella da inserire sulla pagina wiki di Genova per rintracciare al volo le relazioni di tutte le linee.

Nello stesso periodo stiamo cercando di mappare in dettaglio le stazioni FS di Brignole e Principe.

Happy mapping e spero di incontrare molti di voi a Roma in occasione di FOSS4G-IT o a marzo a Torino per Merge-it.

Happy mapping

Location: Sant'Andrea, Centro Est, Genova, GE, LIG, 16123, Italia


Posted by neha tyagi on 31 January 2018 in English (English)

nothing to write will soon update it для тех, кто не пользуется

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

Mapeamento da cidade de Piripiri - PI

Posted by FrancyskoMarkes on 30 January 2018 in Brazilian Portuguese (Português do Brasil)

Ontem concluí a adição de nomes de rua na cidade de Piripiri que fica no Estado do Piauí. Foi um grande trabalho, mas concluí com gosto e determinação, utilizando o editor JOSM o qual estou me acostumando a utilizar. Vejo que muitas cidades do desse Estado não estão com os nomes das ruas adicionados, até mesmo as cidades que já são um pouco grandes. Mas continuarei dando a minha contribuição. Abraços!

Beaudesert Mapping Party Coming Soon (10th Feb!)

Posted by David Dean on 30 January 2018 in English (English)

Hi mapper, welcome to (almost) February,

February's Mapping Party for Brisbane will be a little bit out of town this time: Beaudesert, but I hope I can encourage a good turnout.

The mapping party will be on Saturday 10th Feb, and we will be meeting in the morning for coffee, then surveying, and enjoying a free lunch in the Scenic Rim Council building while we help each other with our iDing and JOSMing, etc.

If you are a bit daunted by the trip from Brisbane to Beaudesert [1], I'd be happy to give you a lift there and back, so let me know. I'm happy to grab you from basically anywhere in Brisbane.

More details on the event are at and please use that link to RSVP so we can plan appropriate amounts of food.

If you can't make it to Beaudesert, please turn up for the monthly Geospatial Network in Brisbane City on Wed 7 Feb ( and keep representing OSM to the local GIS community (I won't be able to be there myself, unfortunately though).

  • David

[1] About an hour:

Location: Helen Street, Beaudesert, Queensland, 4285, Australia

Data Classification with Human Cognition

Posted by grass_and_green on 30 January 2018 in English (English)

Dear Folks,

The study that investigates how human categorize geographic objects in VGI project generally and OSM particularly still need your support

Vist and participate here

Look for results of pilot study, have impression on how objects are recognized differently

Thanks in advance,

Dr. Ahmed Loai Ali

contact me

Add some style - getting the style you need

Posted by pnorman on 30 January 2018 in English (English)

This is a repost of an entry on my blog.

Last post ended with downloading OpenStreetMap data. This post will leave the data aside and switch to downloading and building a style. There's lots of styles available, but we're going to use OpenStreetMap Carto, the current default on Also, because we need software not packaged in Debian, that needs to be installed.

For the script, we're going to assume that the carto binary is in the PATH. Unfortunately, this requires installation, which requires npm, which itself needs to be installed.

Given nodejs and npm is a huge headache of versions, the easiest route I've found is to install nvm, then install nodejs 6 with nvm install 6. CartoCSS is then installed with npm install -g carto.

The shell script starts off with some variables from last time.

#!/usr/bin/env bash

set -euf -o pipefail

OpenStreetMap Carto is hosted on Github, which offers the ability to download a project as a zip file. This is the logical way to get it, but isn't usable from a script because the internal structure of the zip file isn't easily predicted. Instead, we'll clone it with git, only getting the specific revision needed.

rm -rf -- 'openstreetmap-carto'
git -c advice.detachedHead=false clone --quiet --depth 1 \
  --branch "${OSMCARTO_VERSION}" -- "${OSMCARTO_LOCATION}" 'openstreetmap-carto'

Setting advice.detachedHead=false for this command avoids a warning about a detached HEAD, which is expected.

OpenStreetMap Carto sets the database name to be "gis". There are various ways to override this for development, but in this case we want to override it for the generated XML file. Fortunately, the database name only appears once, as dbname: "gis" in project.mml. One way to override it would be to remove the line and rely on the libpq environment variables like PGDATABASE. Another is replacing "gis" with a different name. It's not clear which is better, but I decided to go with replacing the name, using a patch which git applies.

export PGDATABASE='osmcarto_prerender'

git -C 'openstreetmap-carto' apply << EOF
diff --git a/project.mml b/project.mml
index b8c3217..a41e550 100644
--- a/project.mml
+++ b/project.mml
@@ -30,7 +30,7 @@ _parts:
     srs: "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs"
   osm2pgsql: &osm2pgsql
     type: "postgis"
-    dbname: "gis"
+    dbname: "${PGDATABASE}"
     key_field: ""
     geometry_field: "way"
     extent: "-20037508,-20037508,20037508,20037508"

With project.mml patched, it's easy to generate the Mapnik XML, because CartoCSS was installed earlier.

carto -a 3.0.12 'openstreetmap-carto/project.mml' > 'openstreetmap-carto/project.xml'

Lastly, OpenStreetMap Carto needs some data files like coastlines. It comes with a script to download them, so we run it.


Taking all of this and re-arranging it as, we end up with the following script.

#!/usr/bin/env bash

set -euf -o pipefail


rm -rf -- 'openstreetmap-carto'
git -c advice.detachedHead=false clone --quiet --depth 1 \
  --branch "${OSMCARTO_VERSION}" -- "${OSMCARTO_LOCATION}" 'openstreetmap-carto'
carto -a 3.0.12 'openstreetmap-carto/project.mml' > 'openstreetmap-carto/project.xml'