Как то даже не заметил как проскочил юбилейный рубеж в 500 правок :)

Bringázásra Tárnok Százhalombatta benta patak part Jó időbe kiváló

Wikipediaよりも詳しく出ているので驚きました。

1. Armchair Mapping Mistakes

• Going to a place to survey it, returning home to mark it on OpenStreetMap, and then saying it was an armchair edit since I wasn't actually at the location when I uploaded my changes.

• Assuming that just because something was there in my childhood, that it still would be there and unchanged.

• Trusting satellite imagery more then my own eyes.

• Not correcting misaligned satellite imagery with GPS traces.

1. Surveying Mistakes

• Taking photos in public places like Main Street. It's better to be discrete and take photos from behind a car window then risk aggravating rural locals.

• Trusting a wonky smartphone satnav and compass when using Mapillary. Openstreetcam handles the wonky satnav part really well, but it's even worse with the compass since you can't currently correct it manually after uploading like in Mapillary.

• Using OpenSTREETcam on a footpath.

• Not uploading high quality 360's to Mapillary when possible and instead focusing on low quality 2D images.

• Not using Mapillary or OpenStreetCam at all when there was no coverage in my area.

• Not annotating as I mapped of areas with really outdated satellite imagery.

• Surveying without a full charge on my devices.

• Using a standard lens instead of a wide angle one.

1. Community Mistakes

• Not taking advantage of my surveys to also improve Wikipedia, Wikidata, and Wikivoyage.

• Not editing the OpenStreetMap wiki to help other mappers.

• Trying to do things alone.

Something in the weekly newsletter caught my eye:

Miguel Sevilla Callejo (msevilla00) from Zaragoza, Spain, is currently in Wales. He noticed an inconsistent use of English and Welsh in OpenStreetMap. His email resulted in a readable, long-lasting and controversial discussion on the Talk-GB mailing list (threads in July and August) and comments in an OSM changeset. Nearly the same problem in Switzerland – read the following article. 😉

— http://www.weeklyosm.eu/archives/9374

Miguel Sevilla Callejo (msevilla00) de Saragosse, en Espagne, est actuellement au pays de Galles. Il remarque une utilisation pas toujours cohérente de l’anglais et du gallois dans OpenStreetMap. Son courriel a donné lieu à une longue et controversée discussion sur la liste Talk-GB (juillet et août) et des commentaires dans un changeset OSM. Presque le même problème en Suisse – Lisez l’article suivant. 😉

— http://www.weeklyosm.eu/fr/archives/9374

So I went to the “Multilingual names” page https://wiki.openstreetmap.org/wiki/Multilingual_names and found Canada conspicuously absent. Is this because:

1. we're already doing it perfectly in Canada; or
2. local mappers already know what they're doing (an argument that seemed to be dismissed in the original discussion about Wales); or
3. nope nope nope not touching that with a rad-hardened barge pole?

Io, Tania, Fabio e Vale

https://youtu.be/b5QersrtJWQ

GPX Playerとは、動画とGPSログを見やすく再生するソフトです 前半ではGPX Playerの使用方法を 後半ではGPX Playerを使ったOSMの編集を説明します。

I recently received notice that a changeset I had made had been reverted due to not following the protocols in place for importing data. First the facts of the matter. My family was going to vacation at Folly Beach in South Carolina and I thought it an excellent opportunity to do some mapping while in the area to verify local businesses and add information about them to the map. When viewing the area in OSM I saw that only a few buildings had been mapped and that the majority of POIs were nodes. I decided that I would see if I could find a building footprint file already created from the county so that I could add the buildings to the map and then replace the node information with tags connected to the structures where a single occupant resided within the buildings. I find this to be cleaner when it is able to be done rather than have closed ways and nodes trying to describe the very same thing. Now I will admit that I had some confusion and very much a lack of knowledge of what constituted an import and the process that was in place to regulate them. I found a file with the county for building footprints, exported the buildings for Folly Beach using Qgis, cleaned up the attribute data so that when bringing them into JOSM they would have the tag building = yes and proceeded to copy them into the main layer. After this was done I scoured the area for duplicates and resolved any there were, removed nodes that had POI information and instead attributed that information the the closed ways, and used the error checker to insure that I had not introduced any errors. I believe it was necessary to move some roads that ran through buildings due to geographical error but other than that it was nearly a blank canvas. I posted the changeset and readied myself for my vacation.
On arrival and with the mind to do some mapping in the wild I loaded up Vespucci and began downloading the data so that I could get to it. I was amazed to find that the buildings I had placed and properly attributed had been removed. When I arrived back at home I checked my email and found that a user had redacted my changes and rolled everything back to as it was before I began editing, citing a lack of a wiki page or discussion within the import mailing list. I searched out the import page to see if I had been in violation and it would seem that I had been. Mea culpa, mea culpa.

