The OSM QA Tiles project, hosted by Mapbox, generates vector tiles from OSM data.

Owing to some recent changes in our architecture, the paths from where to retrieve QA tiles have changed. Any file that was earlier found at the path https://s3.amazonaws.com/mapbox/osm-qa-tiles/*, can now be found at https://s3.amazonaws.com/mapbox/osm-qa-tiles-production/*. If you are using QA tiles generated by Mapbox, please update your code to receive the latest updates.

Fortunately I am typically editing area that is not a victim of landuse imports.

Unfortunately today I am trying to fix area affected by at least two landuse imports

As bonus, one is using mysterious undocumented CLC:code, CLC:shapeId tags that are not documented anywhere and it is not clear what one should do with them on modifying and merging areas with them.

Is there anywhere at least one large-scale import of landuse data that was done properly?

Our Zen Center hold a regular outreach progam for kids called Bodhi Star. Along with teaching basic mindfulness techniques, life-skill ideas and concepts are also taught or introduced.

Yesterday, it was my turn to teach skills class and I've always been keen on teaching something related to maps and geography.

The kids had great fun trying to identify objects from aerial imagery, "visiting" remote places, and wonder about the beauty of our vast, interconnected world.

Some of the places we visited had limited street-level imagery, which they were quite fond of, so I even got to discuss Mapillary with some of them - who wanted to capture images of their neighborhood. There are plenty of caveats, of course, and there are parents around to keep them grounded.

I should seriously plan for a Mapillary field-trip idea for kids.

Such entertaining steps to create a wiki account to fix errors on the OpenID entry.

cannot find a confirmation code to save

good job SECURING ERRORS

---English Version---

Early September we were facing some of the strongest hurricanes in the Caribbean ocean over the past decades, the humanitarian mapping team HOTOSM was already collaborating full speed to help creating maps in the areas were data was limited or nonexistent. Suddenly the Southern states of Mexico were hit by the first earthquake, Oaxaca and Chiapas are well know for being states with a large marginalized population, in the OpenStreetMap community we have been discussing in the past the need of creating detailed maps for these states among others who lack of this data. Volunteers in the Mexico community requested help to HOTOSM to create tasks to map valuable data for buildings and roads in the towns where help was needed the most. One of the cities more affected was Juchitan

At that time we started a telegram group name #TerremotoMexicoMapping in the one volunteers from the OSMMX community and students who had participated in workshops in the University of the State of Mexico started collaborating creating Geojson files and mapping villages of Oaxaca and Chiapas, at that time we were no more than eleven people in the group. By September 15th there were mapped 984,312 objects in Juchitán, Ixtepec, Matias Romero, San Mateo del Mar, Pijijiapan, Tonalá, among others localities (find the complete list in http://bit.ly/MXEarthquakeMapping this crowsourced geographical Open Data was available in real time in the largest geographical Open Data Base in the world, OpenStreetMap, as soon you click “save changeset” the data is available for everyone to use.

Mapping Oaxaca and Chiapas after 8.1M Earthquake

People with experience in earthquake response mapping such as Daniel Orellana from the #MappingEcuador community and the friends of Kathmandú Living Labs (KLL) were happy to share their best practices and communicate what it worked for them and make sure we don’t lose precious time. The Quakeinfo.org tool showed by KLL was something already Leo Castañeda was preparing by the knowledge gained in mapping Repubikla traffic incidents and was going to be the base for mapa.sismomexico.org

Without having a break the second earthquake surprised us affecting Mexico City, Morelos, Puebla, State of Mexico and Guerrero, more tasks were added to the Wiki we were overwhelmed by the amount of damage we were facing and needed to be mapped but at the same time the second earthquake make people who didn’t react on the September 7th earthquake wanted to participate in anything possible. More mapping tasks were created by digital volunteers from HOTOSM and we asked in a twitter for people who had experience in Visualization and Data Analysis to join our Telegram group, from 11 people in just a few days the group had more than 150 people interested in creating maps and doing data analysis. One of the hardest tasks was to map the affected areas of Mexico City due to the high building density, if Mexico City had an Open Cadastre more digital volunteers could help to analyze the data in the CDMX’s benefit, unfortunately the data has restricted access and it is reserved for opening until year 2023! (but this is a topic for another blog).

