OpenStreetMap Blogs

12.09.2017-18.09.2017

Mapping

• [1] Benutzer Cascafico hat eine eigene Instanz des OSM Analytic Tracker für Nordost-Italien auf einem Orange-PI-Minicomputer aufgesetzt. Dabei handelt es sich um einen Änderungssatzbeobachter mit eigener grafischer Visualisierung der Änderungssätze (Beispiel).
• Tom Pfeifer stößt auf der Mailingliste Tagging eine Diskussion darüber an, ob Verweise auf Bewertungsportale für in OSM befindliche POIs erfasst werden sollten.
• Telenav eckt (automatische Übersetzung) mal wieder bei der kanadischen Community an.
• User GOwin berichtet über „HailHydra(nt)!”, eine Initiative, die er in Zusammenarbeit mit den örtlichen Feuerwehrleuten in der Region Davao (Philippinen) gestartet hat. Ziel ist die Kartierung von Hydranten, Feuerwehrstationen und Freiwilligen Feuerwehren. Die während des Mapathons verwendeten Werkzeuge waren OSMHydrant und OsmAnd.
• Giacomo Servadei hat im Rahmen des GSoC das PT_Assistant-Plugin für JOSM weiterentwickelt. Das Plugin erleichtert die Arbeit mit den ÖPNV-Routenrelationen durch visuelles Feedback, Validierung und einige neue Tools, es meldet Kontinuitätsprobleme und fügt bei richtungsabhängiger Routenführung forward/backward hinzu.
• Benutzer praktikyadav von Mapbox berichtet in seinem Benutzer-Blog, dass es beim Mapbox-Satellitenbildlayer einige Aktualisierungen gibt.
• Das Proposal Language Information (wir berichteten) ist abgelehnt worden.
• Simon Poole berichtet in seinem Benutzer-Blog, dass er den Name Suggestion Index, eine Sammlung an gebräuchlichen POI-Namen und deren empfohlenes Tagging, aktualisiert habe. Dieser dient einigen Editoren, u.a. iD, als Quelle für Taggingvorschläge.
• Bei den Orthophotos des Regionalverbands Ruhr gibt es Aktualisierungen.

Community

• Marena Brinkhurst hat sich einige Schlagzeilen für 2020 überlegt und getwittert. Hoffen wir, dass wir auch noch hinzufügen können: „Die Daten sind korrekt und die Karten von hoher Qualität“.
• Irland macht sich auch auf den Weg, ein Local Chapter zu bilden.
• Yuri Astrakhan startet die Namenssuche für seinen Wikidata+OSM SPARQL query service, der jetzt auch in JOSM verfügbar ist.
• Jo sucht Studenten mit Kenntnissen in Java und dem Datenmodell von OSM. Interesse an Routen-Relationen wäre von Vorteil.
• Der belgische OSM-Blog kürt Jonathan Beliën zum Mapper des Monats.
• Steffen Voß, der selber früher mal Mapper war, weist in seinem Blog auf die App StreetComplete hin.

Importe

• Das kanadische Statistikamt (StatCan) hat einen Mapping-Workshop veranstaltet. Dort wurde das Ziel festgelegt, bis 2020 jedes kanadische Gebäude in OSM zu kartieren.
• Vincent Frison plant Gebäudehöhen in Nizza nach dem gleichen Verfahren zu importieren, das er vor 2 Jahren für Paris benutzte. Er bittet um Feedback auf der Mailingliste Talk-fr und im französischen Forum.

OpenStreetMap Foundation

• Auf der Mailingliste Talk hat die Diskussion um den Entwurf einer Richtlinie zur Verwendung der Marke „OpenStreetMap“ („Trademark Policy“) wieder begonnen (wir berichteten). Die Richtlinie betrifft u.a. diejenigen, deren Projekte namentlich an „OpenStreetMap“ oder „OSM“ angelehnt sind.

Veranstaltungen

• Das Programm der State of the Map US in Boulder, Colorado (20. bis 22. Oktober) wurde veröffentlicht.
• Der FOSSGIS e.V. lädt zum neunten Hacking Event vom 8. bis 10. Dezember ins Linuxhotel in Essen ein. Die Anmeldung erfolgt über das FOSSGIS-Wiki.
• Am 23. und 24. September findet in Kathmandu (Nepal) die State of the Map Asia statt.

Humanitarian OSM

• Daniel Mietchen hat detaillierte Notizen inklusive Lob und Kritik niedergeschrieben, während er MapSwipe ausprobiert hat. Zudem gibt es noch eine Konversation auf Twitter zwischen ihm und dem offiziellen HOT-Twitter-Konto.
• In Mexiko werden immer noch Mapper und Überprüfer benötigt. Aus aktuellem Anlass: Neues Erdbeben, neue Aufgabe.
• Martin Noblecourt erinnert daran, dass Satellitenbilder nicht zwangsläufig lagerichtig sind, und zeigt auf, wie man das Problem angehen kann.
• Über die OpenAerialMap sind Satellitenaufnahmen von DigitalGlobe nach den Hurrikans Harvey und Irma zum Digitalisieren verfügbar.

Karten

• kocio-pl schlägt in einem Pull Request vor, boundary=protected_area in OSM Carto aufzunehmen.
• math1985 möchte Ackerflächen in OSM Carto wieder dunkler machen und hat dazu ein Pull Request erstellt.

switch2OSM

• Pierre Béland (aka Pierzen) berichtet auf der Mailingliste talk-ca, dass „Canadian Press”, eine kanadische Presseagentur, OpenStreetMap-Karten über die MapBox-Dienste veröffentlicht. Diese Karten erscheinen in kanadischen Zeitungen, die „Canadian Press” abonniert haben.

Open-Data

• Die Provinzverwaltung von Neubraunschweig (Kanada) hat ihre Luftbilder an ESRI gespendet.

Programme

• Nicolas Guillaumin, der bisherige Entwickler von OSMTracker für Android, sucht einen neuen Maintainer und wäre bereit, das Github-Projekt zur OpenStreetMap-Organisation auf Github zu übertragen.
• StephaneP beschreibt in einem Blogbeitrag die Verwendung von kostengünstigen GPS RTK mit der Open-Source Software RTKLIB, um eine RTK Basisstation zu betreiben und durch Korrektur des Satellitensignals eine Genauigkeit von wenigen Zentimetern zu erreichen. Im Blog gibt es – wie immer – die Möglichkeit zu Fragen und zur Diskussion mit dem Autor.

Programmierung

• Das OpenRouteService-Backend findet sich jetzt unter der Apache-Lizenz auf Github. Da es sich um einen Graphhopper-Fork handelt, wurde der ORS irgendwann in den letzten Jahren von einer eigenen Implementierung auf eine Graphhopper-Basis umgestellt.
• Bogdan Afonins hat während des Google Summer of Code zahlreiche Verbesserungen für JOSMs Such- und Download-Dialog entwickelt.

Releases

• OSM Carto 4.3.0 enthält größtenteils Bugfixes.

Kennst du schon …

• … Reisezeit-Karten? Peter Liu von Mapbox denkt darüber nach.
• … den Fotowettbewerb Wiki Loves Monuments? Vielleicht hast du beim Datensammeln Bilder aufgenommen, die dort interessant sind.
• … die Liste der Mitglieder des Advisory Boards der OSMF?