Now based on the directions at the import site I can see that if a group was to be doing very large and numerous imports the instructions make complete sense, especially in regards to large geographic areas. The need to insure that data is duplicated or error is introduced has been addressed and I see that there were lessons learned the hard way. Based on the instructions included it seems that the idea is about very large imports along a county, province, state, country, or large city where the potential for error is far greater and much data may already exist. Folly Beach is, according to Wikipedia, 18.9 square miles, the data that existed were a few nodes, the beaches, the wetlands, the roads, and a couple of buildings. The chances of error were minuscule and the import, which I acknowledge failed the guidelines, was checked over for error. My problem is that the wholesale redaction of the changeset did not actually look at whether there was an improvement to the map (I believe throughout the OSM community it is generally found desirable to have buildings represented) nor if any error had been introduced. It would seem rather that a prominent individual within the community has created an account that is solely dedicated to a vigilante style role of cleaning up what he describes as vandalism and what he deems to be bad imports and mechanical edits. Now while this role may be a valid and needed one I do find it intriguing that while there is so much oversight in the import process, one individual can decide for himself without discussion or debate that a changeset is either vandalism or an illegal import or is damaging to the map. Be that as it may I submit myself to that editing as I had seemed to violate the protocols in place.

As to the protocols themselves I find that while it does seem to make sense to prevent error or duplication, it has a chilling effect on mappers and on entities that may wish to upload their data to map. In the United States there are 50 states, 3,007 counties, and 19,354 incorporated places that are, for the most part, independent of one another. This also does not take into account that each of these entities would have multiple commissions or departments that could have interest in uploading data to the map. What the import guidelines would mean for these groups, should they wish to share data with the map, is that they would each create a wiki page for each import they wish to do, they each create an account specific for the import, and that they would submit their import to a mailing list for approval. Having worked in the public sector for small government I can verify that the majority would not want to go through this hassle every single time they wished to share data with the community at large, nor would they have the time at their disposal to do such. This leads to less adoption of the map and a loss of great data for the map. The question would be what to do about this.

We could hope that the many different entities would work in cooperation to limit the amount of import wikis and requests by combining their efforts or even forming a committee to combine their efforts thus making the requests less numerous (presupposing mass adoption of the map). This could happen and it would be great, but I do not see it in the near future as many have no idea about the map or about contributing to it. The second proposal that I would humbly submit is this, allow a trusted partner status to communities and groups much in the same way that Google has done with their map. Communities have a great desire to see their communities represented accurately in online maps. In two of the local governments I worked for we had this partnership with Google, which did not exclude us from scrutiny but rather gave us the benefit of the doubt that we knew what we were talking about. With this process an entity would need only submit once for the right to import, committees that accept the applications can make a stress of what imports are allowed and the requirements the group must follow, verify that the group is legitimate, and then approve them to maintain their AOI on the map. I think this process could lead to greater adoption and more accuracy for the map in the long run.

Whatever may be decided on the future of imports I still acknowledge my error and humbly offer my apologies for breaking protocol in my efforts to strive for the bettering of the map.

Here's my list of some scientific articles on OSM that I might read once retired:

• Neis, P., & Zipf, A. (2012). Analyzing the contributor activity of a volunteered geographic information project—The case of OpenStreetMap. ISPRS International Journal of Geo-Information, 1(2), 146-165.

• Neis, P., & Zielstra, D. (2014). Recent developments and future trends in volunteered geographic information research: The case of OpenStreetMap. Future Internet, 6(1), 76-106.

• Senaratne, H., Mobasheri, A., Ali, A. L., Capineri, C., & Haklay, M. (2017). A review of volunteered geographic information quality assessment methods. International Journal of Geographical Information Science, 31(1), 139-167.

• Barrington-Leigh, C., & Millard-Ball, A. (2017). The world’s user-generated road map is more than 80% complete. PloS one, 12(8), e0180698.