On September 20th mapa.sismomexico.org was launched, at the beginning it was thought to be a tool to add reports and also add/gather open databases created by other sources but we realized we had a weakness, we didn’t have enough people to check/validate the reports so from a tool to create reports we decided to consolidate the sources in one single map and make easier the download process to make accessible the data generated so relief organizations or citizens could take benefit of the databases. The amazing team of Verificado19S was doing an incredible job validating the data with their army of volunteers so when people wanted to add something to our map we would give the details of Gaby Marquez from HorizontalMX and avoid a double collection of the valuable data.

All the actions could have not been possible without the commitment of individuals and institutions that believe in the potential of the OpenStreetMap project, such as:

• Humanitarian OpenStreetMap Team- HOTOSM who supported the activations since the first moment.
• OpenStreetMap Colombia Foundation in the one Freddy Rivera helped coordinated the Disaster Charter from United Nations activation in the one the UAEMX and UNAM are having their experts helping to analyze images post disaster and this way identify damage buildings through satellite images donations.
• Kevin Bullock and team from Digital Globe who released PRE and POST disaster images to help with the mapping of the affected areas.
• Estrategia Digital Nacional who supported the imagery donations requests needed by UNITAR and Digital Globe. OpenAerialMap who process the satellite images to make them accessible.
• Codeando Mexico that gave us the support to host and deploy mapa.sismomexico.org.
• Escuela de Datos for sharing and promoting the mapping.
• Pierre Béland always supporting with his expertise and statistics tools.
• Mapathons all around the globe took place to help mapping and validation of the humanitarian tasks:
  • Cartong in Paris. *CARTO in NYC.
  • Students from University of Miami.
  • GeoInquietos from the Universidad Politécnica de Valencia.
  • Mapbox.
  • Telenav.
  • Accenture Colombia.

• Street level solutions such as Mapillary who coordinated volunteers to create images of damaged buildings in Mexico City, Morelos and Chiapas and OpenStreetCam who took tracks of Juchitán and Ixtepec to document the damage in the area.

• From Openstreetmap-México team, Juan Manuel Vázquez, Ricardo Pérez, Ruben Fernandez, Leonel Castaneda, Edgar Lemus, Cuauhtémoc Gutierrez, Miriam Gonzalez and Céline Jacquin have participated actively in coordination, diffusion, projects construction, mapping and validation, capacity building and orientation to new mappers

And specially thanks to the 1400+ volunteers who added a home, a road or a shelter to the map, every edition make the difference to achieve over 250,000 buildings and almost 25,000 kilometers of roads since September 7th 2017.

Thanks to all the digital support, now we have Open and free data available for everybody to use, it doesn’t matter if you are a Volunteer, Student, Government, University, Geek, Data enthusiastic, everybody can take advantage of the open data created.

Thanks again!

Collaborators of the OpenStreetMap Mexico team

But now…what is next? Click here to find out

NSDI Field Data Collection workshop

NSDI Sri Lanka is conducting five workshops for government field officers representing Agrarian Services Department, Land Use Policy Planning Department, Archeology Department and Local Authorities. All five workshops are conducted as two day sessions.

In this training participants have been trained on basic concepts of Spatial Data, GIS and some open source data collection tools. First day training is on theories and some applications. Second day training is on how to use OSM for field data collection and management.

https://www.facebook.com/permalink.php?story_fbid=1347594545368784&id=1132399976888243

In Attendance:

• SF Sarah
• Neocobalt
• Minh Nguyen
• Luke W
• 3vivekb
• Nick
• Betsy

Project Selection:

As a group moving forward we all agreed to continue to support and finish San Jose sidewalks import but if a Santa Rosa fire mapping project spun up we would all shift focus, at least temporarily.

Minutes:

We discussed some reverting issues from the National Day of Civic Hacking.

3vivekb went into detail about how he set up the sidewalks import and processed the data and all the help Minh Nguyen provided.

We talked about keyboard shortcuts in JOSM (6 to zoom in on issues, hitting M to merge points) to speed up the sidewalks project.

Minh talked about phone books and coverage % as well as about the coming SOTMUS conference.

For full meeting details, read here - https://www.freelists.org/post/ilugc/ILUGC-monthly-meet-Saturday-14-Oct-2017

Indian Linux Users Group, Chennai [ ILUGC ] October Meet - 14 Oct 2017

Venue: Classroom No 1, Aerospace Engineering, Near Gajendra Circle, IIT Madras. Link for the Map: http://bit.ly/iitm-aero