OSM in der Presse

• Die New York Times veröffentlicht einen Artikel über humanitäre Bedürfnisse nach Hurrikan Irma. Die Karten zeigen Informationen, die auf OSM basieren.
• Die Zeitschrift We Demain berichtet darüber, dass die französische Organisation „Hackers Against Natural Disasters (Hand)” Geräte im Wert von 30.000 € in die von Irma betroffenen Gebiete Saint-Martin und Saint-Barthélémy geschickt hat. Unter anderem wurden Drohnen zur Kartierung geliefert. (automatische Übersetzung)

Weitere Themen mit Geo-Bezug

• OSM wird auch immer wieder gern bei geografisch relevanten Inhalten zur Visualisierung genutzt: hier das Projekt Makroplastik der Universität Oldenburg.
• Mercedes-Benz ist What3words auf den Leim gegangen und nutzt die Datenbank der proprietären Geocoding-Methode in seinen Navigationssystemen. Diese Daten stehen unter einer restriktiven Lizenz und dürfen nicht nach OSM übertragen werden!
• Der Bayerische Rundfunk berichtet über die teils fragwürdigen Bearbeitungen der Wikipedia-Artikel von Bundestagsabgeordneten durch anonyme Benutzer aus dem IP-Netz des Deutschen Bundestags.

Wochenvorschau

Wo	Was	Wann	Land
Bremen	Bremer Mappertreffen	2017-09-25
Graz	Stammtisch Graz	2017-09-25
Berlin	111.1 Berlin-Brandenburg Sonderstammtisch Intergeo	2017-09-25
Berlin	Intergeo 2017	2017-09-26-2017-09-28
Lübeck	Lübecker Stammtisch	2017-09-28
Essen	Mappertreffen Essen	2017-10-04
Stuttgart	Stuttgarter Stammtisch	2017-10-04
Dresden	Stammtisch Dresden	2017-10-05
Dortmund	Mappertreffen Dortmund	2017-10-08
Bonn	FOSSGIS 2018	2018-03-21-2018-03-24

Hinweis:
Wer seinen Termin hier in der Liste sehen möchte, trage ihn in den Kalender ein. Nur Termine, die dort stehen, werden in die Wochennotiz übernommen. Bitte prüfe die Veranstaltung in unserem öffentlichen Kalendertool und korrigiere bitte die Einträge im Kalender, wenn notwendig.

Diese Wochennotiz wurde erstellt von Nakaner, Peda, PierZen, Spanholz, derFred, ec, kreuzschnabel.

Actualizando campos deportivos.

I am in the process of trying to update and add bus stops and bus routes in San Diego County. The majority of current bus-stops are based on old data and are many are just a single located at an intersection. MTS and SANDAG have new SHP layers and update this information quarterly. I am approaching this in pieces so as to not break any functionality of the existing bus routes in OSM. However, from what I have seen, the vast majority of bus stops need to be changed and many routes are not added yet.

http://www.sangis.org/

TRANSIT_STOPS_GTFS Publication Date: 2017-06-28 Summary: Public transit stops and stations covering the County of San Diego. Bus, commuter and light rail, and trolley stops managed by the San Diego County Metropolitan Transit System (MTS) and the North County Transit District (NCTD). Data is developed from the General Transit Feed Specification (GTFS) data available from the transitland feed registry (formerly from the GTFS Data Exchange). Layer is updated quarterly and may not reflect most current route information.

TRANSIT_ROUTES_GTFS Publication Date: 2017-06-28 Summary: Public transit routes covering the County of San Diego. Bus, commuter and light rail, and trolley routes managed by the San Diego County Metropolitan Transit System (MTS) and the North County Transit District (NCTD). Data is developed from the General Transit Feed Specification (GTFS) data available from the transit land feed registry (formerly from the GTFS Data Exchange). Layer is updated quarterly and may not reflect most current route information.

I recently added "area roads" to downtown Durham, NC. I made the surface of the roads visible on Openstreetmap. I was wondering if their is any specific way to map road areas. I currently map them as "area = highway" and "highway = service". Feel free to check it out!

Downtown Durham http://www.openstreetmap.org/#map=19/35.99361/-78.89968

Downtown Chapel Hill http://www.openstreetmap.org/#map=19/35.91627/-79.05645

Chapel Hill Public Library http://www.openstreetmap.org/#map=19/35.93251/-79.03549

All three links lead to a place in Openstreetmap where I mapped roads as areas.

I anyone else mapped roads as areas, please reply a link to the location!

I'm tempted to replace all those named as clinic by the tag amenity=clinic, but maybe someone who has lived in Korea can confirm if that's appropriate?

Use this to find them: http://overpass-turbo.eu/s/rRX

3,7 km - Départ Gare RER B Le Guichet , Rue de Versailles, Impasse des Muriers, Chemin dans le Bois de Corbeville, Retour, Impasse des Muriers, Rue de Versailles, Rue du Fond du Guichet, Rue Aristide Briand, Rue du Guichet, Chemin du Libernon, Rue Bossuet, passerelle sur l'Yvette, Arrivée Promenade Lecomte deLisle.

• Trace GPS

• Carte openstreetmap et trace sur Geoportail

• Cette randonnée sur la Page Facebook Randonnées en Yvette Toit d'Orsay - Grotte de Corbeville - de l'extérieur Impasse des Muriers - Monter sur le talus à droite juste après le tunnel. Toit d'Orsay - Grotte de Corbeville - de l'Intérieur

Geburtstagswünsche

Hello i am Kajal Sharma and I love to write about Happy Birthday Sayings, Wishings, Birthday Greetings. also i like to write birthday sayings in various language so kindly check my birthday sayings collection.

Geburtstagswünsche

...