Qué alegría poder ir colocando nuevos puntos, áreas y alguna línea referidos a mi pueblo natal, Louredo. Es una población del ayuntamiento de Cortegada de Baños, en la provincia de Ourense. Eclesiásticamente, somos la parroquia de san Juan de Louredo, arciprestazgo de Ribadavia, diócesis de Ourense.

Las aportaciones de hoy fueron alguna modificación y añadido de caminos, fuentes públicas, situación de alguna viña y capilla antigua. Son detalles pequeños, bien es verdad, pero que me alegran. Al menos, pondré algunos nombres que otros podrán aumentar, mejorando el mapa. De momento, voy colocando mi pueblo en él, junto a pequeñas descripciones en gallego y castellano.

Over the past few years, I've been mapping a lot of bus stops and routes. Over the past few months I've been looking around how it's done in other places around the world.

What I find (this may of course be influenced by what I wanted to find) is that most bus stops start out as a node next to the way, tagged highway=bus_stop, usually with a name on it.

Then somebody comes along, who glues it to the way. Then somebody else comes along who maps a platform next to the way, using a way, copying all the tags over. They do this regardless of the whether a platform actually exists. They think they need this to add 2 objects per stop to the route relations. Somehow the wiki convinces them of the need for this.

Mapping platforms as ways where there aren't actual platforms feels wrong to me. Adding a set of details to more than one object also doesn't feel like the most sensible thing to do. Adding 2 objects to each route relation for 1 real life object makes working with these route relations harder to do.

I'd like to see that a casual mapper can start out mapping a bus stop as a node next to the way, as highway=bus_stop.

Possibly they add public_transport=platform to this node. It seems odd to do so, even if no platform is there, but that's how things evolved. Tagging it as public_transport=platform means that a role platform will be assigned to it in the route relation. (if the route relation has public_transpot:version=2). It's the answer I got when I asked the question a few years back on the mailing list. I usually put that node more or less where the pole is. But the exact position is not all that important, as long as it's more or less where passengers will be waiting.

As far as I'm concerned this node is what represents the bus stop at this side of the street, so it seems obvious that this is the node that should be added to the route relations. The nice thing about doing it that way, is that there is no need to transfer details or relation membership from one object to another. This node is there for the lifetime of the stop. One object to work with, containing all the details, including directly available coordinates.

Now the stop_position nodes. First off, I don't see a need to map all of them and since where I map bus lines they are not all present, I don't see why we would add any of them to the route relations. No need to repeat the stop's details on them either.

Then the platform ways. If there are actual platforms, I would tag them highway=platform/public_transport=platform. Nothing more, nothing less. No need to add them to the route relations.

Then the stop_area relations. This is where we get the chance to indicate which platform node(s) belongs to which stop_position node(s) (if mapped) and which platform way (if present). Doing it this way means to have such relations for each group, where a group is the ones on one side of the road or the ones belonging to 1 platform in a bus station. They can then be grouped in a hierarchy of stop_area_group relations, although this is only needed for the more complex ones and for bus stations.

Sometimes I wonder if I should create a proposal for this. Usually I give up before even getting started, as I know how hard it is to convince anyone in the OpenStreetMap universe, once they are set in their ways. Little by little I'm starting to build the courage to go ahead with it after all. Writing these diary entries is a small first step, also to see if there would be support for such a simpler way of mapping public transport.

Also don't get me wrong, it's still possible to fill in all the detail of the accomodation surrounding the bus stops, but in a way that builds further on what was mapped previously, instead of converting from one object type to another or needing to add details more than once.

OpenStreetMap, la plataforma de datos geográficos abiertos ¡cumplió 13 años! Como parte del equipo de datos de Mapbox, y miembros de esta comunidad tan grande que contribuye diariamente mejorando el mapa, no podíamos dejar pasar este día sin hacer lo que más nos gusta ¡Mapear!

Mapeando el Perú

Como parte del festejo, el sábado pasado nos reunimos por más de dos horas con el propósito de mejorar el mapa del Perú .

Los elementos que agregamos más fueron calles y edificios, a parte de puntos de interés, ríos, lagos, entre otros.

Los datos que más agregamos fueron calles (1199) y edificios (1022), además de puntos de interés, lagos, ríos, entre otros.

Comienzo despacio y atento a las posibilidades de esta magnífica herramienta. Mis primeras aportaciones se refieren a la zona de Louredo, mi pueblo natal.

En Twitter, aporto desde #SJLouredo

Un saludo desde Ourense.

