This was my first State of the Map. That is if you do not count my virtual visits to all previous ones via the video sessions I have seen afterwards.

In this diary entry I not write about the individual sessions, I keep that for another entry.

Let me start by congratulating the organisers and the volunteers for a great experience. Furthermore a big thank you to all people that did a presentation. I found the talks that I followed of a high level. That is they were informative, entertaining and brought by passionate people. Something I have not seen in other (non-OSM-related) conferences that I visited.

What I did wrong was that I visited too many sessions that are recorded and not enough bird of a feather (BoF) sessions. The ones that I visited (Public transport plugin for JOSM and Wikimedia's Kartotherian) were very interesting.

I was good to see people that I only met virtually before, either via a forum, a Mapper of the Month interview or as part of the Weekly OSM team.

BTW, a big applause to my colleagues of the Weekly OSM/Wochennotiz team for winning the Influential writer award. It's a pity that the SOTM team nor the OSMF team made more publicity about the winners of the awards. Because I was in a BoF at that time, i still don't know the other award winners.

Update: The are now listed on https://blog.openstreetmap.org/2016/09/26/we-have-our-winners/

I should also have been braver to talk to more people, but what do you say to famous people like Andy Allen or Frederik Ramm ? Anyhow, if I would have talked to you, I would have thanked you for your hard work for OSM and for the "courage" to continue with your work for carto-css or "promotion" for craftmappers despite all critiques.

As for the OpenStreetView team, I love to have discussed the de-blurring in the website. For what I do (mapping destination signs), it's a necessity and should take far less time than in Mapillary.

The social event had good food, but was missing beer. Not for me (I had to drive home), but an event in a former brewery with almost no choice in beer is strange, especially in Belgium. During the event, I had a nice talk with the woman that made the winning design for the SOTM logo and her partner, an American journalist.

I had a great time and feel sorry I missed the first day due to other obligations. And as Gregory sang at the end, we now will continue to "map, map, map".

Hi OSM community,

my name is Ivan Garcia and I am by the way looking for a python job(GIS, web, bigdata, etc) in case you are looking(just saying).

I helped many regions of the world to convert their official boundaries into OSM format and import them into OpenStreetMap following, of course, the OSM import guideline.

So I decided that since a lot of people are doing these conversions manually therefore wasting a lot of time, I created a python script that you can see and improve, it is called SHPtoOSMBoundaries.py

Normally, what OSM contributors have is a SHP file received from some official institution or downloaded through some OpenData portal, this example will show the user case of Fiji islands SHP file.

If we open the SHP it with QGIS, we see that it contains a lot of boundary polygons, and that each of the polygon contains a ID tag (in this case the TID) and another tag that identify the name of the deepest boundary(the tiniest), or in OSM, the one with the highest admin_level number. In our example this tag name is TIKINA(which corresponds to the village boundary in Fiji)

Also most of the times, from the same SHP we want to obtain the upper admin level boundaries, in this case we also have the PROVINCE ID (PID) and the tag name (PROVINCE).

So we know find out that:

• For the level 8(village) we have TID and TIKINA tags
• For the level 6(province) we have PID and PROVINCE tags

Before we can run the script, we need to create convert the polygons into lines, this is easily made with QGIS using the menu option Vector -> Geometry Tools -> Polygons to Lines

So the result looks like this, a lot of lines that overlapped one to another:

but OSM cannot have repeated ways inside the relation boundaries, so we will break this lines and make them unique.

Luckily, the GRASS plugin in QGIS provides us of a function named v.break:

Once generated the result breaked lines, we export as GEOJSON format to a filename "fiji_splitted.geojson" for example, also we will export the original SHP boundaries file into GEOJSON format, example to "fiji_level8.geojson".

Now is time to run the python(with python 2.7) script, you will need the python library "shapely", before we run it, we edit the script to change the needed parameters, that is:

• ALL_LEVELS_GEOJSON: filename that contains the original boundaries SHP file.
• SPLITTED_WAYS_GEOJSON: filename with the broken, splitted ways.
• DEEPER_LEVEL: level number and uniquetag and nametag that we discovered, in our case: DEEPER_LEVEL = {"level":"8", "uniquetag": "TID" ,"nametag":"TIKINA"}
• OTHER_LEVELS: a python list with the other upper levels that you want to extract also and mix together, in our case: OTHER_LEVELS = [{"level":"6", "uniquetag": "PID" ,"nametag":"PROVINCE"}]

Optional: There is an extra parameter called MAINTENANCE that you can set up to True to let the script to clean up the ways in case that the GRASS v.break did split the ways a bit too much, having too many ways into OSM. When the script is runned this way, it will create a "tofix_splittedways.osm" that can be loaded into JOSM to fix and join those little ways into a bigger one. Then make sure to save the fixed result as GEOJSON to the same filename of the splitted ways we had before, and change the MAINTENANCE to FALSE before reruning the script.

Running the script will create a "final.osm" output which is the file that we need to import into JOSM in order to upload into OpenStreetMap, preferably using the JOSM multiple-parts upload option. Of course, make sure to clean up whatever boundaries were in the area you want to upload, make sure you have permission by the source to do so with the OpenStreetMap license, etc.

Here is how the result looks like:

In you have doubts or errors, you can just write a comment here or add a issue into the github of the script.

I hope it helps saving lots of time to OSM contributors.

I’m Rukaia Parveen Tuba, student of Environmental Science And Disaster Management department (ESDM) of Daffodil International University. I’m an active volunteer of Bangladesh Red Crescent Society. I got a training there on OpenStreetMap by American Red Cross and BDRCS under their Data for Action Project. After receiving that training I thought how to spread the mapping knowledge among my friends. BDRCS took a decision to engage academia for making their program sustainable. Like few other selected universities, ESDM of Daffodil International University has showed their interest to host the training at their premises. The student of our department participated on that program held on 07-08 September 2016 at our premises. The training went successfully with full of learning about the map, uses and types of map, mapping technology for a greater good through crowd sourced mapping. Through the hands on session and heartiest effort given by honorable trainer Mr. Ahasanul Hoque all participant earned the confidence on themselves what they never knew capable of. All they are now a good mapper and promised to train more mappers in near future. We have opened a facebook group named OSM Club, DIU where all our mappers will be included and use the group as a forum for all the mapping activities, events, learning and support media. Today we had a mppathon and we have mapped for the affected region of USA by recent hurricane Newton. All of our new mappers liked the collaborative mapping and amazed to see the power and potentiality of openstreetmap for global humanitarian causes.

Proposta lanciata in mailing list it-lazio. Per ora stiamo pensando a martedì o mercoledì della prossima settimana.

se qualcuno è interessato e non legge la mailing list, commenti alla voce o messaggi personali sono ben accetti.

A presto!

Last week, as a part of improving the quality of road network data in Taiwan in OpenStreetMap and correct data misalignment issues in Taiwan, the Mapbox data team along with the Taiwan OpenStreetMap community has completed aligning major roads in 6 cities in Taiwan.

For this task, the team used updated Mapbox satellite imagery and Strava heat map for aligning the major highway network.

We have presently managed to align and improve more than 4000 kilometers of major highways in Taiwan in just 3 days by working alongside the Taiwan community. The 6 cities where the aligning effort is concentrated are: Taipei, New Taipei, Hsinchu, Taichung, Yilan and Tainan.

New updated Mapbox satellite imagery in Taipei

We have received a great response from the community on this task. They have been extremely helpful in resolving our queries and verifying edge cases and updated data from the ground in the mapping ticket. Taiwan OpenStreetMap community have also started validating our tasks as we have mapped.

While mapping we have come across situations of missing data and recent constructions which may not be reflected in the satellite imagery and are difficult to trace without local knowledge. It will be great to have the community continue validating our work on the ground and also help in adding any missing data in any area to improve the data quality in Taiwan. We also plan to continue aligning minor road network in the cities mentioned above once the validation of the major road alignment is completed.

We thank the community for all the support. We look forward to more interactions with the Asian community. Few of our team members will be present at SoTM Asia this week in Philippines, catch up with @manings, @srividya_c, @Chetan_Gowda, @nikhilprabhakar and me to talk more on this and the latest data team projects at Mapbox!

Thanks,

From Mapbox Data Team.

My user name is same as my real name: Pratik Yadav. But I find the stories of usernames (that are not their real name) very fascinating.

I met a few people in SOTM where they shared how their username relates to their hobby, interest and sometimes a hidden meaning.

If you have a username that has a story, post in comment.

:)