Time : OCt 14, 2017 3.00 - 6.00 PM

Talk - 2

Mini workshop using a TelegramBOT to translate strings for OpenStreetMaps.org

We are dreaming about Maps in Tamil, for long time.

Imagine your mobile phone or GPS device, shows the maps in Tamil, displays the roads, interesting places in Tamil, It shows routes and says the street names and directions in Tamil while driving.

The dream can come into real as we have most of the required technologies. OpenStreetMaps to provide maps, many apps like streetcomplete, osmcontribute to add streetname and interesting places, Tamil TTS to say everything in tamil.

The major thing we need is we need all the strings in Tamil. OSM supports language tags and we can give any string in any language, along with its translation on other languages.

To enable the translation process of existing strings in OSM, we are working on a telegram bot. Now, it is easy to contribute to OSM via translation, with mobile or with web browser.

The bot will be released for public tomorrow with its source code.

It will ask for your osm username, and then for translate or verify. The strings will be translated by google translator as first step. That is not perfect fully. so, we need people to verify it,

You can see a string with its translation. Then say it right or wrong. once three people confirmed a string it as right, it will be confirmed. The incorrect strings will be displayed for translation.

Once the strings are completed, they will be uploaded to OSM using a bot account.

Will release the bot tomorrow.

Come with

• your smartphone.
• Install Indic Keyboard or Sellinam for Tamil Typing.
• Register at openstreetmaps.org

Let us have a translation workshop for openstreetmaps.org

Thanks for the team.

• Dinesh Karthik - dineshkarthik.r@gmail.com
• Srikanth Logic - srik.lak@gmail.com
• Syed Khaleel Jageer - jskcse4@gmail.com
• Shrinivasan - tshrinivasan@gmail.com

Duration - one hour

More accurate informations for the city of Shkodra:

• buildings: validation, number, level, update (new/old object)
• highways (more accurate) improvement, names, categories, speed limit, validation, update (new/old object)
• bicycle line (update)
• parking area (update)
• update tourism category (hotels, hostels, guesthouses, camping, attractions, hiking/biking routes around Shkodra)
• update the POI's (new entries)

More accurate information for "North Albania" (touristic villages like Theth, Valbona, Curraj Epërm, Lëpushë, Vermosh, Bogë, Vukël, Nikç, Tamare, Razëm, Prekal, Shala River, Mazrek, Drisht, Velipojë, Shirokë, Zogaj, Rrjoll, Zadrimë area, Ana e Malit area, around Gashi River):

• new/update hiking/biking routes (more accurate type of hiking routes T1-T5)
• new/update guesthouses
• attractions

From time to time I participate in the voting of tagging proposals. Even if I lack the necessary knowledge in the field the proposal is about (e.g. I have limited knowledge about electricity or fire hydrants), I check a few things before I cast my vote. (The following is my personal opinion)

Avoid changing heavily used tags

A proposal should always avoid to change existing tags which are used a lot. There are some reasons for a change of the tagging but they are rare. Changing American English to British English just to have British English is one example if there is no other benefit. Changing from or to namespaced keys/values is another.

If the only reason is to have nicer keys/values, this will just lead to an unnecessary workload for multiple parties. Mappers who attempt to do mechanical edits, other users who revert them, the Data Working Group who has to mediate disputes (or has to revert the changes if it has not been done already), and last but not least data consumers who have to change their software. You might think "Data consumers, don't be angry, you have just change a string (and add an AND to your code)" but you should keep in mind that more and more data users order pre-installed servers/services from companies in the OSM ecosystem. Their services get automatic data updates because they want or need data being up to date but they will miss more and more features. And all this just happens because someone thought that an l is missing in jewellry (I am not sure if that was a joke or test).

If a proposal tries to change a heavily used tag, I think that it has to address why this change is really necessary and that the "cost" of the change are lower than the benefits. Mentioning this only in one or two sentences will lead to a failure of this test (except very long sentences). If a proposal fails this check, I will say NO although other parts might be good.

Well formed keys and values

If check number 1 is passed, I will check if the new tags and values are well-formed. Keys must only contain lower-case characters, underscores and, if really necessary, numbers. Colons are namespace delimiters. You must have really good reasons that I accept upper case characters. Spaces and other characters are a no go.

The same applies for values. Only free-text values may have any content.

Boolean values must be no or yes.

This check must be passed, too. A failure results in a No vote.