本エントリーは、Organized Editing Policy (https://osm-dwg.limequery.org/741554) の私家訳です。意訳を多分に含みます。アンケート本文はnyampireさんの訳 (http://qiita.com/nyampire/items/c801b0bc562436951f9a) をどうぞ。

--ここから--

組織的編集に関するガイドライン

OSMが始まったころは、趣味の範囲で空いた時間を利用してマッピングを行う活動が主なものでした。マッパーは好きなものをマッピングし、好きなツールを使い、自分がマッピングした内容に対して自分で責任を負っていました。

OSMが拡大するにつれ、組織でマッピングする活動が増えてきました。企業がマッピングチームを雇い、特定の地域や特定の用途を想定してマッピングをおこない、OSMデータを改良しています。他にも学校の授業でOSMマッピングするような、非有償のグループ活動もあります。

このような組織的マッピング活動は、今日ではOSM活動の一部分となっており、正しく活動が進められたならば、OSMがより良いものになり、知名度も上がります。

個人マッパーと組織マッピンググループの間で、コミュニケーションを円滑に行い、どの参加メンバーも平等であることを明確にするため、OSMFデータ・ワーキンググループでは組織的マッピンググループに対するガイドラインを策定中です。ガイドラインでは組織的マッピンググループに対して一定の透明性確保を要請する予定です。例えば、チームメンバーのアカウントを開示することなどが挙げられますが、すでに多くのグループが自主的におこなっている内容でもあります。

ガイドラインに対してOSMコミュニティが何を期待しているのかを把握するため、アンケートを準備しました。このアンケートは、OSMを編集している人、これから編集しようと思っている人、個人マッパー、マッピンググループの一員などすべての人を対象にしています。アンケートの結果をもとに、ガイドラインをより良いものにしていきます。

本アンケートおよび策定されるガイドラインにおいては、paid mapping(有償マッピング)を、「他の人または団体から、何をマッピングするのか指示され、その報酬として金銭を受領したOSM編集」と定義します。また、other organised mapping(その他組織的マッピング)を、「他の人または団体から、何をマッピングするのか指示されるが、金銭を受領しないOSM編集」と定義します。

アンケートは12問あります。

Hoje, eu entrei no projeto Projeto Cocal do Sul. Nele, vamos mapear todas as construções e vias da cidade de Cocal do Sul, SC.

Eu não sou muito bom com diários, então, por hoje é isso...

With this year’s Google Summer of Code’s recent successful completion, we thought it would be a good idea to recap and shine a spotlight on the individual projects. It’s the 10th year we were participating with success, so thanks to Google for supporting us again, and thanks to the Engineering Working Group for managing our participation this year!

The Google Summer of Code is a program run by Google to match student developers to open source projects. Students may apply to any of the participating projects, based on their preferences or relevant experience. The students that get selected receive a stipend (paid by Google) to spend one summer working on their project, gaining valuable experience while contributing code to real-world projects.

This year, we had five student projects with a really great student developer for each of them and all of them passed, i.e. they all finished their project plan in time. Additionally, there were two OSM-related projects outside of the OSMF umbrella: Indoor Support for Marble based on OSM and a plugin API to display OSM data on NASA Web WorldWind. But we had a bit of bad luck as well: Google gave us the opportunity to select even more students and, while we had applications from two more great students lined up, they didn’t start their project with us due to reasons not within our control.

Anyway, as not everyone was following the students’ work, we thought we should share the outcome of this year’s summer of code with you.

OpenGL Renderer for libosmscout

Let’s start with the first project, which is part of libosmscout, a C++ library for offline map rendering, routing and location lookup. What libosmscout doesn’t have right now is a render path based on OpenGL.

Tim Teulings, the mentor for this project, shared with us that he was very happy to see Fanny work on that task as none of the existing project members had time or the respective know-how, but it was still a highly requested feature. So they felt very lucky to have a great student like Fanny to work on it. What’s more, she even said that she’s keen on continuing to work with that project.

Her part of the library with a small demo application can be viewed on Github and all of her work was continuously merged.

As you can see, her renderer works quite well and produces beautiful maps. The objective was to support areas, ways, labels and ground to be rendered correctly. In addition to that, the code now supports most of the styling options and works on Linux, as well as on Windows. You can read more about the work and the results on her user diary.

We hope Fanny will stick to her plan to continue to work on libosmscout and stay a part of our great OSM community!

3D Model Repository

The next project we’d like to present to you is the 3D model repository by Pedro (also known as n42k). The project idea has been around for a while, but in the past we either didn’t have a good student or failed to get enough project slots. This year was different and we finally got both!

The task itself is easy to explain: “We want a website that allows uploading 3D models to use for OSM”. But still, there were a lot of decisions to make: The site is now intended for all kinds of models, unlike previous efforts targeted only at buildings. It will initially focus on OBJ as a file format, and will provide unique IDs that can be easily linked in OSM. To make sure that the models fit the needs of the various applications in the OSM ecosystem, developers from two 3D renderers (OSM2World and OSMBuildings) mentored the project together.

Pedro published some of his work in his diary and his highly appreciated code can be viewed at Gitlab. Currently, the mentors are in the process of checking with the OSMF’s Licensing Working Group and others to deal with some details like hosting, branding and some “legal issues” (e.g. with regard to the geocoding guideline), but we’re expecting to see the site go live later this year.

Enhancing JOSM pt_assistant

Another project we want to talk about is the enhancement of the PT Assistant Plugin for JOSM by Giacomo Servadei. While the plugin name suggests this is all about public transport, the scope of this project grew to include hiking and bicycle routes as well.

Besides the extension of scope, Giacomo worked hard to extend the plugin and make it even more useful. For example, it now allows you to sort stops according to the sequence of the ways in the route relations, and it helps you with splitting roundabouts while keeping the route relations that pass over it. But it also has a better check for problems and now reports and suggests fixes, for example gaps of a single way or routes that don’t start or end neatly on a stop_position node near to a corresponding platform node.

You can read about Giacomo’s main results and his detailed timeline in the wiki. It also includes direct links to the dedicated tickets and associated patches. All of his work got merged and you can easly activate his plugin and test the outcome for yourself.

In addition to that, Polyglot, who was Giacomo’s mentor for this project, has written some diary posts about it.

Web-based Public Transport Editor

Dkocich worked on a similar project, but this time it wasn’t about a JOSM plugin. Instead, the goal was to create a website to edit public transport relations without the need to start a full blown editor.

While the editor is not merged yet, this will probably happen soon. Before the finished version of the editor is published by his main mentor Ilya, you can already have a look at his great work and test his version of the OSM Public Transport Editor. You can also have a look at his code on his Github project.

JOSM Refactoring

The next project in this list is all about JOSM’s core code. This project was mentored by Michael Zangl, a former student who had participated in GSoC the two previous years, working on different JOSM tasks – an experience that had allowed him to gain a very deep understanding of JOSM’s core. This year’s project started out as an effort to refactor the menu bar to have a proper API to use, but the project’s goals got extended and modified a bit during the summer.

Bogdans worked hard to dive into JOSM’s codebase and familiarize himself with JOSM. You can have a look at his work on his wiki user page, which also contains a list of tickets he worked on and patches he wrote which got merged.

Much of his work is “under the hood”, so unless you’re contributing to JOSM development or plugins yourself, you probably won’t easily notice most of the improvements while working with JOSM. Still, there are some visible updates: Bogdans added the option to search based on presets, and also merged the “Download” and “Download from Overpass API” actions into a single dialog box. Furthermore, there’s a Wizard that helps mappers with constructing Overpass queries now, much like the one known from Overpass turbo.

Again, you can read more about his work on Polyglot’s diary, since he served as a co-mentor.

Summary

This was a great Google Summer of Code again and we’re very happy that we were able to participate. We want to use the opportunity to thank all the students for their work and we’re hopeful that you as a user will benefit from one of them as well. In addition to that, we’d also like to thank the mentors for spending their spare time to help the students finish their tasks and the EWG for doing the administration of this year’s GSoC.

After the conclusion of this year’s GSoC, we performed a small survey among our mentors to gather feedback, and even though some of them had to invest considerable hours in it, they unanimously responded that it was worth their time and that OSM should participate again next year. So we conclude by tasking the EWG to apply again next year!

It’s corn maze season in North America: for a couple months, farms all over are inviting folks to explore mazes they’ve cut out of corn fields.

A corn maze in Northeast Ohio by David Fulmer, CC BY 2.0.

In OpenStreetMap, several corn mazes have been micromapped across Southwest Ohio. The designs change each fall, so the mazes have to be micromapped all over again.

Look sideways: these pumpkins at Wendel Farms were previously visible in Bing and other aerial imagery, but the ways clearly need to be deleted now that the pumpkin design has been cut down (and replaced).

None of the aerial imagery providers have this fall’s maze designs yet – after all, these doodles are only weeks old in some cases. So I turned to the farms’ websites and Facebook pages, where farmers have posted aerial photos of their own mazes. I wrote to them, briefly describing OpenStreetMap and asking permission to update the map based on their photos. A few got back to me, happily giving permission. It’s free publicity for them, after all.

This year, Wendel Farms’s corn maze depicts a cow surrounded by various dairy products.

Since my preferred editor, iD, currently lacks support for overlaying arbitrary images, I built a copy locally and modified it to display the photo above the normal imagery and below the data. Using my browser’s Web inspector, I added a pattern to the SVG document’s <defs> element:

<pattern patternUnits="userSpaceOnUse" id="maze" width="956" height="1174">
    <image x="0" width="956" height="1174" href="dist/img/pattern/maze.jpg" y="200" />
</pattern>

and overrode the CSS style of the <path> element representing the edges of the field:

.area-fill > .w107158117 {
    fill: url("#maze") !important;
}

I probably could’ve done something more sophisticated to keep the image anchored while panning and zooming, but this was good enough for a quick, informal micromapping project.

Not too long from now, these corn mazes will’ve been cut down and plowed under, and the paths will also be deleted from OpenStreetMap in anticipation of next year’s corn maze season. But a snapshot of this fall’s designs will eventually appear in the standard aerial imagery and remain there for years to come. As a result, mappers can compare a corn maze’s appearance and the date on which the maze was micromapped to determine the vintage of the surrounding area’s imagery.

In the meantime, if you poke around Southwest Ohio, be on the lookout for cows and other scenes hidden among the cornstalks.

The Data Working Group is conducting a survey as part of its work on a policy covering paid mapping.

When OpenStreetMap started, it was largely a project of hobbyists contributing to OSM in their spare time. They chose freely what to map and which tools to use, and they took individual responsibility for their contributions.

The continuing growth and popularity of OSM have also brought more and more organised mapping efforts, mostly in the form of companies setting up paid data teams to improve OSM data in specific regions or for specific use cases, but also unpaid groups like school classes that are directed to work on OSM.

These organised mapping efforts are an integral part of today's OSM contribution landscape and, when done well, help make OSM better and more widely known.

In order to ensure good communication, and a level playing field, between individual community members and organised editing groups, the OSMF Data Working Group has been tasked with developing guidelines for organised groups. These guidelines will above all set out some transparency requirements for organised groups - things that are already voluntarily followed by most groups today, like informing the mapping community about which accounts edit for the team.

We have prepared the following survey with a few questions about such a policy to give us a better understanding of what the mapping community expects from such a policy. The survey is aimed at everyone editing (or planning to edit) in OSM, whether as individual mappers or as part of a team, and your answers will help us in fleshing out a draft policy.

Within the scope of the survey, and the policy to be written, we define paid mapping (or paid editing) as any editing in OSM performed by someone who is told by a third party what to map (and potentially also how to map it) and who receives money in exchange. We define other organised mapping (or editing) as any editing that is also steered by a third party, but where no money is paid.

Please participate in our survey here: https://osm-dwg.limequery.org/741554

As vias dos novos loteamentos normalmente não estão visíveis nas imagens satelitais disponíveis no OSM para edição, em razão da frequência de atualização das mesmas. A solução é percorrer as novas vias, gravando tracks/trilhas gpx para utilizar nas edições.

Realizei alguns testes comparativos, gravando alguns tracks utilizando um gps automotivo Garmin Nuvi 2580 e um gps de mão, o Garmin 76csx.

Para obter uma maior precisão, em ambos gps foram desativadas a função "Lock on road". Isto é muito importante, para forçar o gps a gravar a sua real localização. Sem este procedimento, o equipamento realiza "correções" a fim de coincidir a localização com o mapa visualizado na tela, obtendo um track impreciso.

No Garmin 76csx, o procedimento consiste em: http://wiki.openstreetmap.org/wiki/Garmin/eTrex_Vista_HCx

Nos gps automotivos Garmin Nuvi, o procedimento varia um pouco conforme o equipamento, mas de forma geral:
- nuvi 1000 ou superior: http://www.gpsinfo.com.br/viewtopic.php?t=4581
- nuvi 2xx e 7xx: http://nastrilhas.com.br/site/index.php/gps/23-garmin/17-gravar-um-tracklog-no-garmin-nuvi-2xx-e-7xx
- nuvi: http://www.mundooutdoor.com.br/melhorando-tracklog/

Após a gravação, foi realizado o efeito comparativo e concluíu-se que a diferença entre os tracks gravados pelos equipamentos é praticamente desprezível:

• Exemplo 01:

• Exemplo 02:

• Exemplo 03:

Assim, os colaboradores do OSM que quiserem utilizar seus gps automotivos para obter tracks para edição, podem fazê-lo sem maiores problemas. Ou podem ser adquiridos equipamentos usados a preços reduzidos, viabilizando os mapeamentos.

Quem tiver interesse, mesclei os tracks do gps Garmin 2580 com o Garmin 76 e subi para as trilhas do OSM:

http://www.openstreetmap.org/user/Tomio/traces/2505114:

http://www.openstreetmap.org/user/Tomio/traces/2505117:

http://www.openstreetmap.org/user/Tomio/traces/2505110:

Quite excited to be at the SOTM Asia 2017 Conference in Kathamandu this weekend. This year I'll be talking about my OpenStreetMap readiness assessment work and walk through on how the approach varies from prior art, opening new avenues for mappers to explore data coverage.

I'm also collaborating with Jennings Anderson on his contributor metrics analysis & trying to understand how does mapping community health reflects on the readiness work.

If you're at Kathmandu this weekend, do catch me up for more conversation over a Chiya! 👋

Hurricane Irma, Mexican Earthquake, Bangladesh Floods

Depois de alguns meses de dedicação e aproximadamente 23 mil buildings adicionadas, atingi a meta de desenhar casas e demais edificações em todas as vias da área urbana de São Gabriel (RS). Ao todo, 37 bairros e 3 núcleos urbanos autônomos. Faltam casas que estão encobertas ou que ainda não aparecem nas imagens aéreas, as quais serão adicionadas quando eu ou outros mapeadores formos coletar dados a campo (o que eu considero a melhor parte do mapeamento). A tarefa por muitas vezes parecia interminável mas vendo o resultado final valeu o esforço. O trabalho agora é de melhorar o mapeamento na zona rural de São Gabriel em paralelo com outras tarefas na região central e campanha do Rio Grande do Sul. Espero que com a geometria disponível, usuários sejam incentivados a adicionar informações, como numeração e nomes de estabelecimentos, relativas a cada building.

Started on project #2286 for a university project.

Helped out on #3593 , which was mapping buildings on Montserrat as the island is currently at risk of flooding and mud slides from Hurracan Maria.

Pour les journées européennes du patrimoine 2017, les contributeurs OpenStreetMap d'Ille-et-Vilaine ont réalisé une cartographie du Musée de Bretagne (Rennes) et de ses oeuvres majeures. Une contribution innovante puisque peu de musées sont encore cartographiés précisément en intérieur dans OSM.

Pour en savoir plus : https://openstreetmap.fr/musee-bretagne-indoor

We recently rolled out 8.2 million km² of high-resolution satellite imagery from DigitalGlobe to our base map. Read more about it here → https://blog.mapbox.com/updating-8-2-million-km%C2%B2-of-high-resolution-satellite-imagery-b68070bdf4b2

All this imagery is available to be used by OpenStreetMap contributors for mapping! 🎉

Here is a breakout of the extents:

Asia Major cities and urban corridors in Middle East, India, China, Turkey, Vietnam, Thailand, Malaysia, South Korea, Indonesia, and the Philippines.

Africa Egypt and parts of Kenya.

Europe Major cities in Poland, Ukraine, Romania, Iceland, and Hungary. Also Paris and Moscow.

South America Major parts of Brazil, Paraguay, Uruguay, Argentina, and Chile.

North America Large parts of Mexico, Cuba, and Central America, along with southern cities of Canada.

This imagery will enable mappers to trace intricate details like buildings intrusions, turn lanes, trees and so much more! Happy mapping! 🌐

Rio de Janeiro

Floating logs in Vancouver

Ijen volcano East Java, Indonesia

The new Presidential Palace, Abu Dhabi (UAE)

FAQ

Mapping: All this imagery is licensed for OSM tracing use.

Source: All this imagery is provided by DigitalGlobe from its satellites.

Date: Varies. We do not publish fine-grained date metadata, but we know it’s important to OSM and we hope to provide it in the future.

Local problems with imagery, requests to prioritize specific areas, and other feedback: Please submit through this form →https://www.mapbox.com/feedback/satellite/

A few years ago I started a bi-weekly video chat for US mappers, called Mappy Hours. They were fun and varied, with topics ranging from tagging discussions to a presentation about OpenHistoricalMap and many things in between.

Then we all got busy and the Mappy Hours stopped. I was recently reminded about them on the OSM Slack channel, and I thought it would be nice to restart them. So here are the details of the first Mappy Hour:

Wednesday September 27 at 5:30pm Pacific Time

We used to use Google Hangouts, but there were problems with that: a limited number of video participants, you couldn't call in, plugins.. There is no perfect solution but I have had success with Zoom so we will try that. You can either download the Zoom client or call in using your phone.

Zoom link

There are local dial in phone numbers for many countries.

The topic for the first Mappy Hour will be State of the Map US. What are you looking forward to? Do you have a presentation you want to promote? Do you have ideas to make the conference even better than previous years? Let's talk! Even if you are not planning to attend SOTM US, I invite you to attend: there will be plenty of time to talk about other things as well.

I gave a talk at State Of the Map 2017, the official OpenStreetMap annual conference, which took place in Japan last month.

“The Diagrams of OpenStreetMap” is a tour of a various diagrams illustrating the project, but focussing more on my own diagramming efforts, including quite a few new diagrams I produced especially for this talk.

I would have mentioned in my talk, but I wasn’t going public with it at the time: I’m going to be available for new work opportunities soon. Maybe I can find something map related? We shall see (suggestions welcome). In any case I’ve been involved in OpenStreetMap, mostly as a volunteer, for over a decade now, and so I’m well placed to try to capture some “big picture” overviews of the project… in diagram form! That’s what I’ve tried to do here.

Watch the video on the conference site

Slides as a LibreOffice .odp file (7.3Mb)

But the following are slides and transcript as one big long blog post. In total there’s a whopping 61 slides (I was talking through them quite quickly). I’ve skipped over some animation step slides to reduce this down a bit, but still a lots of slides:

 

Jump to slide:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61

---

Slide 1

 

 

This talk is called “Diagrams of OpenStreetMap”. I started thinking about this after my previous 2014 State Of The Map talk.

 

---

Slide 2

 

 

In Buenos Aires I ran through some favourite visualisations which in some way capture the essence of OpenStreetMap

 

---

Slide 3

 

 

But I was mostly talking about the “long tail of OpenStreetMap”. The long tail graph shows a spike of a few big contributors on the left, and long tail of many people chipping in a little bit at the bottom.

I annotated this in various ways in that talk. I think this was my favourite. It’s showing the marketing messaging and really everything we do to make OpenStreetMap easier, which all can be related to different positions on the long tail graph.

We’re enticing a potential audience of many millions of people to come take a look at the website and find out about OpenStreetMap for the first time. Then enticing some of those millions to join the ranks of signed up users because you might want to edit… and then trying to entice those people to actually make an edit, since there are many signed up users who do not. So perhaps the message at that stage is to “be bold” and give editing a try.

I suppose it’s also showing that messaging for new joiners and website visitors, is very important in terms of number of people it applies to.

I like this kind of thing. A “big picture” diagram which tries to capture all of OpenStreetMap, or some aspect of it, explaining our project in a particular way.

 

---

Slide 4

 

 

Big picture diagrams are something I’ve been trying to do for a long time now. One of my very early contributions to the project was this technical components diagram …a decade ago now!

 

---

Slide 5

 

 

You may recognise it better if I show it like this. It was designed as a little illustration for the “develop” page on the wiki, where we listed various technical development activities. This page was fairly prominently linked and used to get a fair bit of attention, so it felt like an important diagram despite being pretty basic.

 

---

Slide 6

 

 

And this diagram went through a lot of different revisions, which you can see in the wiki history.

The way the diagram developed was actually kind of interesting. It represents some historical changes, but also an evolution of my own understanding.

 

---

Slide 7

 

 

It starts off with the “Java Applet” editor which feels like early history of the project now.

 

---

Slide 8

 

 

That was largely replaced by Potlatch in the next revision, and you can see I’m refining my understanding of how the tile rendering systems work.

We had a strange idea of calling the API the “Protocol Interface” at this stage, and you can see that I’ve incorrectly shown the “Planet.osm” feeding from the API. This is wrong…

 

---

Slide 9

 

 

….but fixed in the next revision, in November that year.

We’re showing JOSM consuming Yahoo! Aerial imagery via the “YWMS Plugin”. Remember that? That was rubbish. This still feels like early history

 

---

Slide 10

 

 

It went unedited for a while but here in 2009 I did another update. We’re calling it the “API” now and introducing the “diffs” alongside the planet dump.

So as I say, this was an evolution of my own understanding as much as anything. So a few people were involved in the sense that they were telling me the stupid things I was getting wrong, but… I was always hoping for some direct collaboration on this diagram, and later that year…

 

---

Slide 11

 

 

Boom! Collaboration!

Well sort of… ivansanchez redrew the whole diagram into this more spectacular creation, overwriting with the wiki comment (which you have to imagine spoken in Ivan’s cheeky spanish accent) :

“Brand new architecture diagram. I was getting bored of the old one (which by the way looked amateurish)”

Thanks ivan. Thank you very much!

He was right though wasn’t he? It was pretty amateurish. This looks much more of a pro job

Although… it’s getting more complicated. Showing more components, which may or may not be regarded as a good thing.

 

---

Slide 12

 

 

And the diagram continued from there through a few more iterations, with somebody else getting involved too to add some colours.

…up until this point in 2012. At this time it was removed from the “Develop” page on the wiki, and I think around the same time, the entire wiki was de-linked from the front page a bit, meaning this diagram no longer got much attention.

This seemed like a shame to me so…

 

---

Slide 13

 

 

Especially for this talk I decided to blow the dust off it, and make some more changes.

Now first of all I actually largely re-created the diagram because Ivan only had OpenOffice files from an earlier version, so I’ve recreated this in Inkscape now, and got it working directly from SVG within the wiki. Rather a fiddly task actually, but I’m hoping this may encourage more people to make edits to it

I also made various obvious updates. So I’ve included ‘iD’ editor alongside ‘P2’ (I have to thank Richard here for choosing nice short names for editors. Made drawing this bit of the diagram much easier!) and I’ve added some mobile editors.

 

---

Slide 14

 

 

The right hand side shows some tile rendering systems. I got rid of MapQuest, and we’re showing just those which are featured on the main page here. We show Leaflet and OpenLayers options at the top.

But it feels like there’s a huge range of output possibilities not really covered by this.

 

---

Slide 15

 

 

So I’ve done another iteration. This is the components diagram as it currently looks.

You may have seen my blog post about this. I’ve had a go at adding a bit more detail to the right hand side…

 

---

Slide 16

 

 

Near the top we’re now showing other web map libraries, and also mobile apps with web mapping app SDKs.

I’ve tried to introduce “vector tiles” here. We can feed vector tiles into a raster rendering system (e.g. as a Mapnik datasource), sending raster tiles to the browser as before, but these days we can also use “Vector Plugins” such as Mapbox GL JS / Tangram to render vector tile data in the browser. Likewise in the mobile SDKs.

I’m happy with this as as a conceptual summary diagram but vector tiles is a confusing array of different technologies on server-side and client-side, following different standards/schemas. I’m confused by this, so I’m probably the wrong person to try to draw such a diagram, but I think this is also a clue that this is an information gap, and a great diagram could help bring clarity to me and to lots of other people. So can we find a diagram to help with this?

 

---

Slide 17

 

 

I found this diagram on the Q&A site which made me laugh.

Map data from OpenStreetMap(s!), a style definition, in the end map tiles, and …what is that ’???’ thing in the middle?

Not a very revealing diagram, but just look how much more interesting this question is when there’s a diagram added!

 

---

Slide 18

 

 

This diagram is probably the closest to what I’m looking for actually. I found this in the Delft Students on Software Architecture, so some sort of university project to document open source, with a chapter on Mapbox GL JS. We’ve got boxes for client and server side components and various mapbox technologies and APIs. I don’t understand some of the arrow directions here.

 

---

Slide 19

 

 

But what I’m looking for is a diagram with boxes and arrows for the range of different vector technologies from MapBox, Mapzen, OpenMapTiles, ThunderForest, Wikimedia, also the various client-side libraries, and laying out the different standards, and some indication of compatibility (the concept of vector tile “schema” and how that effects compatibility)

This is a sketch I drew while chatting with Matt in the pub, but when I got home I realised I didn’t understand it! Always the way.

Unless anyone can suggest an existing diagram, I hope to revisit this, and I hope to pick the brains of people at this conference to understand it better.

 

---

Slide 20

 

 

OK. Here’s another diagram I created quite a while ago. Actually I think I was regarding it as a successor to the component diagram for some purposes. It’s showing fewer technologies, just some key ones and broad concepts and trying to show an ecosystem of data users.

Actually I created this, not just as a diagram, but as a slide deck forming a kind of animation, introducing tech topics as the diagram builds up.

I’ve presented this four or five times now, to various technical/developer audiences, as an introduction to OpenStreetMap.

 

---

Slide 35

 

 

I found this diagram by Steve Bower which does a similar thing of placing the raw OpenStreetMap data at the centre of the diagram, with many arrows radiating out from it.

 

---

Slide 36

 

 

I like this diagram by Andy Woodruff from a web maps 101 maptime talk. That’s for a similar web developer type audience, and the diagram covers the tile server rendering bits.

I like the way it also has “feature layers” coming in on the right hand side. That’s the bit web developers tend to be more familiar with from using google maps (which offers less control of the left hand side)

 

---

Slide 37

 

 

Sticking with tech topics for a little longer…

Here is a diagram by Komяpa showing the database of OpenStreetMap (website & API). Maybe this kind of thing is useful for developers?

At this zoom it might be better not listing out the fields and just show table names. But I showed this to some of the sysadmins and we played a game of “guess the database table”. The well linked table on the left with lots of fields is the ‘user’ table. The well linked table on the right is the ‘changesets’.

 

---

Slide 38

 

 

Here’s diagram showing the rails app “models”, which is more or less the same thing but a little different.

This is very old. Shaun did this in 2008, so maybe we should try re-running this “Railroad” tool to regenerate it now. The fact that this whole diagram is automatically generated, is kind of interesting.

 

---

Slide 39

 

 

Here’s something a bit different, but again automatically generated.

Matias Dahl made these diagrams which show tag transitions, meaning it’s tracking things which have changed from one tag to another, and looking at the statistical frequence of these transitions, which turns up some interesting linkages, showing that tags are related, but often confused, perhaps because they are very similar or overlapping in their definition.

There are all prefixed with the amenity key, so we can see in the example I’ve pulled out, that people commonly “fix” these various other values to become amenity=drinking_water . You can imagine people might accidentally tag something as amenity=fountain when they meant a drinking water fountain. So that’s just an example, but on the right is the really big diagram covering lots of interlinked amenity tags. And being an automated process, he could re-run it for other keys.

This is neat use of the big “history dump”. He had crunch all of that data rather than just the current “planet dump” in order to figure out these tag transitions.

 

---

Slide 40

 

 

OK. Something completely different now. We’ve been fairly techy so far, but how about this for a diagram?

This is an old diagram which Steve Coast used to show, to explain the project in the early days. The idea is, as OSM quality improves at zero cost, moving along the bottom axis, we start to exert a downward pressure on the price point of traditionally licensed closed data providers, even if we haven’t yet reached their level of “quality”.

This is UK specific, talking about the Ordnance Survey, but you might be able to draw a similar diagram showing a monopolistic over-charging data supplier in your country.

…and actually the situation in the UK has changed now.

 

---

Slide 41

 

 

Ordnance Survey released some of their datasets as free open data, so we have to show this rather more complicated picture. Different products. Different price points. Debatable positions on the quality scale (depending on your use case)

I find it useful to show this, if only to point out that the Ordnance Survey have not released all of their products as open data (a common misconception)

 

---

Slide 42

 

 

Here’s a different diagram. An “organisation chart” for HOT. These are the HOT paid employees. We can see their different teams.

I really like that we can see their mugshots. It feels softer, more human, and more real than just showing people’s names. It makes us feel we know each other better.

 

---

Slide 43

 

 

We also use mugshots on this page, which is showing HOT working groups. These are not staff but volunteers now. It could be interesting to blend the two diagrams somehow.

 

---

Slide 44

 

 

What about the OpenStreetMap Foundation? It only has one member of staff doing admin, so the staff org chart would be boring, but we do have a board and some working groups arranged like this I suppose.

Given that some working groups come and go and are more/less active, while others are like OWG and DWG are performing essential functions, it could be redrawn to show some being more important than others I suppose.

But there’s an obvious limitation/problem with this diagram, and with the previous HOT diagrams. They don’t show anything of the big OpenStreetMap community where a lot of the action is. Some “work” happens in things like working groups, and HOT paid staff positions, but vast amounts of “work” go into making OpenStreetMap great outside of these organisation structures.

 

---

Slide 45

 

 

…in what we might call a “disorganisational structure” (to be a little flippant)

I have this vision of the OpenStreetMap community represented as a wibbly wobbly jelly blancmange thing. A big community of many volunteers working to build OpenStreetMap up into something great. Reaching upwards for the sky.

 

---

Slide 46

 

 

People make collaborative contributions, or individual contributions, sometimes as one-offs before disappearing again.

In the middle of the diagram we have folks working together, and managing to build on eachother’s work to some extent, for example with large important OSM projects like developing the core website & api, and JOSM / iD editors. Things like “Overpass API” also get subsumed into this central column of collaboration, with many people building upon it, and relying on it as a stable bit of infrastructure. But like many things it started life as more of an individual pet project. A great contribution (forming a tall blob on the diagram), coming from the community at large and gradually being drawn in as a more central thing.

This is not just about tech contributions though. It’s also people creating great documentation resources, or blogs, or building great local communities.

But a lot of volunteer effort comes and goes. Things get set up but then get shut down a while later. There’s a lot of ebb and flow. A wibbly wobbly jelly.

 

---

Slide 47

 

 

There’s various things which we might collectively call “Organisation building”, which I think of as attempts to build some solid structure. To make things less wibbly wobbly,

Things like working groups, things done as university projects, or even paying staff to do certain things. These are slightly boring classic organisation type things, which can feel quite different from our normal volunteer driven do-ocracy.

When I served on the board of HOT, we talked a lot about the challenges of building a “hybrid organisation”. This reinforced jelly diagram/metaphor popped into my head a lot. I think we should try to do organisation building activities in a way which is not working around or re-doing volunteer activities, but supporting them. Placing good solid cast iron girders for the community to climb upon, to bring OpenStreetMap to higher heights.

 

---

Slide 48

 

 

OK. Something different again.

Here’s a diagram which for a long time was shown on the first page of the wiki beginners guide. It shows the mapping workflow in 5 steps. Actually the whole wiki guide was structured around this. I think in a way that was quite good, because there’s many different ideas for ordering this guide. I think this diagram forced us to settle on one idea for the overall structure, partly because the graphics is quite nicely done, so nobody felt able to re-draw it!

But the five steps may seem a bit weird. If you’ve never used a GPS unit, you may be wondering why that is presented as the first step in the mapping workflow. Actually the 2nd step is also referring to uploading of GPS data, “upload data” being a confusing title. Likewise “edit maps” and “edit data” are confusing titles for steps 3 and 4. It means “edit nodes/ways” and “edit tags”. Those are OK as titles for chapters of the guide, but here it seems to suggest you do one then the other as separate steps. I suspect the step 5 “render maps” also dates from a time back when we needed to run our own data through osmarender and upload the image to the wiki, because there was no front page map! All said and done, there’s lots wrong with this diagram, but…

I’m interested in what we would replace it with nowadays. How dow we capture the steps of mapping workflow in diagram form?

 

---

Slide 49

 

 

There are many different mapping workflows. In fact there always was, even back when it was all about using these GPS units. You could gather GPS tracks, giving you a spiderweb of lines along where the streets are, and then just name those streets etc from your local knowledge. But people have invented quite range of other ways to gather and record data. You could mess around with waypoints and write them down on paper. You could take photos and correlate them by timestamp (I used to do a lot of that). You could use a dictaphone.

Some folks would just dump their GPS tracks and never do any editing of map data.Now that would mean that you could build upon this by gathering data (using just paper) about street names or POIs and position that it in relation to other people’s GPS tracks. In theory you could even simply add roads over other people’s GPS tracks without even knowing the area (an early kind of armchair mapping) but I don’t think this was a common approach.

But of course we need to add aerial/satellite imagery to the picture here.

It’s worth noting, before I do that, that there are still some parts of the world where we don’t have useable imagery, so these workflows are still where it’s at.

 sl

---

Slide 50

 

 

I’m trying to show all the different combinations of tools and data sources we might use, so if we add the use of aerial imagery as a possibility, then we get this combinatorial explosion in the number of different mapping workflows.The bottom half of this, is showing workflows now incorporating imagery.

But towards the bottom, some of these mapping workflows are made dramatically more viable when we have imagery. In particular, at the very bottom here, you can quite easily and effectively skip the data gathering stage entirely, and simply sit and home and edit the map based on what you see in the imagery. Armchair mapping!

 

---

Slide 51

 

 

OK but these combinations are getting out of hand. Let’s condense this down. Imagery can be thought of as an optional source for use while we are inputting our data. If it’s available you’ll generally use it, even if you’ve got lots of GPS tracks and photos etc, so it’s almost not worth mentioning there. But obviously it enables this big new approach of armchair mapping at the bottom.

In the middle we’ve got paper based approaches. Map printouts like field papers, or just taking some notes on a piece of paper.

 

---

Slide 52

 

 

But while we’re on the topic of paper, I want to draw attention to what I call the “Lubumbashi Workflow”. As a humanitarian mapping thing, people in Lubumbashi in DRC, were asked to write down street names and other details on field papers map printouts. These sheets of paper were then brought back to mapathons in London (and Berlin too I think) and we inputted the map data there.

So this is a workflow involving two different sets of people. Because this editing is in an area we don’t know, maybe it’s a kind of armchair mapping (as humanitarian mapathons generally are) …but maybe not, because we’re taking this locally surveyed data, which is coming from the local community. We could think of it as a souped-up survey powered kind of armchair mapping.

I love the Lubumbashi workflow by the way. A great way to get low-tech local communities involved. The approach has been used several times since, and we should carry on with more of this!

 

---

Slide 53

 

 

That’s not the only kind of souped-up survey powered armchair mapping actually. Connected to armchair mapping down in the bottom-right here, Street level photos from Mapillary and OpenStreetCam, and OSM Notes, when they are added somebody else, can act as a new kind of data source for armchair mapping. Those new mapping workflows are a kind of enhanced armchair mapping, which feels closer to survey-based mapping.

Another box I’ll add here is “community import”. This is where we’re using an external datasource, and we copy data into OpenStreetMap bit-by-bit as armchair mappers. Like imagery though, we might have a dataset available as an optional source to make use of during any editing session. I’ll talk a bit more about importing in a minute.

 

---

Slide 54

 

 

I added field papers in yellow before, so let’s add a few more yellow boxes to this diagram for software/tools.

For armchair mapping we (sometimes) use tools which guide us on what to map. “Tasking Manager” is obviously one, but “Maproulette” also does this in a different way.

At the top in relation to “editing at home”, this is going to involve a desktop editor. JOSM and iD being the main options.

And aha! There’s a whole workflow style I didn’t mention yet.

 

---

Slide 55

 

 

Mobile mapping! Mobile devices allow us a workflow which cuts through this devide between gathering data and inputting data. We do both at the same time, so a wide bar crossing both sides of the diagram. Typically that’s done with apps like Go Map!! on iPhone and Vespucci on android (There’s many other editor options of course. I’m just showing some leading examples)

Even when not using an app to input data, smartphones can make data gathering easer. In particular geo-located photos!

So I want to put this forward as a new diagram to showing mapping workflows. As with many diagrams we have to choose how much detail to show. I like the balance I’ve chosen here. As I showed earlier, trying to show more data source combinations gets pretty messy.

 

---

Slide 56

 

 

We could choose to condense it down more. We can group mapping workflows into survey-based mapping, armchair mapping, and imports.

I see these things on a spectrum. Survey mapping is rich and detailed and creates a dataset backed by a community of local mappers. At the other end of the spectrum, data imports will get mapping done very quickly, usually with even coverage. But (downsides) we’re blatting in data quickly, sometimes crudely, and side-stepping the community building problem. In the middle, armchair mapping e.g. with these big humanitarian tasking manager projects. It’s also blatting in data quite quickly, but at least at a human speed, using humans to use the OpenStreetMap editors, as part of, if not a local community, at least a community.

 

---

Slide 57

 

 

I probably just said something you disagree with, because I’m very much straying into a divisive area of OpenStreetMap politics now.

It’s a kind of tribal politics which Mike Migurski drew attention to, identifying groups he called “Craft Mappers”, “Humanitarian Mappers”, and “Robot Mappers”. He was discussing some particular debate related to robot mappers at the time, but I think it makes more sense to lump those in with a broader group of “Import” people. Anyway he labelled these groups and then…

…went on to conclude that “Craft Mappers” are all wrong and taking the project in a bad direction, which I disagree with pretty fundamentally.

 

---

Slide 58

 

 

The idea of doing survey-based mapping, is not just some old idea we need to move on from. It’s core to what OpenStreetMap is. “Map your neighbourhood”, because if we all map our own neighbourhood and get enough people to do this, then we’ll have a free map of the world. Many hands make light work. A huge community of people coming together to create the map, and to maintain the map. It’s what makes OpenStreetMap unique. We’re not just an aggregation of data. Our map is created by a community. The data is backed by a community.

Imports, armchair mapping, and humanitarian mapping (which largely overlaps armchair mapping) are extensions to the core idea of OpenStreetMap. They should be carried out with due deference to the core idea of OpenStreetMap. This means finding ways to minimise anything which detracts or impedes the message and the practicalities of “map your neighbourhood” community growth.

 

---

Slide 59

 

 

But I agree with one point Mike Migurski’s was making, that it feels like some unhealthy tribal politics has developed here. This “craft mapper” group of old timers are in danger of being seen as the “grumpy old farts” of OpenStreetMap, particularly if this group seems to be cliquey, unwelcoming and negative all the time.

But the “map your neighbourhood” message is a positive message, and a welcoming message. It’s all about welcoming more mappers to our community (but making sure we don’t do anything to inhibit that)

So to the craft mappers I want to say, let’s find ways to amplify that positive message. Less of the snide remarks in back-channels. Less of the polarised entrenched viewpoints. And let’s try not to be grinding on with negativity too much.

 

---

Slide 60

 

 

This will help us to become more unified and less tribal.

But if you are looking upon craft mappers as grumpy old farts, I would ask for your understanding. It’s not easy to defend these principles without sounding negative. Understand what OpenStreetMap is at its core. If you’ve only ever done humanitarian mapping, try mapping your neighbourhood just once. You might like it! Let’s keep refining the HOT validation process to help ensure we’re not blatting low quality data too quickly, and (In the developing world this is always going to be difficult but) wherever and however possible, let’s keep doing what we can to foster local communities and local mapping in addition to the armchair mapping.

If you’re keen on imports, understand that we don’t want OpenStreetMap to feel like a data dumping ground. Blatting in data could be detrimental to community-building; The “map your neighbourhood” thing we’re operating here. Again, understand what OpenStreetMap is. Follow the guidelines. Sell your import idea to the community, but dont get angry if our community doesn’t buy it.

Sometimes defending the core idea of OpenStreetMap can feel like an unavoidably negative discussion. Let’s look for ways to positively advise and reinforce the behaviour shifts we want to see from armchair mappers and importers. Set out rules, but also friendly guidance, and reminders of the reasons & the principles we’re defending. Find consensus on where we should draw the line. And let’s celebrate examples of where it’s done well.

Unify the tribes of OpenStreetMap!

 

---

Slide 61

 

 

…so we’re all in one happy OpenStreetMap family. Wouldn’t that be the best diagram of all? So I’ll leave you with that one. Thank you very much!

 

Jump to slide:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61

Mini-abstract

Tracking vandalisms is often not an easy task. To accomplish this activity I hardly find useful digging in the history of OSM changesets.

Instead OSMAT features a clean list of create/modifiy/deletes and tag changes; the latter one is particularly useful to track "advanced vandalism".

OSMAT focuses on fast detection, so don't expect to configure it on a national base, since rows will start to scroll too fast for spotting problems. For the same reason, OSMAT relies on minimal base of mappers and (quoting its wiki) "Improve[s] team spirit of a regional OSM team/task-force".

The following installation procedure has been brought live on a OrangePi PC single-board computer. Here you can find a regional live instance for Friuli Venezia Giulia Italy.

Docker installation

OSMAT deployment is Docker based, so refer to Davide's Docker installation

OSMAT download

Then download OSMAT sources:
$ git clone https://github.com/MichaelVL/osm-analytic-tracker.git

Check docker service

$ sudo service docker status
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled)
Active: active (running) since Sat 2017-09-16 11:40:37 CEST; 2 days ago