Od 17 września, czyli przez 8 dni, zrobiłem -sołectwo Rogów n. Odrą -sołectwo Bełsznica -sołectwo Bluszczów -sołectwo Odra -poprawki do sołectwa Uchylsko

As last year I participated at the 2. OSM Sommercamp at the Linux Hotel in Essen, Germany. Plan was to do some development for libosmscout.

The master plan for this year was already there, and as part of this I wanted to concentrate on caching of data in the MapPainter thus improving the performance of the render. Since a few days before I got some hints regarding possible performance problem in the label layouter I wanted to take a look at that first. Another topic was creation of simple HTML pages during the import process to dump all those findings about (possible) mapping errors that were detected during import.

Simple results first: The creating of HTML was already prepared before so at the SommerCamp the main task was to go through all the warnings and errors created during the import and convert them to the new API. At the end of the Sommercamp most stuff now was dumped to the HTML pages, too. A quick scan shows that for small imported regions most error occur because of some clipping problems, for larger region a fair amount of error are either due to libosmscout not knowing some types of objects or actual mapping problems. Next step would be some central server that builds libosmscout regularly and imports *.osm.pbf files people are interested in getting results for. While we do have central Travis and Appveyor builds the memory demand during import is likely too high to run imports there.

Next I improved MapTileCache so we now have a nice data structure that allows a renderer to use it for caching "things" (which could be handles, measurement result,...).