Out of curiosity, I pulled some statistics on the US Rail network. This does cross into a bit of Canada and Mexico where the GeoFabrik extract approximated the boundary.

level_crossing  TOTAL   232167
crossing    TOTAL   8231

Rail_Bridge 47232
Rail_Tunnel 16394
Highway_Bridge  70811
Highway_Tunnel  8972

Total Layer Crossings 143409

A bridge or tunnel is counted as a single occurrence no matter how many rail lines are included. Each marked crossing node is counted, so a fully mapped rail yard could contain many crossing nodes.

For a closer look here is a breakdown of the top 20 categories of level_crossing - the first column is the type of 'highway', and the second column is the type of 'railway' in OSM:

residential rail    112659
service rail    29171
tertiary    rail    26789
secondary   rail    16717
unclassified    rail    12732
track   rail    10058
primary rail    6734
residential disused 1628
residential light_rail  1547
residential tram    1413
trunk   rail    1122
tertiary    light_rail  1114
secondary   light_rail  1059
service light_rail  676
residential abandoned   660
primary light_rail  517
tertiary    tram    493
service disused 435
tertiary    disused 372
residential Unknown 371
residential preserved   353

A type of 'Unknown' usually means that a node that joins 'highway' to 'highway' is marked as type level_crossing for example.

Similarly, here are the top 10 'crossing' types:

footway rail    2984
footway light_rail  2083
path    rail    881
cycleway    rail    762
footway tram    565
path    light_rail  116
cycleway    light_rail  96
footway miniature   86
footway preserved   62
residential rail    56
service rail    34

Note the presence of 'residential' and 'service' which are either newly incorrectly marked 'crossing's or a rail crossing at the junction of 'residential' and 'path' for example.

To see the complete breakdown to perform custom category groupings, obtain the raw .CSV files from Rail Crossing Counts

The Mayor and City Council of Baltimore acted swiftly after violence at the Unite the Right rally in Charlottesville, Va. led to a national conversation on the removal of Confederate monuments. The protests centered around the removal of prominent Confederate generals' monuments in that city. In Baltimore, the City Council passed a bill that permitting the removal of four Baltimore monuments to the Confederacy. The mayor executed the order by contacting local firms to remove the four Confederate monuments in Baltimore during the night of August 15, 2017, into the following morning.

OpenStreetMap is a database of physical features. Since the four monuments are no longer physically present, I have removed them from OpenStreetMap. The removed statues include the Roger B. Taney Monument, the Lee-Jackson Monument, the Confederate Soldiers and Sailors Monument, and the Confederate Women's Monument.

zu Teil 1

Communitywachstumspreis

Der Communitywachstumspreis soll für Anstrengungen zur Erweiterung der Community, nicht nur in räumlich Hinsicht, sondern auch zur Verbesserung der Vielfalt sowie zur Integration des humanitären Sektors sowie der öffentlichen Verwaltung verliehen werden.

Pete Masters aka pedrito1414 wird dafür gelobt, dass er seit vier Jahren als Koordinator beim Missing-Maps-Projekt aktiv sei, "unzählige" Mitwirkende in OSM eingeführt habe, Communities in Bangladesh, der Demokratischen Republik Kongo und anderen Ländern unterstützt habe und alle ihn lieb hätten.

John Sturdy sei ein wichtiges Element für die Entwicklung der albanischen OSM-Community und pflegt Kontakte zu einem Hackerspace in Albanien.

Andrew Braye leitet die GIS-Abteilung beim Britischen Roten Kreuz und ist ein Gründungsmitglied von Missing Maps.

Tony Emery und Jean-Louis Zimmermann wurden wegen der Organisation der State of the Map France 2017 in Avignon, Kontakten zur regionalen Verwaltung, Schulen und Vereinen in Südfrankreich nominiert.

Jessica Salo wurde für das Organisieren von Mapathons in Colorado (USA) nominiert.

In dieser Kategorie haben zahlreiche Kandidaten Beschreibungen, die in meinen Augen überlange Werbetexte einer PR-Abteilung sind. An Belegen mangelt es jedoch. Nur bei Jessica Salo ist eine Überprüfung mit einem akzeptablen Rechercheaufwand (zwei Klicks) möglich.

Aufgrund mangelnder Belege und einer dadurch nicht möglichen Überprüfbarkeit der Behauptungen enthalte ich mich aus Protest in dieser Kategorie.

Preis für Engagement in Lateinamerika/Afrika/Asien