OSMAT configure

Once you got docker up and running (I had to upgrade linux kernel > 3.10 for my Jessie Orange Pi) and before compiling container, you have to configure active region.

Default available regions are the ones defined by Geofabrik. For instance, navigate to nord-est, take note of .poly link (nowadays is https://download.geofabrik.de/europe/italy/nord-est.poly) and edit configuration file:

$ cd osm-analytic-tracker
$ vi config.json
You'll need to replace 3 occourences of default "denmark.poly" with your poly (for instance "nord-est.poly", without any trailing URL).

Optionally, here you can also adjust:

• map zoom level and time horizon, just search for "map_scale": "6"
• logging interval, search for "horizon_hours": "48"

Compile container

Once you're done with region & zoom configuration, set your device OS (mine is Armbian, which I've found Raspian compatible) commenting one of the following lines :
$ vi Dockerfile #FROM debian:jessie FROM resin/rpi-raspbian

then compile container:
$ sudo docker build -t osm-analytic-tracker .

Run

Then choose which port to listen (mine is 8889) and run it!
$ docker run -d --restart=always --name=osmat-container -p 8889:80 osm-analytic-tracker

[optional] Customizing

If you need a particular Area Of Interest, I've found easier to add a line in default regions list:

1. Build a polygon: use JOSM opendata plugin to easily build and save a .poly which will be your AOI.
   
2. Publish myAOI.poly somewere in internet
   
3. Edit docker/regions.txt adding (or replacing) geofabrik URI's with your URI, for instance:
   $ cd docker
   $ vi regions.txt
   http://bpi.uk.to/osm/regions/myAOI.poly
   https://download.geofabrik.de/asia/myanmar.poly
   https://download.geofabrik.de/asia/japan.poly
   https://download.geofabrik.de/asia/vietnam.poly
   [snip]
   
4. Stop, remove and re-run container:
   $ docker stop osmat-container
   $ docker rm osmat-container
   $ docker run -d --restart=always --name=osmat-container -p 8889:80 osm-analytic-tracker
   

Try it

Go to http:127:0.0.1:8889 and wait for some changeset :-)

If you don't see any changeset, at least you should see the map centered in your AOI and read in the upper right corner "Lag" around 1-5 minutes. Just wait for the next OSM changeset.