After that I took a look at the label layouter. In fact there was some O^2 algorithmic deficiency (how could that happen!?). Since I planed that anyway and to try to improve the API to the rest of the renderer I moved the layouting to its own class and at the same time removed the O^2 problem.

During testing I found some mysterious performance effect. While scrolling through the map, map rendering suddenly got much, much slower. After much analysing, dumping of ids, the cause was clear.

1. Libosmscout does some heavy work trying to merge ways in cases where they have the same attributes. Longer way mean, simpler routing graph, less data overhead.
2. On the other hand since some time libosmscout now does repetitive contour label rendering on ways (before that the contour labels was just rendered once on each way segment, independent of its length).
3. For detecting if a way should be rendered or not we use simple bounding box clipping.

Result: For the river Rhine for the nordrhein-westfalen import we generated a very long way (from Bonn up to the the german border in the north). The style sheet defines a contour labels for this. The effect bounding box for the river did go to the right up to Essen (where the Rhine is not visible, but because of the snake like meandering the bounding box still was there). So somewhere around Essen we started to render contour labels for the whole of the Rhine. Labels that were actually not visible on the resulting map. During the Sommercamp I fixed this by defining an upper limit on the way merging. Since the problem occurred after the Sommercamp again for some ferry line Lukas fixed this again with a more general approach by explicitly splitting ways again after merging.

Label rendering is now faster than before. Though we still need some geometric solution to further reduce the overhead.

Finally time was spend to eat some cake at the 12. birthday of OSM :-)

Se agregó la ubicación del cuerpo de bomberos de Placilla.

When I read Michal Migurski's recent post robots, crisis, and craft mappers, I was really baffled and concerned. I am a fan of Migurski; he's a good person and a smart guy. But the content of this particular blog post was really off. I had hoped it would pass with little notice, but I can tell from the #craftmapper T-shirts at SOTM that people actually paid attention, so sadly I feel compelled now to rebut, and hopefully offer some useful perspective as well.