Good tag design

Good tag design is more difficult. It is a good idea to put special interest tags into a namespace but on the other hand namespaced keys exclude mappers who don't think they are qualified to edit them.

Namespaced keys have the advantage of avoiding conflicts with other keys which could be tagged on the object. On the other hand, namespaces add some kind of noise to the raw tag list.

Using keys to tag properties of the new feature B which are already in use for feature A is not a good idea if an OSM object could be both A and B but the value of the key should be different.

Example: A pole of a power line (power=minor_line) has a reference number ref=34. A proposal wants to add a tag to map transformators on poles. Both should share one node in OSM. Adding the reference number of the transformator as ref=T5 is not possible because this would overwrite the reference number of the pole. Adding a special tag for reference numbers of transformators mounted on poles is one solution. The other one is to map two nodes. Both have advantages and disadvantages.

This example shows that there is not always a clear answer what good tag design is and therefore serious problems have to persist after the discussion to make the proposal fail this test.

Observable

A tagging proposal should only suggest tags which are observable on the ground. For example, a proposal which contains a tag for the maximum amperage a electrical locomotive may consume from the catenary, might fail this test if the author could not point me to a region where it can be observed on the ground (in Germany you cannot observe it).

If a property or feature can be observed only on some objects, this will not cause a failure of this test.

Stable

Tagged values have to be stable. If values changes multiple times per year (or even every year), maintenance is difficult or impossible. If the value changes too often, the property does not fit into OSM at all.

This is a soft fail test, too. If the properties of some instances could be stable but other are not, it might not lead to a No vote.

Privacy

Tagging proposals which invite mappers to add information which infringes privacy and/or will lead the project into legal trouble in regard with data protection (in Europe) could fail this test. It depends on how much tagging without infringing privacy is possible (see "Stable" and "Observable").

For example, a proposal with a tag for the owner of a house will clearly fail this test.

Structure

This is a soft test. Readers of a proposal should understand quickly what the proposal wants to change, what it introduces and what is just mentioned as context to understand the proposal. Guides which summarize various tagging schemes fail it easily because proposal are not guides but change requests. If a guide covers a disputed topic, it is a good idea for its author to write that it is disputed, what the parties arguments are and leave the decision to the reader.

Split up your proposal into a section of simple and advanced tagging if your proposal is very long and goes deep into a topic of a special interest. People starting adding the simple features and properties might later use the advanced tagging. But if you only offer a steep ladder, less people might climb it up.

Summary

As you have seen, I am very strict because there is no difference between a YES and a partial YES. But you, as a proposal author, could circumvent this problem partially. If you split up your proposal in two or more parts, the parts which don't fail these test, will pass.

If you want to learn more about how to write good proposals, I suggest you to read the discussions and voting section of rejected proposals.

What do you check if you read a proposal before you cast your vote? Or does your wiki user page already include the UserAgainstTagVoting or No_Wiki_Fiddlers template?

Recently we released the new version of OSMCha, an application to help the OpenStreetMap community to review the changesets in the map. In this new version, the frontend was rewritten, we changed the backend to serve the data as a REST API and we have added some new interesting features. Let’s talk about some of the new possibilities that came in with these changes.

The REST API allowed us to build a faster and more efficient frontend and it opened up avenues for other applications being able to use OSMCha data. Yes, It’s now possible to build a JOSM plugin to update the status of a changeset or a feature in OSM. The API documentation to make this happen can be found here → https://osmcha.mapbox.com/api-docs/

The main API endpoint is the /api/v1/changesets/ as it allows us to get changesets. It accepts many filters and one ordering parameters. We also have some sub-urls, like /api/v1/changesets/checked/, /api/v1/changesets/unchecked/, /api/v1/changesets/suspect/, etc. That makes it easy to filter the changesets by some boolean fields and accepts filters parameters too.

Filters & Areas of Interest (AoI)

The new version of OSMCha comes with many additional options of fields to filter changesets that weren’t present in the previous version. Almost all filter options are available in the frontend, but you can also check the API docs to verify if you can benefit from some special API capability. One resource that is not still unavailable in the frontend is the possibility to filter changesets by using any geometry type you want, not just limiting to a bbox.

Furthermore, now you can set a filter query and save it as an Area of Interest (AoI), that way you won’t need to set the query parameters again, all you need is to access your AoI URL. Each AoI also has a GeoRSS feed that you can use to be notified for the new edits. You can also easily share your AoIs with other users by sending them the URL.