Mangels ausreichender Kenntnisse und regionaler Relevanz dieser Kategorien enthalte ich mich und kann hierzu auch keine Wahlempfehlung abgeben.

Ulf-Möller-Gedächtnispreis

Der Ulf-Möller-Gedächtnispreis ist für Einzelpersonen gedacht, die das OpenStreetMap-Projekt erheblich vorangebracht haben – sei es durch gutes Mapping, Wohltaten für die Community und andere Leistungen für OpenStreetMap. Jedes Communitymitglied, das irgendwann seit 2004 aktiv war oder ist, kann vorgeschlagen werden.

Christoph Hormann (aka imagico) wurde für seine regelmäßigen Beiträge bei den Diskussionen mechanischer Edits und Importe[ auf den einschlägigen Mailinglisten] nominiert.

Martin Raifer wurde für die Entwicklung des Overpass-Turbo nominiert.

Nama Budhathoki wurde für seine Verdienste um den Aufbau der OSM-Community in Nepal vorgeschlagen. [Er ist Leiter des Kathmandu Living Labs.]

Richard Fairhurst [(Benutzer Nr. 165)] wurde für seine lange Liste an Beiträgen zu OSM, sowohl beim Mappen als auch bei der Softwareentwicklung vorgeschlagen. Von ihm stammen die Online-Flash-Editoren Potlatch 1 und 2, welche für viele Mapper das Tor in das OpenStreetMap-Projekt waren.

Miriam Gonzalez arbeit in der Communityarbeit bei Telenav und ist bei HOT aktiv. [Ihre restliche Beschreibung gibt nicht viel mehr her und ist eine heiße Luftblase.]

Es fällt mir in dieser Kategorie sehr leicht Miriam auszusortieren. Wer in dieser Kategorie nominiert wird, sollte sich durch sowohl besonders lange als auch zahlreiche Beiträge zum Projekt auszeichnen. Miriam ist erst seit gut einem Jahr aktiv. Man kann zwar in einem Jahr viel erreichen, aber "erhebliches Voranbringen" braucht mehr Zeit.

Die anderen Kandidaten sind in meinen Augen alle ausreichend lang bei OSM dabei. Meine Stimme geht in dieser Kategorie – welch Wunder – an Richard Fairhurst.

Mangels Zeit in den letzten Wochen habe ich mich nicht so intensiv mit den Kandidaten der diesjährigen OSM Awards auseinander setzen können und veröffentliche diese Wahlempfehlung leider erst kurz vor Ende der Abstimmung.

Wie stimmt man ab?

Man ruft awards.osmz.ru auf und wird meistens erst auf die OSM-Loginseite umgeleitet. Die Abstimmungsplattform wurde vom OSMF-Vorstandsmitglied Ilya Zverv (Zverik) geschrieben und ist auf seinem Server gehostet, daher nicht unter einer "offiziellen" openstreetmap.org-Subdomain. Durch den Login wird sichergestellt, dass jedes OSM-Benutzerkonto nur einmal abstimmt.

Anders als letztes Jahr, kann man in jeder Kategorie beliebig vielen Kandidaten eine Stimme geben. Man kann bis zum Ende des Abstimmungszeitraums noch seine Stimmabgabe ändern.

Die einzelnen Kategorien

Es gibt neun Kategorien, drei mehr als letztes Jahr. Für die Definition der Kategorien sei auf meinen Eintrag im deutschen OSM-Blog hingewiesen.

Im Folgenden gehe ich durch die einzelnen Kategorien. In jeder Kategorie findet ihr zu Beginn die Beschreibung der Kategorie. Danach folgt die Liste der Kandidaten mit einer Beschreibung, die neutral zu sein versucht und an das englische Original angelehnt ist. Als letztes kommt meine persönliche Meinung, die nicht neutral, aber wertend und ehrlich-direkt ist.

Core Systems Award

Die Definition: Der Core Systems Award (Preis für zentrale Dienste) soll für herausragenden Beiträge zu wichtiger, zentraler OSM-Software, -Systemen, -Prozessen oder -Ressourcen vergeben werden. Die Software/das System muss nicht unter der Kontrolle der OSMF stehen. Der Rails Port, osm2pgsql, OSM Carto, iD, JOSM, Mapnik und all die anderen Werkzeuge, die Mapper wissentlich oder unwissentlich tagtäglich nutzen, sind qualifiziert.