To get something out of the way first, I am absolutely a "armchair" or "craft" mapper, and an addicted mapper, averaging ~5 hours a day mapping for the past 3.5 years; by my own estimation, there are only two human OSM accounts (katpatuka and Heinz_V) with more node/way contribution. (Also, shoutouts to AndrewBuck, Stalker61 and ulilu!) I care passionately about the map, I've been in geo since the 90s, and I've been inside Google to see how mapping actually happens at scale.

To start with, he writes:

The OpenStreetMap community is at a crossroads

Arguably, no it isn't. It is actually on a stable trajectory, with no major shifts likely.

I see three different movements within OpenStreetMap: mapping by robots, intensive crisis mapping in remote areas, and local craft mapping where technologists live

Actually, no. "Robot" mapping is a perennial project of AI zealots, not a movement, and cannot and will not produce acceptable data (for reasons way beyond the scope of this rant). At best, it is another way to produce yet more controversial imports of dubious quality. Crisis mapping is now well-established for many years, not a new or dynamic trend; same with local or remote "craft" mapping, i.e. normal OSM contributors; not a movement, and not new.

The first two represent an exciting future for OSM, while the third could doom it to irrelevance.

This is saying that normal OSM contributors, the ones that have and continue to build most of the map - and the great majority of the quality map - are "irrelevant". This is really, 100% wrong.

Historically, OpenStreetMap activity took place in and around the home areas of OSM project members

True enough, and that is still the single largest source of quality map contributions. The other parts are imports, a small amount of commercially-sponsored input, and armchair mappers like myself, tracing aerials from the places that can't (or can't yet) map themselves, either for HOT or MissingMaps or beyond. Together, that IS OSM, past and present, and unless Something Dramatic happens, that is also OSM's future.

Craft mapping remains the heart of the project, potentially due to a passive Foundation board who’ve let outdated behaviors go unexamined.

I am trying to figure out how to not feel hurt by this. "OUTDATED." The passion that drives the entire past, present and future of OSM is "outdated?"

Left to the craft wing, OSM will slide into weekend irrelevance within 5-10 years.

That's basically saying that OSM is irrelevant today. As an opinion, that's a pretty harsh one.

Two Modest Proposals (1) codes of conduct and other mechanisms intended to welcome new participants from under-represented communities

This sounds fine, but it seems orthogonal to the "robot, crisis, craft" framing. It seems uncontroversial to empower and support more crisis/craft mappers from under-represented communities.

(2) the license needs to be publicly and visibly explained and defended for the benefit of large-scale and robot participants

I have sat out the license wars, partly because, as a regular non-lawyer human, I cannot fathom what all the fuss is about. That said, it also seems unrelated to crisis/craft mappers, with or without AI-robot assistance to produce data for human review, who will surely be able to proceed with or without license changes.

I could say much more about this, but much has already been hashed out of the comment thread on the original blog. For example, "automation vs. craft is a strawman argument; Both - in an integrated manner!" yes obviously.

Instead, I'd like to provide an answer the question I believe Migurski is actually asking. I believe he is saying:

1. While better in some areas, OSM isn't on par, for the full range of uses, with maps from Google/Apple/etc.
2. The existing approaches aren't on a trajectory to get us there, therefore they "doom us to irrelevance".
3. We need something more to get us there, but what is it (robots? codes of conduct? license changes?)

The answer to this question is obvious, but everyone seems to be waffling and dodging it. I will say it: MONEY.

To be a top-tier global map, it takes roomfuls of full-time, paid mappers, with the kind of resources and coordination that (realistically) are only found in large corporations.