To save an Area of Interest, make a POST request to its endpoint with the name you want to give to your AoI and the filter parameters, which are the same that we use to query the changesets. The API also supports saving an Area of Interest with any geometry type you want.

Statistics

Do you need stats about an AoI, a user or about a changeset query? We provide it with some endpoints: /api/v1/stats/ gives us stats about the changesets (total number, quantity of harmful, checked and quantity by suspicion reason and by tag). This endpoints supports the filter params. We have the same stats to an Area of interest in /api/v1/aoi/{id}/stats/ and finally the stats of a user in /api/v1/user-stats/{uid}/.

Protection rules and documentation

The API has a throttling mechanism that limits the number of requests by user by minute to avoid our database of being misused. There are some endpoints, like the ones that add and remove suspicion reasons, that were made to help with administrative issues like fix a wrong detection and whose access is restricted to the admin users.

So checkout the documentation and use OSMCha to monitor your areas of edits! If you have some suggestion, feedback or ideas, post a comment or open an issue in github. It will be great to have new insights from the OSM community!

• API documentation: https://osmcha.mapbox.com/api-docs/
• API/Backend repository: https://github.com/willemarcel/osmcha-django
• Frontend documentation: https://osmcha.mapbox.com/about
• Frontend repository: https://github.com/mapbox/osmcha-frontend/

As always, the local OSM community in the Philippines is keen in finding ways to engage, and expand the community of OpenStreetMap contributors in the country. Many mapa-thons and hacking events are fueled by passion, and pizza. You can help drive the passion, and we'll take care of the pizza.

We just launched a new program: the OSM PH-izza Challenge that offers to send free ph-izza for mapathon events in every possible part of the country - especially those outside Metro Manila. If the mapathon proposal is selected, the PH-izza is on us!

We're hoping to select at least one event every month - and we'd like to hear your proposal!

If your group or club would like to send your proposals, please fill-in this application form so we can evaluate your them: https://goo.gl/forms/si06mto1fOkeY3652

P.S. We would also be very happy to hear from pizza-hearted sponsors who would like to help us expand this program!

If you have been a daily user of OSMCha, you have already started using the new version. Wille has been working with Mapbox on new developments of OSMCha. We have been testing the stack stability, and collecting feedback from Mapbox data team and community members for few months now.

I would like to use this diary post to introduce few features in the new version of OSMCha and talk about ways we can use them for validation.

Introduction

The development challenge has been to make OSMCha easier to use, faster to review changesets, and a robust tool for filtering OSM edits. We needed to add contextual information on mappers & changesets, improve the user-friendly UI, add keyboard shortcuts, and a lot more using an API driven frontend.

Along with a brand new design, a lot of things have been improved in the new version. Here are some of the new features.

Sidebar

The sidebar is similar to how the History tab on OpenStreetMap shows a list of changesets. The sidebar on OSMCha also gives a count of changesets in the search, and supports keyboard shortcuts to move through the list.

Filters

Many filters correspond to the metadata associated in changesets. To help make this clear, we now have descriptions for each filter that briefly explain what a certain filter does in the search.

Saving personal filters - Area of interest

One key request from OSMCha community users has been ability to save a set of filters for easy sharing, and reuse. This is now possible! You can save a filter with a custom name and share the url with the folks you work with or find it in your profile for future use and reference.

For example: Here is a filter that lets me see all changesets in New York https://osmcha.mapbox.com/filters?aoi=095e8b31-b3cb-4b36-a106-02826fb6a109

GeoRSS feed

If you would like to be notified when a new changeset comes into your personalized filter, we now have GeoRSS feed that can do that for you. Here is an example changeset feed link for the New-york filter I have made above

https://osmcha.mapbox.com/api/v1/aoi/095e8b31-b3cb-4b36-a106-02826fb6a109/changesets/feed/

Open a list of changesets by ids

If you need to open a list of changesets by id (for example, returned from Overpass), OSMCha now supports filtering by comma seperated changeset ids.

Size bound BBOX search

The bbox search works by retrieving all changesets whose bboxes have an intersection with the bbox we give. A problem with this method is that global scale changesets can overlap the local search area. This problem has been wonderfully explained here by Athalis. One way to solve this problem is to have a bbox size bound search.