• Hartmut Holzgraefe hat den alten MapOSMatic-Dienst zum Atlantendruck, nachdem er offline gegangen war, wiederbelebt, indem er ihn geforkt hat und eine eigene Instanz aufgesetzt hat. Und das ist nicht das Ende: Jede Woche verbessert er seinen Dienst weiter. Er hat die größte Sammlung an Kartenstilen, die zum Drucken bereit sind. Sein Dienst unterstützt E-Mail-Benachrichtigungen und er hat die Benutzerobefläche verbessert. Man kann sogar zusätzliche Overlays einbinden.
• Bryan Housel ist der Maintainer von iD, dem Online-Editor auf openstreetmap.org. Kürzlich hat er ein Einsteiger-Tutorial ergänzt, das zum Ausprobieren sogar eine virtuelle Stadt bereithält.
• Andy Allan arbeitet seit vielen Jahren an OpenStreetMap-Projekten, am Kartenstil, der auf openstreetmap.org eingesetzt wird und seit einiger Zeit auch an der Website und API. Dort macht er gerade eine Fleißarbeit – er räumt auf.
• Kevin Bullock ist als DigitalGlobe-Mitarbeiter auf diversen State-of-the-Map-Konferenzen schon gefragt worden, wann DigitalGlobe endlich Satellitenbilder zum Mappen bereitstelle. Jetzt war es endlich so weit.
• Paul Norman und Matthijs Melissen haben über ein halbes Jahr den Kartenstil "OSM Carto" einem Refactoring unterzogen, eine Arbeit, von der man nicht viel sieht, aber trotzdem wichtig ist.

Ich tendiere dazu, diesen Preis demjenigen zu geben, der ehrenamtlich an einem zentralen Projekt lange arbeitet. In dieser Kategorie vergebe ich nur eine Stimme. Sie geht an Andy Allan.

Auf keinen Fall würde ich meine Stimme an Kevin Bullock geben. Zum einen sind die DigitalGlobe-Luftbilder kein "zentraler Dienst", zum anderen sollten die OSM Awards an Freiwillige und nicht an bezahlte Kräfte vergeben werden.

Auch bei Hartmut Holzgraefe frage ich mich, was an MapOSMatic "zentral" sein soll. Es ist nur eines der vielen Tausend Projekte aus dem OSM-Universum.

Bryan Housel bekommt von mir auch keine Stimme, weil er für seine Tätigkeit von Mapbox bezahlt wird.

Da Paul und Matthijs beim Refactoring sich, soweit ich weiß, nicht so sehr um die Kompatibilität mit anderen Kartenstilen gekümmert haben und man künftig nicht mit derselben PostgreSQL-Datenbank sowohl OSM Carto als auch einen der anderen Mapnik-basierten Kartenstile rendern kann, bekommen die beiden von mir keine Stimme.

Innovationspreis

Der Innovation Award (Innovationspreis) wird für den besten neuen Dienst oder Ansatz vergeben, z.B. neue Werkzeug zum Mappen, Bilderkennung, Digitalisierung oder OSM-Datenanalyse, neue Mappingtechniken oder neue Nutzungsmöglichkeiten für bestehende Werkzeuge.

• Stefan, Philipp und Martin, die Entwickler der OpenTopoMap, welche OSM-Daten in einem der TK50 nachempfundenen Stil rendert. Zudem stellt das Projekt OpenTopoMap wöchentlich aktualisierte Garmin-Karten bereit.
• Sajjad Anwar (geohacker) hat die manuelle Analyse von Änderungssätzen beschleunigt. Die meisten verwenden dafür bislang Achavi, welches aber langsam ist, weil es die Daten live aus der Overpass-API bezieht. Sajjad erzeugt die für die Analyse notwendigen Daten jedoch in Echtzeit und cacht sie, was die Ladezeiten verkürzt. Zudem ist das Rendering schneller. Seine Arbeit wird schon von OSMCha verwendet.
• Yuri Astrakhan hat die SPARQL-Schnittstelle zum Abfragen von Wikidata-Daten mit OSM verknüpft.
• Tobias Zwick hat mit der Android-App StreetComplete neue Nutzergruppen als Mapper erschlossen. Dabei handelt es sich um einen OSM-Spezialeditor, der einem zu erledigende Aufgaben in der nahen Umgebung anzeigt.
• Michael Straßburger hat einen ASCII-Renderer für Vektortiles geschrieben, sodass man sich OSM-Karten auch auf der Kommandozeile ansehen kann.