1. Clickshops. Google has them, Apple has them, any organization that wants to take OSM to the "next level" will need them. In some developing nation (for cost), with fast computers and fast networks and thorough, regularized training for speed and consistency. (In case someone is thinking Mapbox, that's nice, but think bigger. Think 100x.)

2. Streetview. Every station in Google's clickshops has the entire catalog of streetview instantly available, continuously integrated into the mapping flow. Without a streetview-like dataset, you just can't do it. I know Mapillary (+JOSM plugin) is trying, but they are not even close - you have to capture FULL 360 (cylindrical) imagery, not just hope that hobbyists were pointing their camera where you need to to look, and you need the RESOLUTION to read street names. Not even 1% of mapillary users are capturing HD 360 imagery. You can't do it with prosumer cameras (I've tried). You need an expensive rig. Stop pretending otherwise.

Some company or consortium (or, in theory, government, but I'm not holding my breath) could step forward with MONEY and take OSM to that "level III/IV" Migurski (and many others) would like to see. Barring that, everyone needs to extend love to the homebrew/crisis/craft/mapathon mappers we have, because we ARE OSM's future.

Hello everybody. In recent days, I added some improvements for Lima (Peru). After the first update, now enlisted more contributions to revise and preserve the city for the next months.

• Updating Via Parque Rimac and Costanera highways. The inaguration is in 2017-2018.
• Retouches in the historic center of Lima and some neighborhoods as Barrios Altos and Rimac
• (Interval) streets in La Punta and the historic center
• More improvements in Campo de Marte and Paseo de las Aguas
• Construction of second part of the Callao's airport and new underground highway
• Sidewalks in the parks
• Added Mercado Unicachi, rural market, and some tweaks in Comas district
• Added a fort in Rimac district (see La Muralla) and orientation maps in urban parks
• Added Sea sport track (I don't know the real name) in south of Lima for the 2019 Pan American Games.
• More shops in Mega Plaza (like Plaza Norte).
• Structuring Pachacutec to differentiate with Santa Rosa and Punte Piedra locations.
• Added Ciudad Satélite Santa Rosa (residential city) near the airport
• Retouching in Pachacámac (Lurin)
• Building Design National Stadium

Comming...

• Buildings in Gamarra shopping center (completed)
• Streets with vector lines (San Isidro?)
• More schools to help in the upcoming elections (maybe, the presidential and rural in 2020)
• Remove "alpine hut" and replace with other objects
• Traffic lights strategically located in the streets
• Find out if some local work, especially in areas prone to landslides or similar

It is possible that visual applications like Maps.me or Osmand finish saying as "updated map" so this list serves very useful for both experienced and novice in OpenStreetMap. Any contribution is welcome comments. Greetings.

This was translated from the original post

It took more than 6 months to reach my personal target (map a boundary set by various roads, culminating at the ancient – although now mostly gently rotting – centre of Carlton). Now, I do admit that I've still got to complete a bit of the extreme west end of this mapping (Porchester Gardens), but the greatest extent has been done. In the light of that, perhaps I can indulge myself a little.

Close by the junction of Burton Road and Cavendish Drive is the Army Reserve Centre (‘ARC’) of the Sherwood Rangers Yeomanry. They are a cavalry unit, and this is not a bad picture of one of their vehicles:

Useful for shifting the worst of the traffic jams, I would have thought.

Proposal procedure is not something required to introduce a new tagging scheme, however, some people are brave enough to start it for tags they want to introduce. But then, they are not obligated to follow this procedure, not only in form of being able to abandon a proposal (which is normal - you don't have to finish it if you don't want to) but also in form of disregarding the RFC stage.

RFC stands for Request for Comments. Supposedly, it serves to collect feedback and to correct errors found by reviewers. But currently, proposal author is not obligated to take any feedback into account, even in a simple form of replies on a Talk: page (leave aside actual addressing the issues, mentioned there). Since voters are not always reading Talk: page, they could be unaware of those open issues and cast their votes regardless of that. This makes an RFC stage (and the whole proposal procedure) nothing more than a formality.

My view on it is that voting stage should never be started (allowed to start) without addressing every issue submitted by proposal reviewers. Otherwise, no improvement of proposed scheme is possible if an author is lazy enough.

I wrote in June 2016 about CCTV cameras on Carlton Hill top, but it seems that in Carlton centre they take their Neighbourhood Watch even more seriously:

Опубликован ЕженедельникОСМ 321 - краткие новости о происходящем в мире ОСМ, можно прочитать на русском языке на сайте.

Замечания по переводу оставляйте в комментариях, исправьте в вики, напишите на форуме, сообщите в телеграмм

Hola a todos, he proseguido con el mapeo de algunos pueblos de las periferias de la ciudad de Arequipa, especialmente entre los distritos de Chiguata y Pocsi, donde he seguido agregando caminos (sin clasificación porque no puedo determinar si son transitables por autos aparte de personas), haciendo correcciones y otros. En resumen lo avanzado:

• Agregadas algunas más rutas entre los poblados de Piaca, Tuctumpaya, Mosopuquito, en los distritos de Chiguata, Characato y Pocsi.
• Agregado más detalle al trazo de la vía PE-118 que va hacia Puquina (Moguegua), entre los distritos de Pocsi y Polobaya, en algunas zonas especialmente aquellas donde hay conexiones con otras vías menores.
• Agregado la represa de San José de Uzuña, distrito de Polobaya, y el flujo de agua correspondiente que sale del mismo y se conecta con el flujo que ya se hallaba previamente mapeado río abajo (entre Polobaya y Quequeña).
• Se agregaron más rutas aledañas al poblado de Polobaya.

Revisando otros alrededores de Arequipa he detectado la falta del mapeo de rutas entre los distritos de Huanca y Lluta, especialmente la vías que se dirigen hacia el nevado Ampato. He agregado algunas rutas y planeo seguir agregando mientras reviso la zona.

never send to know for whom the bell tolls;
it tolls for thee.

Devotions Upon Emergent Occasions, "Meditation XVII"
John Donne
(written in 1624 whilst Dean of St. Paul’s, following a potentially fatal bout of spotted fever)

A young chap that lives in West View Road, Carlton (a private, unadopted road) explained during my latest mapping session that his house is subject to Chancel Repair Liability. The object in the middling distance below is responsible for that (it is called ‘Gedling Church’):

The Carlton householder explained Chancel Tax as applying to those that “can hear the Church bells”. The full story (Wikipedia) is less romantic and much more complex, but the statement is accurate enough in it’s way. It is a uniquely English & Welsh story, involving medieval (pre-1536) church history, Henry VIII & rich men’s responsibilities that have come to haunt modern land-owners (those that own their own house).

The ‘Chancel’ is the liturgical heart of an Anglican Church (normally at the east end, and so on). Chancel Tax originates hundreds of years ago as the responsibility of land-owners to pay for the upkeep of a church (normally their parish church). Getting from those medieval times to now involves a fabulously tortured path, and the consequences can be likewise.

This all came to a head for Adrian and Gail Wallbank in 2009 when they were forced to sell their home. A couple of decades earlier they out-of-the-blue had received a bill upon their doormat for £100,000 GBP of Chancel Tax (the same value at that time as their home) and had decided to fight it through the courts. It took 18 years for them to lose their case; they then had to find an additional £250,000 GBP for legal costs (£350,000 GBP total; $454,000 USD, €408,000 Euro currently).

This is a curious connection to my earlier Diary entry on Ecclesiastical Parishes. Wikipedia states that there are ~15,000 such parishes, of which 5,200 are responsible for chancel repair. Of those, only a minority have exercised their right to deploy this Tax if required. A 2014 House of Lords bill, if enacted, will finally remove all such rights to do so.

Most interesting (unless your home is threatened by it).

At the Python Unconference in Hamburg, we released the new OSMAlchemy library, which allows for the simple creation of arbitrary, OSM-data based applications with a low resource footprint in Python. It wraps around the popular SQLAlchemy database library and allows access to the whole world of OSM data as if it were in a local SQL database, and uses such a local database for caching.

See the GitHub repo for the code and a README, and find the original presentation from the release talk.

You can write to osmalchemy@veripeditus.org if you have questions or comments, or use the GitHub issue tracker.

I'll be at State of the Map in Brussels this week presenting all of our work on validating OpenStreetMap data. At Mapbox, we spent the last few months looking at changes that happen in OpenStreetMap closely - geometry, tags, users and the community. I'm really excited to share what we learned, and to open the conversation on how the community can focus on keeping the map from breaking while growing. I'll be presenting the tools we have been building, insights about problematic changes, response, mechanics of communication and more during my talk.

Our team just published an approach to validating OpenStreetMap data - talking about identifying problematic changes, inspecting them, communicating and eventually fixing. Let me know what you think!

What makes OpenStreetMap special is the community. The community is what makes OpenStreetMap a truly self-healing map. The community is the map.

Map of recently reverted changesets

If you haven't already, watch Sanjay Bhangar's presentation at State of the Map US.

Looking forward!

I was meaning to say (and left it a bit late) it is a great honour to be nominated for the OpenStreetMap awards.

I have realised recently, with some embarrassment, that despite trying to contribute in many different areas, my greatest contribution to OpenStreetMap has almost certainly been my diary entries about people sitting around in pubs! :-)

I think my pub diaries date back to 2008 some time. I started writing them as a way to promote our London meet-ups and also to try to inspire others to run similar events worldwide. Hopefully it succeeded in that aim to some extent. But it also developed into a sort of newsletter with a mixture of sometimes current, sometimes just random, topics in and around OpenStreetMap, mixed with some of my own half-baked opinions and opinions of others around the pub table ...if I agreed with them ;-)