Bbox size bound search limits the retrieval of worldwide edits by taking a multiple from the user that essentially limits the max bbox size in the search. Example: 2 only shows changesets whose bboxes are at maximum twice the size of bbox we have provided.

Keyboard Shortcuts

Keyboard shortcuts enrich user experience. In the new version of OSMCha, we have keyboard shortcuts that allow us to sift through panels, sidebar changeset list and even verify a changeset. Read more about keyboard in the about page for OSMCha https://osmcha.mapbox.com/about#are-there-keyboard-shortcuts-in-osmcha.

Tag the changesets

Another new feature is the possibility to tag the changesets. This way we can add a little more information about the changesets, besides saying that it’s good or bad. We have some tags to evaluate the severity degree, if the errors were resolved or not and if they were intentional.

It is important for us to review changesets we are reviewing as good or bad, as it indicates other community members that they need not spend time on that particular changeset.

Feedback

If you have ideas or suggestions on OSMCha, please feel free open an issue in one of the below repositories.

OSMCha frontend - https://github.com/mapbox/osmcha-frontend/

Backend API repo - https://github.com/willemarcel/osmcha-django

Find all the necessary documentation related to the API here:

API docs - https://osmcha.mapbox.com/api-docs/

We are delighted to introduce the new version. This was a collaborative work and we hope you like it just as much as we do.

Happy reviewing!

Talking of the OSM Contributors, we often see the Big Numbers. In this Diary, my objective is to focus on the OSM Contributor profiles, to try to measure the impact of various groups on the OSM Edit Contributions.

Since 2005, there has been an explosive growth of new OSM Registered members from 500,000 in 2012 to 1 million in 2013 and 4.2 millions at the end of september 2017.

Pascal Neis and Alexander Zipf study in 2012 showed that only 38% of the registered members at the end of 2011 had started editing the database and that only 5% (24,000) of all members actively contributed to the project in a more productive way.

Activityworkshop.ne published in july 2013 an interesting analysis of contributors «Joining and leaving» as participants. It shows the volatily of OSM contributors with a high volume of contributors starting and stopping contribution shortly after. As we will see below, a high percentage of people that start to contribute stop the first day or after a short period.

There are also various studies that show the contribution inequality with most of the data produced by a minority (see Anran Yang, Hongchao Fan, Alexander Zipf, 2016 and Ding Ma, Mats Sandberg and Bin Jiang, 2015). Statistics and analysis presented by Pascal Neis and Simon Poole over the last years did also show various aspects of the contributions, with the concentration of Contributions by a minority and the volatility of contributors participation.

The OSM Changesets Dump File contains metadata about each changeset edition. Like others, our analysis comes from this file. If we dig in and analyze the OSM changesets database, this shows that for the 13 years from 2004 to end of september 2017, 953,200 contributors edited at least one object and 108,800 edited more then 1,000 objects (ie. node, ways or relations). This is an indication that there are massive inflows of new participants that contribute minimally. The analysis below will confirm this hypothesis.

The Pulse of OpenStreetMap Contributors

Cohort analysis let’s break a dataset into related groups that share common characteristics or experiences. For OSM, we can group contributors by the year they started to contribute and compare the various cohorts to see patterns of contribution.

The graph 1 reveals what I call the «Pulse of OpenStreetMap Contributors». Rodolphe Quiedeville OSMPulse website did also illustrate the beat of contributions. While his real-time graphs (Last update in 2014) did focus on the number of objects edited minutely, we focus on the contributors with the same year of experience. For each calendar year, this is like if we did organize a marathon will all the contributors aligned on the same start line, looking at their progression month by month. We could also follow them for even longer periods and compare their long term behavior.

Graph 1
Note that this graph do not show a long timeserie. These are 
individual graphs for each yearly cohort.  For each year,
we follow for 12 months the new contributors that start editing. 

Here for each calendar year, we follow OSM new contributors and participation from their month 1 to month 12 of contribution (it does not matter if one started in january, feb. etc). With such cohort analysis, we can see all the new entries for the year. This reveals what I call the Pulse of «Discovery contributors» with the great majority that do not participate more then 1 month. The high rate of departure at month 1 confirms the volatility of contributors participation. It shows what is called the lower tail of Contribution with a high number of Contributors with a minimal impact on the OSM edits. There is a lot more to say from such analysis and I will come back in an other Diary with more profile analysis from the cohort trajectory statistics.