Ich werde in dieser Kategorie eine Stimmen vergeben.Die eine Stimme geht an Tobias Zwick. Zwar gibt es schon Manches auszusetzen, es handelt sich dabei jedoch um Fragen, die die Gestaltung der Aufgaben betreffen.

Die zweite Stimme geht an Sajjad Anwar. Zwar ist seine Arbeit Teil seiner Tätigkeit bei Mapbox, jedoch geht es in dieser Kategorie um die Innovation und nicht um das Engagement.

Da ich nicht mehr als zwei Stimmen vergeben möchte, geht Michael Straßburger leider leer aus. Ehrlich gesagt, hätte eine Implementierung des Renderers in C mehr Stil gehabt als in JavaScript.

Die OpenTopoMap ist eine Fehlnominierung und es spricht in meinen Augen nicht für das Auswahlkomittee in dieser Kategorie, dass diese Nominierung es in die Endauswahl geschafft hat. Das Projekt existiert schon seit Jahren und verstößt damit zum einen gegen die Bedingungen dieser Kategorie, zum anderen mangelt es mir an Neuheit.

Preis für einflussreiches Schreiben

Der Influential Writing Award (Preis für einflussreiches Schreiben) soll für das beste Tutorial, die beste Anleitung, den besten Blog oder Blogbeitrag vergeben werden. Ein Text oder eine Reihe an Texten, die neue Leute zu OSM bringen, einen interessanten Ausblick auf OSM bringen oder die Community dazu animieren, Sachen besser zu machen, sind gesucht.

BushmanK wird für seine nachdenklich-kritischen Benutzer-Blog-Einträge nominiert, in denen er sich Mapping-Themen widmet, z.B. der Benennung von Objekten und ob man gewisse Dinge überhaupt eintragen sollte.

Joost Schouppe wurde für die Einträge in seinen Benutzer-Blog zu den folgenden Themen nominiert: Interviews, Analyse lokaler Bearbeitungen, Statistiken, dem Effekt von Mapathons und Gedanken zur Nutzung bereitgestellter amtlicher Daten

Ramani Huria wurde für Blogeinträge zur Community und Mappingtechniken in Tansania nominiert.

Die Firma Carto'Cité wurde für ihre französischsprachigen Tutorials zur Nutzung von OSM-Daten in QGIS und uMap nominiert.

Arun Ganesh (PlaneMad) wurde für Einträge in seinem Benutzer-Blog über Statistiken, Renderingbeispiele und Kuriositäten (inkl. Vandalismus) in den OSM-Daten nominiert.

Meine Stimme geht an Joost Schouppe, weil seine Blogeinträge den Eindruck erwecken, dass sie sehr einiges an Rechereche im Vorfeld erfordert haben (Erstellung der Statistiken usw.). Meine zweite Stimme geht an BushmanK, da seine Beiträge ebenfalls einen aufrufenden Charakter haben. Gerade das ist für "einflussreich" erforderlich.

Fortsetzung in Teil 2

Weekend before last I spent several hours roaming Abadan and Gypjak, far western suburbs of Ashgabat, collecting street names, points of interest, and adding streets that didn't appear on the map (unplugging the SD card from the Garmin navigator forces it to collect tracks where you actually are, rather than trying to align them to the nearest street). Those towns, while not yet complete, are in much better shape in OSM now.

The research continued on names of monuments in traffic circles within the Ashgabat city limits. I count 22 monuments inside traffic circles and believe we now have names for all of them. If you are curious, enter "binasy, Ashgabat" or "monument, Ashgabat" in the OSM search box (without the quotation marks) and see what pops up.

Construction in Ashgabat is winding down as the Asian Indoor and Martial Arts Games approach. They start September 17 and the city is preparing.

test

This Friday, I will be at SOTM in Aizuwakamatsu, Fukushima this weekend talking about the state of validation on OpenStreetMap! I will talk about the need for making a validated error free map with OSM data, the recent efforts of the Mapbox Data team to review OSM changes and what the future of data validation might look like. If you are interested to attend the talk, grab a seat in the main hall at 4:10pm on Friday at the Aizuwakamatsu City Culture Center.

If you are interested in a deep-dive into validating edits in your area on OpenStreetMap, attend Validating the Map workshop conducted by manoharuss on Sunday at 1:30pm in Room-1.

Distribution of reviewed and validated changesets using OSMCha in 2017 | View Interactive Map