It turned into quite a habit, which I felt I should keep going. I even became quite organised, by actually writing notes in the pub. I adopted a sort of stream-of-conciousness writing style. Nothing too polished. I think this helped make it a bit less effort, but even so, it added up to quite a lot of effort over the years. It's nice to have this recognition of my primary OpenStreetMap talent: writing about people in pubs!

I think that Zverik has done a great job putting together these awards. It's an idea I've pondered in the past, but never got off my ass to do. I hope they're considered successful, and become a regular annual fixture to recognise more people within our community. Hopefully it will motivate people. Hopefully it won't make people feel resentment. Probably it won't do either of those things all that much, but...

I think it feeds nicely into another positive effect. Thinking about OpenStreetMap "storytelling", things like this create a "human interest story" where previously we may have missed it. Take the "core systems" category for instance. We spend a lot of time talking about technologies like Nominatim, iD, osm-carto, OverpassAPI, etc, but if we can find a way to spend more time talking about Sarah Hoffman, Bryan Housel, Mateusz Konieczny, Roland Olbricht, Grant Slater and Tom Hughes, this not only gives them some much-deserved kudos, but it makes the story more interesting somehow. In our open community we miss out a bit on this by being so egalitarian, altruistic, and just plain over-modest all the time!

Other fantastic efforts which create a human interest story include the Belgian community's "Mapper of the month interviews", and the OpenCageData interviews. I'm a huge fan of those. Again, it's a thing I pondered about doing but never got off my ass and did it. I think we need to weave a bit of this good stuff into the blog.openstreetamp.org somehow.

In fact thinking about doing things on blog.openstreetmap.org (and generally not doing them) has put me in a state of analysis paralysis lately. My stream-of-conciousness diary entries dried up, and so I'm also rather embarrassed to be nominated for an award for a thing which I've stopped doing!

Of course I also have a new and exciting time sink these days, but I am allowed a few days off from nappy changing to head to State Of The Map Brussels (arriving tonight). I'm looking forward to this immensely. Maybe I'll get into some interesting conversations with belgian beer! If you like my diary entries, maybe I'll write up some of these conversations. There we go... it's motivating people already!