Simon Poole published in his OSM Diary various examples that show the variability of inflows of new contributors and how it is not always related to significative edits. The sudden increase of contributors in early 2016 that we can observe on graph 2 below comes from Maps.Me editors where many of them did map personal infos. At the end of 2016, thousand of faked accounts were created in USA by SEO companies. OSMstat for 2017-09-30 shows also indications of various profiles with 5,413 active contributors and 3,301 with node edits > 15.

Graph 2

Monthly Statistics – Let’s color with Contributors Profiles

Lets’ now add Days profiles to the monthly statistics and help better see the heterogeneity between the Contributors and the Contributions. Pascal Neis OSMstat website and Simon Poole stats on the OSM wiki OSM wiki let us observe monthly statistics of contributions. We observe since the beginning of 2016 an average of 25,000 to 50,000 active contributors per month.

Graph 2 combines the monthly statistics of Contributors (ie. have edited in the month) and Contributions (ie. number of objects edited node, way or relation) from the OSM stats wiki. We color these charts with the Contributors profiles based on cumulated days of participation since the first edit to OSM (Pascal Neis classification). The comparison of the two graphs let’s observe the concentration of Contributors in the first two classes and the concentration of the Contribution in the last class.

Profiles of Contributors and Contributions by month for 2017 up to september on Graph 3 let’s measure the respective percentage of each class based the cumulatives days of contribution. For 2017-08, the first two classes «Discover 1-2 days» (19,186 contributors) and «Rarely Active 3-14 days» (12,845 contributors) represent 66% of the share of Contributors. In comparison, their share of Contributions (13%) is relatively minimal. The «Discover» class with 3.5% of Contributors corresponds more or less to the «Pulse» we observe on the cohort analysis.

The other tail of distribution is represented by the 4,000 contributors that are part of the «Mega Active» class (271 days and more). They represent 8% of Contributors and 37.6% of Contributions.

Graph3

Pascal Neis Contributions of the yearly cohorts graph on his 2016 yearly Statistic Blog, shows the respective importance of each yearly cohort on the level of monthly Contributors. In this case, the cohorts are not aligned from month 1 but colors let's see stratas of contributors by the year they started to edit. With this representation, the peak of the yearly new contributors is less acute, being spread in the month they started editing. The top of Graph 4 reproduces Pascal chart. Every year, we observe the jump in the number of contributors, and their relative importance that reduce gradually in the next years. Again, we see the rise of Contributors from 2016.

The Contributions Profile at the bottom of the Graph (ie.Percentage of Contributions by months) reveals that the first year of participation, the yearly cohort of new contributors represents nearly 40% of contributions, that share reducing in the following years. With the rise of Contributors in 2016 and 2017, we observe also a rise in the share of Contributions. Simon has measured that the rise of Maps.Me Contributors had a minimal impact on the share of Contributions. More analysis will be necessary to explain which categories are responsible of this jump.

Graph 4

I hope that this different angle on the Contributors data will hep to better understand the various contributions to OSM. Do not hesitate to comment. And I plan to continue such analysis in other Diaries.

ned compost related support for drop off, community outreach, collaboration, greenhouse and cold frame design and vermiculture.

just an update of number of keys grows, and grows, and grows ...

since the last post one week ago, the graph is now in a sideways motion ... great.

thanks guys, and keep up.

Approximately 50 MIT students and OSM'ers from the Boston area participated in a 4 hour Mapathon on Sunday afternoon 10/8/2017.

The task was to map buildings from satellite photos taken before Hurricane Maria

The event went off without a hitch. The facilities at the Dewey Library were fantastic. I was surprised that this event, organized just a couple of days ago was so well attended. The student organizers spread the word and the community responded.

The organizers were pleased at the turnout and hope to hold more mapathons in the future.

I saw a write up in the Baltimore Sun about students at JHU hosting mapping parties. That was the first I heard about this fantastic project. Contributing in my spare time and trying to encourage my friends and co-workers to join the effort!

Here is how Wikipedia defines "Trunk road":

A trunk road, trunk highway, or strategic road is a major road, usually connecting two or more cities, ports, airports and other places, which is the recommended route for long-distance and freight traffic. Many trunk roads have segregated lanes in a dual carriageway, or are of motorway standard.

'usually'.. 'many'.. Adverbs that serve to muddle the definition: I still don't know whether a specific road can be classified as a trunk or not.

The OSM wiki has this to say:

Use highway=trunk for high performance or high importance roads that don't meet the requirement for motorway. In different countries, either performance or importance is used as the defining criterion for trunk – see #International equivalence and Highway:International equivalence for guidance on road classification in different countries.

Hmm. Equally noncommittal. But there are reference to places where more specific references are to be found. I am interested in the United States. So let's look there. The 'International Equivalence' section on the highway=trunk page says:

Surface expressway: A relatively high-speed divided road (at least 40 MPH with a barrier or median separating each direction of traffic), with a limited amount of intersections and driveways; or a major intercity highway. This includes many U.S. Highways (that do not parallel an Interstate) and some state highways. Wikipedia reference

..whereas the separate 'International Equivalence' page says for trunks in the United States:

Limited access highway with occasional grade level intersections, or major intercity highway where no motorway exists.

Not precisely the same, but I am starting to see a pattern. The definition of trunk, according to the people who wrote the wiki pages, seems to be a mix of technical and functional road classification:

• Technical: Designed for speeds > 40 MPH, limited at-grade intersections.
• Functional: Major inter-city highway where no motorway exists.

Let's try and apply this to some major roads in Utah that I know well and are currently at least partly marked as trunk. (This Overpass query shows all trunk ways in Utah.)

US Highway 6 between Spanish Fork and I-70, currently marked as trunk in OSM. This is a two lane road with a speed limit of 65 MPH, with some exceptions in places. It is the main connection between the Wasatch Front and southeast Utah and southwest Colorado. There is no freeway alternative. **Conclusion: proper trunk.

State Route 154 or Bangerter Highway as it is known locally. Currently marked as trunk but some stretches are marked motorway as well. It is a 4-6 lane divided highway. Some sections have at-grade intersections (Continuous Flow Interchanges among them) but they are spaced pretty far apart. SR 154 is not a major inter-city highway, and there is a reasonable freeway alternative available. However, SR 154 does serve an important connector function between cities and towns west of Salt Lake City and the SLC International Airport. Conclusion: trunk is OK, but motorway sections should be downgraded.

US Highway 89. Currently only marked trunk between Farmington and I-84, where it meets the technical (if not the functional) definition of trunk. Most of the rest of US-89 is two-lane road with a speed limit of 65 or 70 MPH, with local exceptions. If you look at it purely from a functional perspective, only the stretch between Brigham City and the WY border in the North, and the (long) stretch from Provo south to the AZ border can be considered trunk. The section actually marked trunk currently is not part of either of these two. To my mind, the sections that serve important long distance connecting functions should be trunk as well. Conclusion: more sections should be trunk.

Looking at a few of the roads I know and their current tagging in the context of the current wiki definitions, my overall conclusion is:

A road should be tagged trunk in the United States if either of the following conditions are met:

1. The road is designed for speeds > 50 MPH and has limited at-grade intersections.
2. The road is a serves an important inter-city connector function, and there is no freeway alternative.

Small stretches where condition 1) is not met, for example a reduced speed limit in a built up area, should be tagged trunk to maintain a continuous classification.

Pretty? No. Works for me? I think so. What do YOU think?

Tomorrow is the 10 year anniversary of OSM's API version 0.5. This is the version of the OSM-API that first exposed (among other things) the version number on all OSM objects, making it possible to access the full history of every object modification from this point onward.

This means that very soon, the full history planet file published on planet.osm.org will contain more than 10 years of editing history which can be investigated, evaluated and analyzed (using tools like the OSM history database oshdb that's currently under development at HeiGIT on the University of Heidelberg, which I presented earlier this year at the State of the Map).

Of course, OpenStreetMap as a project exists for a bit longer than that (about 13 years now) and there was already quite some data mapped before the OSM API 0.5 was introduced 10 years ago.

Here's an interesting side note: There already existed a history call in OSM's API 0.4 (and apparently even in 0.3, see the comments below), but unfortunately this historic data apparently hasn't been preserved in the newer versions of the OSM API, meaning that it is also not available in the (relatively) easy to use full-history planet dumps which are available nowadays. As far as I can tell, this "prehistoric" OSM data has basically been lost (though some of it might be reconstructible by analyzing the list of very old planet dumps on planet.osm.org). Does someone of you perhaps know what exactly happened to that data back then?

(Cake made by Liz LeBreuilly, picture uploaded by Blackadder, CC-BY-SA-2.0.)