OpenStreetMap

Users' diaries

Recent diary entries

Detailing Montclaire Apartments

Posted by That NE Philly Guy on 7 December 2018 in English (English)

In Fox Chase in the SE quadrant of Susquehanna and Pine Rds.

رسم برج خنک‌کننده نیروگاه

Posted by geoaria on 7 December 2018 in Persian (فارسی)

man_made=tower + tower:type=cooling هنگام رسم این برج ها علاوه بر تگ building=yes و تگ man_made و تگ building=industrial استفاده کنبد و با تگ height هم ارتفاع برج را تعیین کنید.

https://wiki.openstreetmap.org/wiki/Tag:tower:type%3Dcooling

https://wiki.openstreetmap.org/wiki/Fa:Tag:tower:type%3Dcooling

مثال

روش تعیین کاربری یک ساختمان

Posted by geoaria on 7 December 2018 in Persian (فارسی)

در تگ building=yes به‌جای مقدار عمومی "yes" کاربری ساختمان را وارد کنید. یعنی اگر ساختمان، یک مدرسه است از building=school استفاده کنید. تگ #building مقادیر متفاوتی از قبیل house, apartments, office, kiosk, roof, mosque, civic, hospital, supermarket...

و خیلی موارد دیگر رر می‌تواند پوشش دهد که می‌توانید در جدول موجود در لینک زیر مشاهده بفرمایید https://www.openstreetmap.org/wiki/Key:building

🔴 نکته‌: این مقادیر فقط کاربری ساختمان را مشخص می‌کنند و نمی‌توانند جایگزین تگ اصلی شوند، این یعنی مثلاً وقتی به یک ساختمان تگ building=school را می‌دهید فقط کاربری این ساختمان جهت یک مدرسه تعیین کرده اید. پس برای اینکه نشان دهید اینجا در حال حاضر یک مدرسه است باید از تگ amenity=school استفاده کنید. پس برای یک مدرسه‌ متروکه و خالی فقط از تگ building=school و برای یک مدرسه‌ فعال از دو تگ building=school و amenity=school بصورت همزمان استفاده کنید، که البته تگ amenity=school بهتر است به محدوده‌ مدرسه اعمال شود و نه به ساختمان. این موضوع برای کُل ساختمان‌ها صادق است.

🔵نکته‌ : ممکن کاربری اصلی ساختمان با کاربری فعلی متفاوت باشد، مثلاً یک کلیسای قدیمی را در نظر بگیرید که الآن به‌عنوان کتابخانه استفاده می‌شود. برای این مورد باید از دو تگ building=church و amenity=library بصورت همزمان استفاده شود.

🔵نکته‌ : با نمایش کاربری یک ساختمان ، کیفیت نمایش سه بعدی (و بسیاری موارد دیگر) می‌تواند موثرتر از قبل باشد.

OSMF Board election 2018 - Answers provided after deadline

Posted by Mapanauta on 7 December 2018 in English (English)

Hi to all,

As some of you might know I am candidate for the OSMF Board election 2018. There is diverse group of candidates and I am sure every single one will be doing a great job if they are elected. Please find the information and manifiestos here. I was not able to complete all my answers by the deadline so please find the pending answers below:

The values and goals of the OpenStreetMap project

I agree with the core value and goals covered in the mission of the OSMF website but I consider specifically regarding the goals we need to find a way to measure the achievements and set up statistics to be able to know if we are going in the right way or where are we failing to achieve the objectives.

Your opinion on Term limits for board members?

I agree with having limited term limits, I don't thing it is healthy for any organization having the same people in a Board for a long period. More people should  have the opportunity to be part of the board and provide diverse and fresh ideas. When a person knows they have a limited period to cause impact I believe they can be more efficient.

Your opinion on Organized editing

I believe this is a good start and this is a good way to enforce the quality of the data in OSM. In my own experience I helped to coordinate mapathons in Universities where the largest audience we had was eighty eight mappers, of course this was with the help of the professors in the Universities, so we have to make sure the guidelines do not discourage community events and the excitement of organizing  events (which is already a lot of work). For the companies it will be good because that way a standard about what is expected from them will be open an available. Regarding small organization or enthusiatic groups I will say mentioning examples in a wiki will help understand the scope of the guidelines.

Due diligence reverting edits

Reverting should be always discuss but I believe there could be either unintencional errors or vandalism and we can see that immediately from the changeset. If it is vandalism (such as a hate message) it should be revert immediately and if is an error we should communicate with the mapper to make her/him aware of the mistake and if the person do not take action then proceed with reverting.

Criticism on social media

We need to be open for criticism and even sometimes can be harsh we should take something positive out of it because that will make us stronger as individuals and as a community. I also believe even we agree and disagree in many points the community should be able to communicate in a respectful and polite way.

Thanks,

Miriam

weeklyOSM 434

Posted by Laura Mugeha on 6 December 2018 in Swahili (Kiswahili)

06.11.2018-12.11.2018

Picha

  • Logo

Miaka 10 ya OSM nchini India^1^ | Picha ya Arun Ganesh (@planemad) chini ya CC-BY-SA 3.0

Kutengeneza Ramani

  • Gregory Marler alifanya mafunzo ya Youtube kuonyesha jinsi anatumia picha yake mwenyewe nyuzi 360 kutoka Mapillary kwa ajili ya kuhariri na JOSM.

  • Inaonekana kuwa utengenezaji wa ramani unaofanywa na Grab (Uber ya South-East Asia) husababisha matatizo makubwa. Russ McD alisema "... kile tunachokiona ni shirika lingine kuu, kuruhusu kundi la wasio wataalamu wa kutosha kwenye eneo la mafunzo wanaloita OSM. Wote hulipwa, wakati sisi wanaojitolea, tunarekebisha kazi yao." Lakini isome mwenyewe.

  • Hivi karibuni tuliripoti kwambaTelenav imefanya programu yao ya kisayansi ya kugundua ishara ya barabara na data ya mafunzo ambayo hutambua aina ya ishara 100 ziwe wazi . Telenav inazitumia na OpenStreetCam , huduma inayofanana na Mapillary. Martijn van Exel alieleza kuhusu mpangilio wa uthibitisho, ambayo inakuwezesha kuthibitisha safari nzima na ishara nyingi zilizoonekana kwa haraka sana katika tovuti ya OpenStreetCam.

  • Swali kama; Kama Aruba, Curacao na Bonaire lazima kuwa kinachoitwa kama nchi huru au kama sehemu ya ufalme wa Uholanzi ulijadiliwa katika jukwaa hilo. Mlolongo unatoa muonesho wa viwango tofauti vya uhuru wa maeneo bado zaidi au chini ya milki ya ufalme

Jamii

  • Huduma ya kupakua ya Geofabrik ina watumiaji wengi na Frederik Ramm, daima anajaribu kupunguza trafiki kwa kutoa dondoo za data kama kubwa kama ilivyohitajika lakini pia kama ndogo iwezekanavyo. Moja ya dondoo kubwa zaidi ambayo hakuna ugawaji ulipo, ni California. Swali jinsi California inaweza kugawanywa imebaini kuwa uelewa wa California huwa na jukumu muhimu zaidi.

  • Mtumiaji Nop alitangaza! (de) (tafsiri ya moja kwa moja ) sasishi yake ya mhariri kitakwimu katika Wiki ya OSM.

  • Miaka mitano baada ya kimbunga Haiyan kuikumba Ufilipino, mtumiaji seav anaelezea msaada uhusishao OSM katika shajara yake mtumiaji. Soma jinsi ambavyo kimbunga kimebadili OSM na jamii yake katika Ufilipino.

  • Shirika la OpenStreetMap Foundation nchini Colombia imetekeleza zana za OSM katika lugha ya Kihispania (hasa kwa Amerika ya Kusini na Colombia), kama programu za Tasking Manager na Umap na kutengeza zana zengine. Kampeni ya kukusanya fedha inaomba msaada wako kuendeleza hili kwa angalau miaka miwili zaidi.

  • Benki ya Dunia ilichapisha makala kuhusu OSM na kuongezeka kwa jamii za ramani. Makala hiyo inaonyesha ushirikiano wa kutengeneza ramani Asia na Afrika.

  • tyr_asd alitumia blogu yake ya OSM kutoa shukrani yake kwa jamii ya OSM huko Graz, Geofabrik na Disastermappers Heidelberg.

  • [1] Arun Ganesh alitweet utambulisho kwa ajili ya SOTM ya Asia ijayo Novemba 17-18, 2018 huko Bangalore, India na ina msururu wa maonyesho mazuri ya miaka 10 ya OSM nchini India.

Bidhaa

  • Jeff Underwood, kutoka Facebook, alichapisha makala yenye mada So how does Facebook's AI Assisted Road Import Process work? kuhusu zana yao ya kisayansi ya kizazi cha data. Facebook sasa inapakia data ya Thailand na washirika na HOT nchini Indonesia.

Taasisi ya OpenStreetMap

  • Tobias Knerr (OSM Tordanik) alitangaza (de) kwamba atasimama kama mgombea wa uchaguzi wa bodi ya OSMF.

Matukio

OSM ya Kibinadamu

  • MapAction, shirika la kutengeneza ramani kwa madhumuni ya kubinadamu, ilichapisha a makala kuhusu usaidizi wa wenye hiari watatu na wafanyakazi wawili uliotolewa Malawi baada ya mafuriko makubwa Januari 2015.

Elimu

  • Volksfreund kutoka Trier aliripoti (tafsiri ya moja kwa moja) kuhusu mwanzo wa Mradi wa Erasmus + uliofadhiliwa na EU ambapo walimu kutoka nchi tano walikutana Saarburg, Ujerumani, kwa mafunzo ya OSM. Hasa, makala hiyo inaonyesha kiunganisho Severin Menard, aliyeripoti kuhusu uzoefu wake Afrika. Mradi wote utaendelea kwa miaka miwili na lengo la kuhamasisha wanafunzi wengi katika nchi zinazohusika za Ulaya kushiriki katika "kutengeneza ramani kwa madhumuni ya kibinadamu".

Open Data

  • Tume ya Geospatial ya Uingereza itatangaza ushindani wa takwimu za ushirikiano mnamo 26 Novemba. Kiasi ni takriban sawa na gharama za matumizi ya jumla ya OSM kwa kuwepo kwake kwa miaka 14 nzima.

  • Taasisi ya Heidelberg ya Teknolojia ya Geoinformation(HeiGIT) imechapisha openelevationservice katika GitHub.

  • SmugMug, wamiliki wapya wa Flickr, walitangaza mabadiliko makubwa kwa Ts & Cs kwa akaunti za bure za Flickr. Picha kubwa ya 1000 zitahifadhiwa kwa akaunti hizi ambazo zinaweza kuathiri washiriki wa OSM na wanablogu ambao wametumia Flickr kwa picha na picha zingine.

Programu

  • OSMCha imesasishwana vipengele muhimu. OSMCha sasa inalingana na sheria ya GDPR na ina njia mpya ya kupokea vipengele vya OSM zilizoruhusiwa.Wille alichapisha makala kuhusu sasisho hili.

  • Tessio Novack na wenzake katika Chuo Kikuu cha Heidelberg walichapisha jarida kuhusu kuzalisha njia zilizopendekezwa kulingana na data ya OpenStreetMap na Openrouteservice.

Programming

  • Andy Allan, wa OSM-dino, aliandika makala yenye mada Moderation, Authorisation and Background Task Improvements for OpenStreetMap. Anatoa muhtasari wa hivi karibuni wa sasisho za OSM , ikiwa ni pamoja na msaada kutoka kwa Ruby for Good, timu ambayo ilichangia maboresho mengi katika OSM wakati wa tukio lao la kila mwaka.

  • Katika blogu yake Christoph Hormann anaelezea (tafsiri ya moja kwa moja) jinsi ya kukabiliana na zana iliovunjika ya Mapnik ya mifumo ya eneo ya SVG, kama uwakilishi wa maeneo kama vile misitu na milima.

  • Nadhifu: nyaraka mpya ya Openrouteservice API iliyotengenezwa na vue.js inaonyesha kipengele chake kipya cha ramani ya LeafletJS.

  • Christoph Hormann alichapisha uwasilisho wake wa Ujerumani na sisi kwenye miradi ya ramani ya wazi ya jamii ya OSM ambayo ametumia kwa hotuba yake katika Shirika la Kijerumani ya Cartography na Geomatics.

Matoleo

  • Tovuti ya ujerumani mobilesicher.de imeripoti (de) (tafsiri ya moja kwa moja) kuwa programu ya usafiri inayotumia data ya OSM, Magic Earth imeondoa mahusiano na Google, Facebook and Twitter na haitagawa data ya watumiaji tena.

Je, wajua

  • Anonymaps alionyesha tweet ya Mapbox kuhusu Porsche, inayotumia usafiri kwa kutumia data ya OSM kutoka kwa kampuni ya Mapbox ingawa inamiliki sehemu ndogo ya moja kwa moja hapa. Tungependa kuonyesha kwamba asilimia ya umiliki iliyoelezwa na Anonymaps si sahihi.

  • ... orodha ya programu husika za OSM?

  • ... osmoscope ya Jochen Topf kurekebisha makosa bugs in OSM? Ulijaribu na Osmoscope haikushiriki data kwa JOSM? Hii labda kwa sababu kivinjari chako haina cheti cha anwani ya JOSM au haujawezesha udhibiti wa kijijini. Jaribu kutumia https://127.0.0.1:8112/version katika kivinjari chako.

OSM katika vyombyo bya habari

Vingine vya kijeographia

  • Makala ya kikundi cha GIScience cha chuo kikuu cha Heidelberg inaonyesha kuhusu Wheelmap na matumizi ya habari ya kijiografia kuboresha upatikanaji.

  • Mapillary imezindua zana ya uwazi ya kutengeneza programu.

  • Ujerumani, kuna mzunguko wa njia (tafsiri ya moja kwa moja). Kampuni ya Solmare, imetengeneza njia ya mita 90 with na kuiweka kwa Erftstadt/NRW. Kampuni inaona maendeleo haya kama teknolojia ya baadaye yenye mafanikio sana. Utambulisho wa njia hii ilipendekezwa kwa surface=solar_panel. Kuna njia hizi zilizo na urefu zaidi kama katika Uholanzi (tafsiri ya moja kwa moja) (lakini nila utambulisho...).

Matukio yajayo

  • |Wapi |Nini |Lini |Nchi | |----------------------|----------------------------------------------------------------------|---------------------|------------------------------------------------------------------------------| |Mumble Creek |OpenStreetMap Foundation public board meeting |2018-11-15 |everywhere| |Mannheim |Mannheimer Mapathons |2018-11-15 |germany | |Freiberg |Stammtisch |2018-11-15 |germany | |Pamplona |Mapatón Pamplona - Médicos sin Fronteras |2018-11-16 |spain | |Barcelona |Mapes i Birres (Trobada trimestral usuaris d'OSM) |2018-11-16 |spain | |Como |ItWikiCon 2018 |2018-11-16-2018-11-18|italy | |Como |Mapping Party during ItWikiCon 2018 |2018-11-17 |italy | |Brno |State of the Map CZ 2018 |2018-11-17 |czech republic | |Bengaluru |State of the Map Asia 2018 |2018-11-17-2018-11-18|india | |Vantaa |OSM GeoWeek 24h HOT Mapathon |2018-11-17-2018-11-18|finland | |Wakayama |オープンデータソン in 雑賀崎 |2018-11-18 |japan | |Cologne Bonn Airport |Bonner Stammtisch |2018-11-20 |germany | |Lüneburg |Lüneburger Mappertreffen |2018-11-20 |germany | |Derby |Pub Meetup |2018-11-20 |united kingdom | |Reading |Reading Missing Maps Mapathon |2018-11-20 |united kingdom | |Melbourne |FOSS4G SotM Oceania 2018 |2018-11-20-2018-11-23|australia | |Toulouse |Rencontre mensuelle |2018-11-21 |france | |Karlsruhe |Stammtisch |2018-11-21 |germany | |Lübeck |Lübecker Mappertreffen |2018-11-22 |germany | |Alajuela |ES:State of the Map Costa Rica |2018-11-23-2018-11-25|costa rica | |Manila |【MapaTime!】 |2018-11-24 |philippines | |Dublin |Monthly Mapping Party |2018-11-24 |ireland | |Ivrea |Incontro mensile |2018-11-24 |italy | |Graz |Stammtisch Graz |2018-11-26 |austria | |Bremen |Bremer Mappertreffen |2018-11-26 |germany | |Arlon |Espace public numérique d'Arlon - Formation Contribuer à OpenStreetMap|2018-11-27 |belgium | |Reutti |Stammtisch Ulmer Alb |2018-11-27 |germany | |Düsseldorf |Stammtisch |2018-11-28 |germany | |San José |Civic Hack Night & Map Night[1] |2018-11-28 |united states | |Toronto |Mappy Hour |2018-12-03 |canada | |Praha - Brno - Ostrava|Kvartální pivo |2018-12-05 |czech republic | |Stuttgart |Stuttgarter Stammtisch |2018-12-05 |germany | |Toulouse |Rencontre mensuelle |2018-12-05 |france | |Bochum |Mappertreffen |2018-12-06 |germany | |Dresden |Stammtisch Dresden |2018-12-06 |germany | |online via IRC |Foundation Annual General Meeting |2018-12-15 |everywhere| |Heidelberg |State of the Map 2019 (international conference) |2019-09-21-2019-09-23|germany |

What next?

Posted by Kilkenni on 6 December 2018 in English (English)

Our case revealed a serious problem. This problem is not only of ignoring international law, but also a problem of lack of transparency in an open community-driven project. The boil was present for a while now, but this case is where its existence became apparent. Data Working Group now is not what it was when it was created, and not everyone is happy with what it turned into. Currently it is a non-transparent OSM body that answers to no one but has serious influence on decision-making inside OSMF, as three out of seven OSMF Board members are also DWG members.

Our indignation and our actions have flushed out this issue into the open. We must, however, remain calm and patient. We should inform OSM community and draw attention to the issue as it is the only way to see it properly resolved.

This text is not mine but I agree. OSM currently lacks rigid rules or firm agreements concerning community, it lacks some sort of social contract. While this approach has certain advantages, it utterly fails in case of internal conflict in the community, and resolving such a conflict is challenging (to say the least).

(careful, language. I would use a spoiler tag if Markdown had one) Troubleshooting or, for English-speaking people, roughly

"System of assumed defaults" has serious benefits for rule-making in small communities as

  • it is fast to build, and

  • it allows jumping straight to business instead of paperwork

However, when such a system breaks causing a conflict, troubleshooting it is a clusterf--k because you'll go nuts before you figure out all the defaults explicitly and find an error to blame.

State of the Map US 2018: OpenStreetMap Data Analysis Workshop

Posted by Jennings Anderson on 5 December 2018 in English (English)

(This is a description of a workshop Seth Fitzsimmons and I put on at State of the Map US 2018 in Detroit, Michigan. Cross-posting from this repository)

Workshop: October 2018

Workshop Abstract

With an overflowing Birds-of-a-Feather session on “OSM Data Analysis” the past few years at State of the Map US, we’d like to leave the nest as a flock. Many SotM-US attendees build and maintain various OSM data analysis systems, many of which have been and will be presented in independent sessions. Further, better analysis systems have yet to be built, and OSM analysis discussions often end with what is left to be built and how it can be done collaboratively. Our goal is to bring the data-analysis back into the discussion through an interactive workshop. Utilizing web-based interactive computation notebooks such as Zeppelin and Jupyter, we will step through the computation and visualization of various OpenStreetMap metrics.

tl;dr:

We skip the messy data-wrangling parts of OSM data analysis by pre-processing a number of datasets with osm-wayback and osmesa. This creates a series of CSV files with editing histories for a variety of US cities which workshop participants can immediately load into example analysis notebooks to quickly visualize OSM edits without ever having to touch raw OSM data.

1. Background

OpenStreetMap is more than an open map of the world: it is the cumulative product of billions of edits by nearly 1M active contributors (and another 4M registered users). Each object on the map can be edited multiple times. Each time the major attributes of an object are changed in OSM, the version number is incremented. To get a general idea of how many major changes exist in the current map, we can count the version numbers for every object in the latest osm-qa-tiles. This isn't every single object in OSM, but includes nearly all roads, POIs, and buildings.

 Histogram of Object Versions from OSM-QA-Tiles

OSM object versions by type. 475M objects in OSM have only been edited once, meaning they were created and haven't been subsequently edited in a major way. However, more than 200M have been edited more than once. Note: Less than 10% of these edits are from bots, or imports.

Furthermore, when a contributor edits the map, the effect that their edit has depends on the type of OSM element that was modified. Moving nodes may also affect the geometry of ways and relations (lines and polygons) without those elements needing to be touched. Thus, a contributor's edits may have an indirect effect elsewhere (we track these as "minor versions"). Conversely, when editing a way or relation's tags, no geometries are modified, so counts within defined geographical boundaries often don't incorporate these edits. Therefore, to better understand the evolution of the map, we need analysis tools that can expose and account for these rich and nuanced editing histories. There are a plethora of community-maintained tools out there to help parse and process the massive OSM database though none of them currently handle the full-history and relationship between every object on the map. Questions such as "how many contributors have been active in this particular area?" are then very difficult to answer at scale. As we should expect, this number also varies drastically around the globe:

 Map of 2015 users Map of areas with more than 10 active contributors in 2015 source. The euro-centric editing focus doesn't surprise us, but this map also shows another area with an unprecedented number of active contributors in 2015: Nepal. This was in response to the April 2015 Nepal Earthquake. This is just one of many examples of the OSM editing history being situational, complex and often difficult to conceptualize at scale.

Putting on a Workshop

The purpose of this workshop was two-fold: first, we wanted to take the OSM data analysis discussion past the "how do we best handle the data?" to actual data analysis. The complicated and often messy editing history of objects in OSM make simply transforming the data into something to be read by common data-science tools an exceedingly difficult task (described next). Second, we hoped that providing such an environment to explore the data would in turn generate more questions around the data: What is it that people want to measure? What are the insightful analytics?

2. Preparing the Data: What is Available?

This was the most hand-wavey part of the workshop, and intentionally so. Seth and I have been tackling the problems of historical OpenStreetMap data representation independently for a few years now. Preparing for this workshop was one of the first times we had a chance to compare some of the numbers produced by OSMesa and OSM-Wayback, the respective full-history analysis infrastructures that we're building. As expected, there were some differences in our results based on howe we count objects and measure history, so this was a fantastic opportunity to sit down and talk through these differences and validate our measures. In short, there are many ways that people can edit the map and it's important to distinguish between the following edit types:

  1. Creating a new object
  2. Slightly editing an existing object's geometry (move the nodes around in a way)
  3. Majorly editing an existing object's geometry (delete or add nodes in a way)
  4. Edit an existing object's attributes (tag changes)
  5. Delete an existing object

All but edit type 2 result in an increase in the version number of the OSM object. This makes identifying the edit easier at the OSM element level because the version number is true to the number of times the object has been edited. Edit type 2, however, a slight change to an object's geometry is a common edit that is often overlooked because it is not reflected in the version number. Moving the corners of a building to "square it up" or correcting a road to align better with aerial imagery are just two examples of edit type 2. We call these changes minor versions. To account for these edits, we add a metadata field to an object called minor version that is 0 for newly created objects and > 0 for any number of minor version changes between a major version. When another major version is created, the minor version is reset to 0.

Quantifying Edits

Each of the above edit types refer to a single map object. In this context, we consider map objects to be OSM objects which have some level of detailed attribute. As opposed to OSM elements (nodes, ways, or relations), an object is the logical representation of a real-world object: road, building, or POI. This is an important distinction to make when talking about OSM data because this is not a 1-1 relationship. OSM elements do not represent map objects. A rectangular building object, for example, is at minimum 5 OSM elements: at least 4 nodes (likely untagged) that define the corners and the way that references these nodes with an attribute of building=*. An edit to any one of these objects is then considered an edit to this building.

This may seem obvious when thinking about editing OpenStreetMap and how the map gets made, but reconstructing this version of OSM editing history from the database is difficult and largely remains an unsolved (unimplemented) problem at the global scale: i.e., there does not yet exist a single (public, production) API end-point to reconstruct the history of any arbitrary object with regards to all 5 types of edits mentioned above.

Working towards such an API, another important infrastructure to mention here is the the ohsome project built with the oshdb. This is another approach to working with OSM full-history data that can ingest full-history files and handle each of these edit types.

Making the data Available

For this workshop then, we pre-computed a number of statistics for various cities that describe the historical OSM editing record at per-edit, per-changeset, and per-user granularities (further described below).

3. Interactive Analysis Environment

Jupyter notebooks allowed us to host a single analysis environment for the workshop such that each participant did not have to install or run any analysis software on their own machines. This saved a lot of time and allowed participants to jump right into analysis. For the workshop, we used a single machine operated by ChameleonCloud.org and funded by the National Science Foundation to host the environment. I hope to provide this type of service again at other conferences or workshops. Please be in touch if you are interested in hosting a similar workshop and I can see if hosting a similar environment for a short duration is possible!

Otherwise, it is possible to recreate the analysis environment locally with the following steps:

  1. Download Jupyter
  2. Clone this repository: jenningsanderson/sotmus-analysis
  3. Run Jupyter and navigate to sotmus-analysis/analysis/ for the notebook examples.

4. Available Notebooks & Datasets

We pre-processed data for a variety of regions with the following resolution:

1. Per User Stats

A comprehensive summary of editing statistics (new buildings, edited buildings, km of new roads, edited roads, number of sidewalks, etc.) see full list here that are totaled for each user active in the area of interest. This dataset is ideal for comparing editing activity among users. Who has edited the most? Who is creating the most buildings? This dataset is great for building leaderboards and getting a general idea of how many users are active in an area and what the distribution of work per user looks like.

2. Per Changeset Stats

The same editing statistics as above (see full list of columns here) but with higher resolution: grouped by the changeset. A changeset is a very logical unit of analysis for looking at the evolution of the map in a given area. Since each changeset can only be from one user, this is the next level of detail from user summaries. Since changeset IDs are sequential, this is a great dataset for time-series analysis. Unfortunately, due to a lack of changeset extracts for the selected regions (time constraints, fun!), OSMesa-generated roll-ups do not include actual timestamps. This caused some confusion for a group looking at Chicago, as visualization of their building import did not show the condensed timeframe during which many changesets were made when using changeset ID as the x-axis.

3. Per Edit Stats

This dataset records each individual edit to the map. This dataset is best for understanding exactly what changed on the map with each edit. Each edit tracks the tags changed as well as the geometry changes (if any). This dataset is significantly larger than the other two.

What cities are available?

Detroit is currently available in this repository. See this list in the readme for a handful of North American cities available for download.

5. Example Notebooks

  1. Per User Stats
  2. Per Changeset Stats
  3. Per Edit Stats

Editing heatmap Example heatmap from building edits in Detroit

If you're interested in more of this type of analysis, directions on setting up this analysis environment locally can be found in this repository. Furthermore, much of this is my current dissertation work, so I'm always happy to chat more about it. Thanks!

Location: The Hill, Boulder, Boulder County, Colorado, 80802, USA

Сумерки Ночной клуб / SUMERKI Disco club

Posted by Артем «Тёмич» Сидоренко on 5 December 2018 in Russian (Русский)

Добавьте пожалуйста правильный адрес клуба)

Location: Слободка, Николаев, Заводской район, Мыколаив, Николаевская область, 54000-54490, Украина

Mais de 10 Mil Changesets

Posted by BladeTC on 5 December 2018 in Brazilian Portuguese (Português do Brasil)

Saudações, amigos mapeadores!

Alcancei a marca de 10 mil changesets no OSM, desde que iniciei em 2011. 94% delas usando o JOSM. Hoje é possível alcançar rapidamente esta marca usando o iD, mas aquí é old school haha

Obrigado aos meus amigos da comunidade BR, que me ensinaram muito e sem eles não teria graça.

http://hdyc.neis-one.org/?BladeTC

Muito obrigado!

------ English Greetings, mappers!

I have reached the 10 thousand changesets mark in OSM since I started in 2011. 94% of them using JOSM. Today it is possible to quickly reach this brand using iD, but in old school haha

Thanks to my friends from the BR community who taught me a lot and without them it would not be fun.

http://hdyc.neis-one.org/?BladeTC

Thank you!

Location: Centro, Três Corações, Microrregião Varginha, Mesorregião Sul/Sudoeste de Minas, Minas Gerais, Região Sudeste, 37410-000, Brasil

Adicionando Casas, áreas Verdes, Arvores e Varias Melhorias no Bairro do Ibura/Cohab - Recife/PE

Posted by raphaelmirc on 5 December 2018 in Brazilian Portuguese (Português do Brasil)

Venho a alguns dias fazendo melhorias e inclusão de Arvores, Casas e Áreas Verdes no Bairro do Ibura/Cohab e bairros Vizinhos, o Bairro do Ibura/Cohab e um importante bairro da Capital Pernambucana, Recife possui varios bairros e o Bairro do Ibura e um dos maiores da Cidade, localizado na Zona Sul do Recife ele abriga o Aeroporto Internacional Gilberto Freire dos Guararapes e por ser um dos maiores bairros ele tem muitas ruas e escadarias.

O Bairro do Ibura vem tendo constantes atualizações e melhorias e atualmente está bem mapeado, participando inclusive do Projeto Mapeia Cep, que e a inclusão de Cep´s nas Ruas do Bairro.

Bairro do Ibura/Cohab no OpenStreetMap; https://www.openstreetmap.org/#map=15/-8.1241/-34.9458

Conheça o Site do Guia Osm-BR, Tutorias, Noticias e Ferramentas; https://guiaosmbr.webnode.com/

RaphaelMirc. Recife/PE. https://guiaosmbr.webnode.com/

Location: Cohab, Recife, Microrregião de Recife, Região Metropolitana de Recife, Mesorregião Metropolitana de Recife, Pernambuco, Região Nordeste, Brasil

10000 Edits Contest

Posted by Toeby on 5 December 2018 in English (English)

Today, i have been recognized, and i am in a contest with fellow mappers to reach 10000 edits by next Wednesday ( 7 days from now). Its a big challenge. This should be fun :) #osmnigeria#hotosm#microgrant2018#mapthedifference2018#uniquemappersteam#Youthmappers#unilagmappersteam

#CrimeaІsUkraine #DWG #CrimeaMap #КримЦеУкраїна #ИхТамНет

Posted by z-yurets on 5 December 2018 in English (English)

The Ukrainian community is concerned about the possible negative impact on the project as a whole, the emergence of lawsuits from users of data and the subsequent decline of the project, and therefore restores the borders of Ukraine to the internationally recognized status. The recent decision of DWG ( https://wiki.osmfoundation.org/wiki/Working_Group_Minutes/DWG_2018-11-14_Crimea ) neglects the wide recognition of Crimea as an integral part of Ukraine expressed by numerous governments and international organizations (in particular, UN General Assembly Resolution 68/262 http://www.un.org/en/ga/68/resolutions.shtml / https://undocs.org/en/A/RES/68/262 ). DWG actions directed to cut off Crimea from the borders of Ukraine are considered to be inadequate to the interests of the project and are not recognized by law. Any blockages (bans) aimed against members who restored the border of Ukraine to the widely internationally recognized status will be seen as unjustified pressure on the entire community and usurpation of power in the OSM.

P.S.

“changing names or country information would require consensus from both the Ukrainian and Russian communities. It is unlikely that any such edit proposals will be able to achieve this.” (с) DWG //

Moreover, according to clause 4, a consensus should be reached between the Ukrainian and Russian communities on changing information about countries. There is no consensus - there is no reason to separate the Crimea from Ukraine.

#CrimeaІsUkraine #DWG #CrimeaMap #КримЦеУкраїна #ИхТамНет

https://www.openstreetmap.org/relation/60199

https://www.openstreetmap.org/user/velmyshanovnyi - https://www.openstreetmap.org/user_blocks/2360 ;

https://www.openstreetmap.org/user/velmyshanovnyi - https://www.openstreetmap.org/user_blocks/2359 ;

https://www.openstreetmap.org/user/andergrin - https://www.openstreetmap.org/user_blocks/2358 ;

https://www.openstreetmap.org/user/Дівчина_з_Коломиї - https://www.openstreetmap.org/user_blocks/2357 ;

https://www.openstreetmap.org/user/паляниця - https://www.openstreetmap.org/user_blocks/2356 ;

https://www.openstreetmap.org/user/frankoivan - https://www.openstreetmap.org/user_blocks/2355 ;

https://www.openstreetmap.org/user/pumpkinpie226 - https://www.openstreetmap.org/user_blocks/2354 ;

https://www.openstreetmap.org/user/Хтосьіншийдятел - https://www.openstreetmap.org/user_blocks/2353 ;

https://www.openstreetmap.org/user/ue0 - https://www.openstreetmap.org/user_blocks/2350 ;

https://www.openstreetmap.org/user/andergrin - https://www.openstreetmap.org/user_blocks/2348 ;

https://www.openstreetmap.org/user/KKS - https://www.openstreetmap.org/user_blocks/2347 ;

...and other

https://www.facebook.com/openstreetmapua // https://twitter.com/osm_ua // https://t.me/osmUA // openstreetmap.ua@gmail.com

#CrimeaІsUkraine #DWG #CrimeaMap #КримЦеУкраїна #ИхТамНет

Posted by Artiom Komolov on 5 December 2018 in English (English)

The Ukrainian community is concerned about the possible negative impact on the project as a whole, the emergence of lawsuits from users of data and the subsequent decline of the project, and therefore restores the borders of Ukraine to the internationally recognized status. The recent decision of DWG ( https://wiki.osmfoundation.org/wiki/Working_Group_Minutes/DWG_2018-11-14_Crimea ) neglects the wide recognition of Crimea as an integral part of Ukraine expressed by numerous governments and international organizations (in particular, UN General Assembly Resolution 68/262 http://www.un.org/en/ga/68/resolutions.shtml / https://undocs.org/en/A/RES/68/262 ). DWG actions directed to cut off Crimea from the borders of Ukraine are considered to be inadequate to the interests of the project and are not recognized by law. Any blockages (bans) aimed against members who restored the border of Ukraine to the widely internationally recognized status will be seen as unjustified pressure on the entire community and usurpation of power in the OSM. It also violates OSM guidelines in respect of using national boundaries: https://wiki.openstreetmap.org/wiki/Boundaries#National

P.S. “changing names or country information would require consensus from both the Ukrainian and Russian communities. It is unlikely that any such edit proposals will be able to achieve this.” (с) DWG //

Moreover, according to clause 4, a consensus should be reached between the Ukrainian and Russian communities on changing information about countries. There is no consensus - there is no reason to separate the Crimea from Ukraine.

#CrimeaІsUkraine #DWG #CrimeaMap #КримЦеУкраїна #ИхТамНет

New OpenStreetBrowser version

Posted by skunk on 4 December 2018 in English (English)

New OpenStreetBrowser version! -> https://www.openstreetbrowser.org

Main new feature: * Export all visible map features as GeoJSON, OSM XML or OSM JSON!

More: https://blog.openstreetbrowser.org/node/59

#openstreetmap #osm

Bing Maps Fussgängerrouting auf OSM-Daten...

Posted by MKnight on 4 December 2018 in German (Deutsch)

hat sich da schon mal wer ausgekotzt?

Aufgefallen ist mir, dass auf Bing Maps Tonnen an Wegen nicht vorhanden sind.

Bilder sagen mehr als 1000 Worte:

https://binged.it/2Sz5v8L

vs

https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=50.98200%2C11.35230%3B50.98250%2C11.37810#map=15/50.9822/11.3653

Das Beispiel hab ich rausgesucht, weil hier ein Weg in der Ansicht ist, der (in OSM) die identischen Eigenschaften mit einem Weg hat, der nicht in der Ansicht ist (auf Bing direkt rechts von A fehlt dieser)

Hat da jmd. nen Reim drauf? Warum werfen die Wege weg? Ich sehe in meinem Extrembeispiel nichts, was das rechtfertigen könnte. (und bei allen anderen Wegen auch nicht.)

Die OSM-Daten da sind meiner Einschätzung recht frisch, im schlimmsten Fall 2 Jahre alt.

P.s. Ich finds total dufte, dass MS unsere Daten verwendet, aber in DER Art ist das doch eine Katastrophe?!

Road categorisation - OpenStreetMap versus Flemish Planning Documents

Posted by Tim Couwelier on 4 December 2018 in English (English)

Intro

First of all, some background. I'm employed by a consultancy agency, and anything traffic/mobility related is part of my job. It should also imply I'm familiar with several planning documents...

When diving into the world that is OpenStreetMap, I've had to realize a few things. Things in OpenStreetMap do NOT always mean what I assume they mean. Road categorisation is one of the key points here, and frequent need to repeat the explanation has finally made me create a diary post on the subject. For clarification I'll try to explain in english, but add the corresponding terms in dutch after.

The problem

At the core of the issue is semantics. OpenStreetMap and 'the real world' but use certain terms, like 'primary roads', 'secondary roads', 'tertiary roads'. These are however not synonymous, and editing OpenStreetMap just to be in line with those planning documents is often well.. wrong.

The planning context

  • Primary roads ('primaire wegen') are selected in the RSV ('Ruimtelijk Structuurplan Vlaanderen', or 'spatial structural plan Flanders'). They deal with the connections between 'Grootstedelijke gebieden' - essentially the main metropoles. Think along the likes of Gent, Antwerpen, Brussel, Brugge, ...
  • Secondary roads ('secundaire wegen') are selected one planning level lower, at a provincial level. The PRS ('Provinciaal Ruimtelijk Structuurplan') selects these. They deal with the connections between regional poles.
  • Tertiary roads are not named as such, but fit under the umbrella of 'lokale wegen'. In planning documents, we speak of 'lokale wegen types I, II and III', where I and II are dealing with the connections between very local poles, and III is basically whatever didn't fit elsewhere'. Selection of these happens in the 'Gemeentelijke Mobiliteitsplan' ('communal mobility plan).

The provincial level used to have a matching responsability for provinces to maintain some of the roads in their category. Around a decade ago, an overlap in responsabilities between Agentschap Wegen en Verkeer en Provinces was sorted out: roads maintained by Province were either transfered to Agentschap Wegen en Verkeer, or to the communities, based on functionality of the road.

In addition, note that there's always multiple versions, where typically the 'I' version means connection between poles of a same scale, and the 'II' version means collecting traffic from a lower level. In an attempt to summarize, here's an attempt at graphical representation of the principles behind it: Summary of the road categorisation according to planning documents. (Based on courses by Joris Willems, as I was taught at Vives Kortrijk)

The OpenStreetMap way

I'll base the comparsion of the wiki page for the belgian conventions: wiki page

At first glance, the comparison still seems straightforward:

  • Hoofdwegen vs Motorway

  • Primaire wegen vs Primary

  • Secundaire wegen vs Secondary

  • Lokale wegen I & II vs Tertiary

  • Options to specify more clearly what 'lokale wegen III' are (paths, service roads, residential roads, ...)

... leaving only 'trunk' as the odd one out.

Upon digging in a bit deeper however, the criteria as described are detailed in part through relation with the road numbers.

What once started as a ideal world (N1-N9 connect province capitals with Brussels, Nx0 add on to those in a radial pattern, interconnection those), with Nxx turning those basic structures into a finer mesh based on local city distribution. Proper 'ringroads' around cities get an Rxx number, which lets you filter out those functions too. And where there's only 'partial ring roads' around smaller towns, the part that circles around gets the Nxx number, while the old downgraded trajectory (which hopefully got an ACTUAL downgrade in profile) gets a number like Nxxa or Nxxd, or any variation of the sorts.

That seems sensible enough to link it to the categorisation (given there's a form of similarity to the earlier stated reasoning), regardless of what interpretation (OSM vs planning) is taken into account.

Intended use versus actual use

One of the key principles we adhere to when mapping is 'sticking to ground truth'. It's at times a sad realisation, but many roads have a lay-out, a certain 'look and feel', that leans more towards a different function then the actual intended use.

This inherently implies that for cases a road that should only give access to a small residential area (highway = residential, or a 'lokale weg III') actually has the appearance of a tertiary road, or that what should be a major axis in the traffic network has a rather underwhelming profile making it look and feel like a lower category..

We (the belgian community, and I'd assume by extension most communities) chose not to map according to 'vision documents', but to what we can see / survey in the field. Especially tertiary / secondary roads are subject to different interpretations between the two.

I still don't get the fuss - where does it actually differ?

Nothing like a good example to make a point. I've collected a few examples from my own region, as these were the cases that initially got me stumped.

The R32 - Ringroad around Roeselare

The R32, according to OSM logic, is a ring-road, with an Rxx number, and should therefor entirely be classified as 'primary' road all along the way. However, structural planning documents disagree: rather then seeing it as an actual 'ring-road' to divert traffic around the city, they see it as a 'traffic collecting road' towards the E403 - which 'collects' for example traffic from the northern branch of the N32 and the N36, then 'connects' those streams to a higher degree network...
The R32 This would imply it being a secondary road in the sections west of the N32, and primary between N32 and E403 both ways.. which is means the majority of the length is judged differently.

Meiboomlaan Roeselare

In OpenStreetMap you'll see Meiboomlaan in Roeselare marked as 'secondary'. It carries a number (N37), and it also looks like it's a road for a connection at a semi-high scale (watch it here ).

If we were to judge that road merely on planning documents alone, it is a 'lokale weg II', which boils down to a tertiary road...

In comparison, Hoogleedsesteenweg (connection to neighbouring town Hooglede) and Beversesteenweg (connection between Roeselare and part-community Beveren) which do form a connection between poles at a local level, do not exceed 'tertiary' status in OSM, largely due to a lack an N-number.... Somewhat ironical, within the limits of the so called 'Kleine Ring' (Westlaan - Noordlaan - Brugsesteenweg - Koning Leopold III-laan - Mandellaan - Kaaistraat - Koning Albert I-laan), having or not having an N-number doesn't mean all that much - these roads are now owned and maintained by the city of Roeselare.

But my choice is the better one!

Err.. maybe it is, maybe it's not. We need some common ground to determine how we tag things, and obtain a database (plus a rendered map) that fits as close to reality as we can get it. Sure, given the very very very similar structure and terminology it's easy to get carried away and 'straighten out this mess'. Believe me, I've been there. But I'm used to thinking in 'planning' and 'networks' and the theoretical part of how we'd like things to have. But untill that day, we should map things as they are.

We see similar patterns in other applications: - Landuse. Something may be designated for industrial buildings, if we go there and we see it's still entirely a meadow or farmland, we map it as such. We do not map it as an industrial zone, untill it actually is one. - Buildings: Even if we KNOW what's going up there, we don't map the building as long as it's not there. We don't map fancy landscaping around an appartment building, if it's still rough terrain as a building site - ...

You didn't mention Living Streets, School Streets, Cyclestreets, ...'

You're absolutely right, I didn't. These are all subcategories of what we'd call 'Lokale wegen III', and by default, OSM has a lot more flexibility to classify what's what. You'll never get overruled on these purely based on what's in any sort of planning document. I took the liberty of considering these out of the scope of this diary post.

Location: Krottegem, Aardappelhoek, Roeselare, West Flanders, Flanders, 8800, Belgium

weeklyOSM 433

Posted by Laura Mugeha on 4 December 2018 in Swahili (Kiswahili)

30.10.2018-05.11.2018

Picha

Kutengeneza Ramani

  • Kwa mujibu wa tweet, Pascal Neis amesasisha ramani yake ya Unmapped Places. Inaelezea makazi mbali na njia kubwa za trafiki. Hata hivyo, makosa ya kutambulisha pia yalipatikana katika nchi zilizotengenezewa ramani vizuri.

  • Stefano Maffulli anapendekeza emergency=fire_alarm_box katika orodha ya barua pepe kwa "kifaa kilichowekwa kwenye ardhi ya umma kutumika kwa taarifa ya idara ya moto ya moto".

  • Toni Erdmann aliripoti kuhusu zana mpya ya kuthibitisha ubora wa uchambuzi (QA): PTNA (Public Transport Network Analysis) katika orodha ya barua pepe (tafsiri ya moja kwa moja) na katika jukwaa (tafsiri ya moja kwa moja).

  • Makala yenye mada Finding Missing Roads in the Philippines ya Gowin inaelezea kazi yake na njia mpya ya kuthibitisha barabara tovu il kukamilisha barabara nchini Filipino.

  • Zana ya kuthibitisha ubora wa anwani OSMSuspects ya dooley sasa inapatikana kwa watumiaji wote tena. Ukiingia na akaunti yako ya OSM, unaweza kuona metadata.

  • Leif Rasmussen alipendekeza kuongeza ratiba ya usafiri katika OSM katika pendekezo. Kama ilivyovyotarajiwa, watu wengi hawakukubaliana na kuongeza ratiba katika maelezo yao kamili na ya kina.Ni kiasi kikubwa cha data, ambacho hubadilika mara nyingi. Itakuwa daima katika mtindo wa kizamani hivyo vigumu kutegemea.

  • Simon Poole hakubaliani na mazoezi ya sasa ya kugawanya vitambulisho kama languages=<code>;<code>;<code> na language:<code1>=yes + language:<code2>=yes. Anaona kuwa hii inafanya kuwa vigumu kwa watumiaji wa data na waandishi wa mhariri.

Jamii

  • Opencagedata.com imechapisha mahojiano na Russ Garrett wa OpenInfraMap.org. Russ, aliyekutana na Steve Coast katika baa mwaka 2005, anaongoza mradi wa OpenInfraMap.

  • Mshiriki wa kikundi cha kazi cha data mavl, aliripoti katika blogu yake kuhusu ujumbe za kwanza 1000 ambazo zimepokelewa kutoka kwa zana mpya ya kutoa taarifa ya openstreetmap.org. Karibu asilimia 60 ya taarifa hizo zilikuwa zinahusu watumiaji, ikifuatwa na maelezo ya OSM. Bila kujali kitu cha wasiwasi, sababu kuu ya ripoti ilikuwa spam

Taasisi ya OpenStreetMap

  • Frederik Ramm, mshirika wa bodi ya OSMF na mfadhili wa OSMF, aliripoti kuhusu uvumi wa makampuni mawili ambayo hayajajulikana ambayo "yanahamasisha" wafanyakazi wao kujiunga na OSMF,na kuwapa mapendekezo ya uchaguzi na kulipa ada ya uanachama.

  • Rory McCann anaeleza katika orodha ya barua pepe ya OSMF jinsi mwajiri anaweza waambia wafanyakazi wale ambao wanapaswa kupigia kura na jinsi hii inaweza kuthibitishwa licha ya "haijulikani" uchapisho wa kura.

  • Tunajiunga na Michael Reichert na wito wa watu wengine kuwa mwanachama wa OSMF. Mjumbe wa bodi tu anaweza kuhakikisha kwamba bodi ya OSMF itatenda daima kwa maslahi ya watengenezaji wa ramani. Ikiwa unataka kupiga kura katika uchaguzi wa mwaka huu,unapaswa kujiunga kabla ya Novemba 15. Aidha, karibu vikundi vyote vya kazi vya OSMF vinatafuta msaada.

  • OSMF imekuwa ikifanya kazi katika kurekebisha OpenStreetMap API (Rails Port and CGIMap) ili kuzingatia Kanuni ya Ulinzi ya Takwimu Mkuu na imetangaza ombi la zabuni kala ya 15 Novemba.

Matukio

  • Mkutano wa tatu wa State of the Map Czech utafanyika mnamo tarehe 17 hadi 18 mwezi wa Novemba 2018 katika mjii wa Brno.

OSM ya Kibinadamu

  • Shirika la Humanitarian OpenStreetMap Erasmus+ wanafunzi walitangaza katika tweet, kwamba walikuwa wameendesha kozi ya wiki-mrefu inayoitwa kufundisha walimu. Mpango huo ulikuwa na wigo mpana na mada ikiwamo kutengeneza ramani, programu ya Overpass, OSM Wiki, njia za mawasiliano na mengine. Mpango huu umeonyesha uwezekano wa OSM kwa majibu ya kibinadamu na msaada wa maendeleo ya kiuchumi na kupainia viongozi (ambao ni waenye hiari) .

  • HOT inahitaji usaidizi juu ya wiki chache zinazofuata, kutambua idadi ya wakimbizi wa Venezuela walio katika kisiwa cha Aruba.

  • Shirika la Humanitarian OpenStreetMap Team imemaliza kutengeneza ramani ya miundombinu, hasa majengo, barabara, na vipengele vya maji huko Semarang, mji mkuu wa tano wa Indonesia.

Ramani

  • Programu ya Magic Earth Navigation sasa inatumika katika programu ya CarPlay ya Apple baada ya sasisho la hivi karibuni, kulingana na hii ripoti (de) (tafsiri ya moja kwa moja).

  • Nicolas Bétheuil alieleza kuhusu ramani yake ya usafiri wa umma katika orodha ya burua pepe ya Kifaransa . (fr)(tafsiri ya moja kwa moja).

  • Template ya JOSM ya ramani ya Xmas ilirekebishwa na Negreheb kwa taarifa fupi (tafsiri ya moja kwa moja) ana akachapisha katika tovuti ya wiki (tafsiri ya moja kwa moja).

switch2OSM

  • Pristina, mji mkuu wa Kosovo, inatumia ramani ya OpenStreetMap kama ramani yao rasmi ya utalii. Stereo; (Guillaume Rischard) amendika makala kuhusu safari yake huko Kosovo, mkutano na jumuiya ya OSM, na kushawishi Manispaa ya Pristina kutumia ramani ya OpenStreetMap.

Open Data

  • OpenGeoHub imetangaza kutolewa kwa kwanza wa LandGIS, mfumo wa ramani ya wavuti iliyo sawa na OSM, ya data zinazohusika na ardhi na mazingira.Mradi huo inaeneza (au kwa maneno mengine inashindana) na OSM.

  • Statistics Canada imejadili kuhusu Open Database of Buildings, na inashirikiana na jumuiya ili kuagiza katika mikoa tofauti ya Canada.

Programu

  • Simon Poole aliandika kuhusu kutoendelea kwa Google Play ya Android 2.3 and 3.x katika blogu yake na nini inamaanisha kwa Vespucci, ambayo bado inatumia matoleo haya ya Android. Pia anaelezea jinsi ya kutumia Vespucci kwa vifaa ambavyo vina RAM iliyo chini sana

Programming

Vingine vya kijeographia

  • Justin O'Beirne ameandika makala kuhusu uchapishaji wa ramani mpya ya Apple na anaeleza jinsi ramani hizo ni tofauti na za zamani kwa kuonyesha mabadiliko ya kuvutia, kama kiasi cha kina cha mimea. Soma zaidi juu ya swala hili katika blogu yake.

Kumbuka: Ikiwa ungependa kuona tukio lako hapa, tafadhali ongeza tukio hilo kwenye kalenda. Data iliyopo tu ndiyo itaonekana kwenye weeklyOSM. Tafadhali angalia tukio lako katika kalenda yetu ya uma, hakikisha na sahihisha ambapo inafaa.

Facebook Fort McMurray Alberta

Posted by Respectfully on 4 December 2018 in English (English)

Facebook uses a filter to limit distances for interested items. Example the search will only take results from this area. Would someone be able to get the distance in kilometers please. Currently it is only in miles.

Kind regards and thank you in advance.

work

Posted by ALYAFA3 on 4 December 2018 in Arabic (العربية)

Hi there!

Location: Asdaf, المحرق‎, محافظة المحرق, 254, ‏البحرين‎

Some numbers about mailing lists (part 2): Number of messages per mailing list and year, most active authors since 2016

Posted by Nakaner on 3 December 2018 in English (English)

A new evening is a new evening to play around with SQL. This is part 2 of my series on the number of messages and the most active authors on the public mailing lists hosted a lists.openstreetmap.org. Part 1 was published on 2 December 2018.

Here are my latest queries and their results:

Numbers of messages per year

SELECT EXTRACT(YEAR FROM "date") AS year, COUNT(1) AS message_count
  FROM mails
  GROUP BY year
  ORDER BY year;

 year | message_count 
------+---------------
 2004 |           180
 2005 |          2343
 2006 |         10481
 2007 |         34059
 2008 |         70120
 2009 |        102357
 2010 |         96569
 2011 |         66484
 2012 |         69943
 2013 |         67428
 2014 |         55866
 2015 |         52484
 2016 |         38914
 2017 |         36815
 2018 |         34271

Numbers of messages per mailing list and year (2004–2008)

Mailing lists with less than 50 messages in all of these years are not shown in the following table. Rows are sorted by number of messages in their first year.

WITH
  postings_years AS (
    SELECT list_id, EXTRACT(YEAR FROM "date") AS year, COUNT(1) AS message_count                                                       
      FROM mails          
      GROUP BY list_id, year     
  ), 
  list_ids AS (
    SELECT list_id        
      FROM mails          
      GROUP BY list_id    
  )
SELECT *
  FROM (
    SELECT
        l.list_id AS list_id,
        y2004.message_count AS "2004",  
        y2005.message_count AS "2005",  
        y2006.message_count AS "2006",  
        y2007.message_count AS "2007",  
        y2008.message_count AS "2008"
      FROM list_ids AS l  
      LEFT OUTER JOIN postings_years AS y2004
        ON (l.list_id = y2004.list_id AND y2004.year = 2004)                                     
      LEFT OUTER JOIN postings_years AS y2005
        ON (l.list_id = y2005.list_id AND y2005.year = 2005)                                     
      LEFT OUTER JOIN postings_years AS y2006
        ON (l.list_id = y2006.list_id AND y2006.year = 2006)                                     
      LEFT OUTER JOIN postings_years AS y2007
        ON (l.list_id = y2007.list_id AND y2007.year = 2007)                                     
      LEFT OUTER JOIN postings_years AS y2008
        ON (l.list_id = y2008.list_id AND y2008.year = 2008)
      ORDER BY
        y2004.message_count DESC NULLS LAST,
        y2005.message_count DESC NULLS LAST,
        y2006.message_count DESC NULLS LAST,
        y2007.message_count DESC NULLS LAST,
        y2008.message_count DESC NULLS LAST,
        list_id
    ) AS stats
WHERE "2004" >= 50
  OR "2005" >= 50
  OR "2006" >= 50
  OR "2007" >= 50
  OR "2008" >= 50;

      list_id      | 2004 | 2005 | 2006 | 2007  | 2008  
-------------------+------+------+------+-------+-------
 talk              |  180 | 1771 | 7772 | 11656 | 11310
 dev               |      |  572 | 2119 |  5625 |  4979
 talk-gb           |      |      |  239 |  1952 |  1524
 talk-de           |      |      |  235 |  5953 | 26392
 legal-talk        |      |      |   47 |   452 |  1285
 talk-fr           |      |      |   42 |   763 |  4579
 talk-it           |      |      |   27 |   322 |  4381
 talk-nl           |      |      |      |  4107 |  3873
 talk-es           |      |      |      |   888 |  1473
 josm-dev          |      |      |      |   597 |  1689
 talk-cz           |      |      |      |   590 |  1727
 talk-au           |      |      |      |   487 |   771
 talk-za           |      |      |      |   184 |   104
 routing           |      |      |      |   162 |   432
 talk-tr           |      |      |      |   103 |    26
 party             |      |      |      |    69 |     7
 talk-ie           |      |      |      |    54 |   192
 talk-fi           |      |      |      |    52 |    30
 talk-se           |      |      |      |    19 |    58
 talk-us           |      |      |      |    13 |   619
 merkaartor        |      |      |      |       |  1001
 talk-ja           |      |      |      |       |   897
 talk-be           |      |      |      |       |   612
 talk-ca           |      |      |      |       |   471
 talk-at           |      |      |      |       |   441
 talk-ph           |      |      |      |       |   261
 talk-in           |      |      |      |       |   220
 talk-ar           |      |      |      |       |   181
 talk-gb-midanglia |      |      |      |       |   116
 legal-general     |      |      |      |       |   111
 talk-co           |      |      |      |       |   100
 talk-il           |      |      |      |       |    69
 talk-is           |      |      |      |       |    69
(33 rows)

Number of messages per mailing list and year (2009–2013)

Mailing lists with less than 50 messages in all of these years are not shown in the following table. Rows are sorted by number of messages in their first year.

WITH
  postings_years AS (
    SELECT list_id, EXTRACT(YEAR FROM "date") AS year, COUNT(1) AS message_count
      FROM mails
      GROUP BY list_id, year
  ),
  list_ids AS (
    SELECT list_id
      FROM mails
      GROUP BY list_id
  )
SELECT *
  FROM (
    SELECT
        l.list_id AS list_id,
        y2009.message_count AS "2009",
        y2010.message_count AS "2010",
        y2011.message_count AS "2011",
        y2012.message_count AS "2012",
        y2013.message_count AS "2013"
      FROM list_ids AS l
      LEFT OUTER JOIN postings_years AS y2009 ON (l.list_id = y2009.list_id AND y2009.year = 2009)
      LEFT OUTER JOIN postings_years AS y2010 ON (l.list_id = y2010.list_id AND y2010.year = 2010)
      LEFT OUTER JOIN postings_years AS y2011 ON (l.list_id = y2011.list_id AND y2011.year = 2011)
      LEFT OUTER JOIN postings_years AS y2012 ON (l.list_id = y2012.list_id AND y2012.year = 2012)
      LEFT OUTER JOIN postings_years AS y2013 ON (l.list_id = y2013.list_id AND y2013.year = 2013)
      ORDER BY
        y2009.message_count DESC NULLS LAST,
        y2010.message_count DESC NULLS LAST,
        y2011.message_count DESC NULLS LAST,
        y2012.message_count DESC NULLS LAST,
        y2013.message_count DESC NULLS LAST,
        list_id
    ) AS stats
WHERE "2009" >= 50
  OR "2010" >= 50
  OR "2011" >= 50
  OR "2012" >= 50
  OR "2013" >= 50;

        list_id        | 2009  | 2010  | 2011  | 2012  | 2013  
-----------------------+-------+-------+-------+-------+-------
 talk-de               | 28125 | 20392 | 10276 |  8758 |  6088
 talk                  | 13570 |  9296 |  5724 |  4095 |  3336
 talk-fr               | 11994 | 12072 |  9541 | 13755 | 12880
 talk-it               |  8267 |  7896 |  5182 |  6285 |  8046
 dev                   |  4720 |  3398 |  2613 |  2235 |  1236
 talk-au               |  3515 |  2617 |  1291 |  1019 |   450
 talk-gb               |  3358 |  3428 |  2027 |  1669 |  1386
 talk-nl               |  2511 |  1824 |  1236 |   721 |   328
 talk-us               |  1942 |  2436 |  2101 |  2885 |  2385
 talk-es               |  1892 |  2281 |  2121 |  2265 |  1063
 talk-cz               |  1729 |  2019 |   890 |  1064 |   888
 josm-dev              |  1587 |  1217 |   792 |   464 |   428
 talk-ca               |  1539 |  1511 |   832 |   895 |   659
 talk-ph               |  1345 |  1185 |   835 |   584 |   639
 talk-lv               |  1304 |   967 |  1724 |   985 |   543
 legal-talk            |  1291 |  2468 |  1226 |   510 |   310
 talk-at               |  1278 |   939 |   934 |  1640 |   990
 talk-ja               |  1224 |  1844 |  1667 |  1222 |   917
 tagging               |  1011 |  5118 |  2900 |  3368 |  3551
 talk-ro               |   944 |   786 |   292 |   238 |   606
 merkaartor            |   942 |  1022 |   158 |    94 |    20
 talk-br               |   901 |   971 |   480 |   671 |  1728
 talk-transit          |   858 |   391 |   290 |    50 |    83
 talk-in               |   824 |   355 |    92 |   210 |   177
 talk-hr               |   553 |   478 |   316 |   344 |   285
 imports               |   440 |   280 |   504 |   548 |   848
 osmosis-dev           |   418 |   446 |   317 |   249 |   140
 talk-be               |   416 |   674 |   733 |   921 |  2098
 talk-gb-westmidlands  |   364 |   261 |   237 |   300 |   229
 talk-co               |   363 |  1148 |   964 |   500 |   321
 talk-dk               |   357 |   708 |  1055 |  1063 |   411
 talk-is               |   269 |   207 |    65 |   145 |    92
 talk-za               |   257 |   189 |    78 |    82 |   176
 routing               |   247 |   233 |    78 |    76 |    14
 talk-ee               |   228 |   548 |   357 |   199 |   154
 talk-se               |   211 |   411 |   414 |   676 |   572
 talk-ar               |   211 |   244 |   219 |   155 |   289
 talk-lt               |   148 |   484 |   285 |   251 |   334
 talk-fr-bzh           |   117 |   114 |   290 |   279 |   194
 talk-gb-midanglia     |   114 |    48 |    62 |    16 |     8
 talk-cu               |   108 |    34 |       |    11 |     3
 talk-si               |   107 |    55 |    26 |    34 |     2
 talk-gb-oxoncotswolds |    87 |    20 |   101 |     8 |    85
 local-chapters        |    65 |   118 |    20 |       |    47
 geocoding             |    65 |    77 |    48 |   423 |   430
 talk-ie               |    61 |    50 |    64 |    26 |    44
 moderation            |    59 |    15 |       |       |      
 accessibility         |    55 |   101 |    55 |    75 |      
 talk-vi               |    54 |     1 |     1 |     7 |      
 potlatch-dev          |    51 |   326 |   984 |   540 |    79
 talk-cl               |    33 |   857 |   120 |    83 |    36
 talk-ko               |    21 |    34 |    11 |    67 |    11
 talk-pt               |    14 |    70 |   232 |   171 |   178
 talk-tr               |    12 |    18 |    21 |    38 |    64
 talk-pe               |     3 |    65 |    53 |   127 |    40
 hot                   |       |   456 |   861 |  1179 |  1787
 talk-ht               |       |   347 |    64 |   183 |   337
 talk-it-fvg           |       |   206 |    75 |    66 |   180
 strategic             |       |   185 |   398 |    14 |      
 dev-fr                |       |   140 |   480 |   821 |   449
 mapcss                |       |   134 |   116 |    61 |    65
 talk-ve               |       |    86 |   255 |   226 |    19
 talk-tw               |       |    53 |   112 |   467 |   412
 talk-rs               |       |    30 |   199 |    71 |     1
 talk-uy               |       |    12 |    17 |    24 |    68
 talk-it-piemonte      |       |       |   281 |   143 |    47
 rails-dev             |       |       |   187 |  1408 |  3458
 taginfo-dev           |       |       |    74 |    52 |    59
 talk-id               |       |       |    70 |    64 |    21
 talk-it-bici          |       |       |    54 |    47 |      
 talk-it-lazio         |       |       |    49 |    36 |   201
 talk-it-trentino      |       |       |    33 |   133 |   323
 talk-lu               |       |       |    33 |    59 |    16
 talk-np               |       |       |    14 |   163 |    31
 talk-it-liguria       |       |       |    13 |   513 |   153
 talk-pl               |       |       |     7 |   449 |   346
 rebuild               |       |       |       |   353 |      
 historic              |       |       |       |    72 |   265
 talk-sn               |       |       |       |    36 |   152
 talk-ni               |       |       |       |    15 |   310
 talk-baltics          |       |       |       |     5 |    91
 sotm-asia             |       |       |       |     4 |    86
 talk-mx               |       |       |       |     2 |    57
 tile-serving          |       |       |       |       |   778
 imports-us            |       |       |       |       |   481
 osrm-talk             |       |       |       |       |   359
 talk-cat              |       |       |       |       |   230
 diversity-talk        |       |       |       |       |   130
 talk-us-nps           |       |       |       |       |   106
 talk-it-southtyrol    |       |       |       |       |    69
 talk-it-sardinia      |       |       |       |       |    61
 talk-ke               |       |       |       |       |    61
(92 rows)

Some mailing lists changed their focus or became unnessary after some time. For example, the legal-talk mailing list became a bit more quiet after the license change in mid 2012 was over. The "rebuild" mailing list had the only purpose to discuss the decisions implemented in the Redaction Bot.

Number of messages per mailing list and year (2014 to November 2018)

Mailing lists with less than 50 messages in all of these years are not shown in the following table. Rows are sorted alphabetically by the ID of the mailing list.

WITH
  postings_years AS (
    SELECT list_id, EXTRACT(YEAR FROM "date") AS year, COUNT(1) AS message_count
      FROM mails
      GROUP BY list_id, year
  ),
  list_ids AS (
    SELECT list_id
      FROM mails
      GROUP BY list_id
  )
SELECT *
  FROM (
    SELECT
        l.list_id AS list_id,
        y2014.message_count AS "2014",
        y2015.message_count AS "2015",
        y2016.message_count AS "2016",
        y2017.message_count AS "2017",
        y2018.message_count AS "2018"
      FROM list_ids AS l
      LEFT OUTER JOIN postings_years AS y2014 ON (l.list_id = y2014.list_id AND y2014.year = 2014)
      LEFT OUTER JOIN postings_years AS y2015 ON (l.list_id = y2015.list_id AND y2015.year = 2015)
      LEFT OUTER JOIN postings_years AS y2016 ON (l.list_id = y2016.list_id AND y2016.year = 2016)
      LEFT OUTER JOIN postings_years AS y2017 ON (l.list_id = y2017.list_id AND y2017.year = 2017)
      LEFT OUTER JOIN postings_years AS y2018 ON (l.list_id = y2018.list_id AND y2018.year = 2018)
      ORDER BY
        list_id
    ) AS stats
WHERE "2014" >= 50
  OR "2015" >= 50
  OR "2016" >= 50
  OR "2017" >= 50
  OR "2018" >= 50;

        list_id        | 2014 | 2015 | 2016 | 2017 | 2018 
-----------------------+------+------+------+------+------
 dev                   |  596 |  758 |  633 |  393 |  390
 dev-fr                |  365 |  144 |   74 |   54 |   14
 dev-italia            |   90 |   16 |  165 |   11 |    5
 diversity-talk        |  118 |    4 |      |    5 |  100
 geocoding             |  318 |  300 |  104 |   57 |   29
 historic              |  205 |  380 |   55 |   83 |   59
 hot                   | 2669 | 3729 | 2088 | 1272 |  503
 hot-francophone       |  305 |  497 |  182 |  123 |  107
 imports               |  914 |  604 |  518 |  564 |  515
 imports-us            |  154 |   90 |   47 |   12 |   52
 josm-dev              |  288 |  437 |  172 |  157 |  217
 learnosm-coord        |   50 |   57 |    4 |      |     
 legal-talk            |  367 |  276 |  197 |   74 |   29
 osmf-membership       |    2 |   59 |      |      |     
 osmosis-dev           |   23 |   89 |   35 |   19 |   19
 osrm-talk             |  343 |  345 |  293 |  179 |  156
 potlatch-dev          |   14 |   22 |    2 |   71 |   12
 rails-dev             | 1309 | 1783 | 1781 | 2232 | 2494
 tagging               | 4685 | 7217 | 2803 | 3734 | 6602
 talk                  | 2814 | 3584 | 1975 | 2668 | 1778
 talk-africa           |      |    1 |   16 |  100 |  114
 talk-ar               |  228 |   77 |    4 |   11 |     
 talk-at               |  851 |  938 |  596 |  334 |  729
 talk-au               |  248 |  279 |  370 |  416 |  592
 talk-be               | 1119 | 1569 | 1234 |  837 |  260
 talk-bf               |   84 |   45 |   27 |   18 |    1
 talk-bj               |    3 |    5 |   26 |   64 |    5
 talk-blr              |    3 |   52 |      |      |     
 talk-bo               |   24 |   32 |  137 |  153 |  210
 talk-br               | 4412 | 1809 |  730 |  461 |  189
 talk-ca               |  370 |  311 |  906 |  611 |  679
 talk-cat              |  368 |  374 |   83 |   74 |   45
 talk-cl               |  106 |  110 |  165 |  159 |   83
 talk-cm               |   31 |    8 |    5 |   41 |   50
 talk-co               |  200 |  268 |  264 |  128 |   55
 talk-cu               |    1 |   13 |  131 |   42 |   35
 talk-cz               | 2290 | 1720 | 2594 | 2490 | 2140
 talk-de               | 3615 | 2306 | 1335 |  764 | 1138
 talk-dk               |  359 |  415 |  299 |  156 |  212
 talk-es               |  786 |  762 | 1121 |  814 |  856
 talk-fr               | 8479 | 5082 | 3690 | 4110 | 4008
 talk-fr-bzh           |  399 |  332 |  157 |  153 |  169
 talk-gb               | 1300 | 1136 | 1524 | 1390 | 1151
 talk-gb-westmidlands  |  262 |  161 |  123 |  180 |   65
 talk-gh               |    1 |   44 |   30 |   77 |   74
 talk-hr               |  238 |  164 |   35 |   32 |   65
 talk-ht               |  144 |   62 |  131 |   72 |   46
 talk-ie               |  352 |  481 |  297 |  298 |  159
 talk-in               |  125 |  362 |  271 |  275 |  189
 talk-it               | 5730 | 4646 | 5645 | 4843 | 3675
 talk-it-cai           |      |      |      |  336 |  173
 talk-it-fvg           |  139 |  219 |  269 |  236 |   96
 talk-it-lazio         |   64 |   23 |   47 |  231 |   98
 talk-it-liguria       |   73 |   19 |   12 |   10 |    2
 talk-it-piemonte      |  118 |   49 |   17 |   73 |  113
 talk-it-sardinia      |  110 |   12 |   28 |      |     
 talk-it-southtyrol    |   69 |   10 |      |    2 |    1
 talk-it-trentino      |  163 |  159 |  277 |   71 |   68
 talk-ja               |  635 |  543 |  356 |  378 |  370
 talk-ko               |   26 |   30 |    5 |   97 |   36
 talk-latam            |  165 |  235 |  167 |  119 |   70
 talk-lt               |   81 |  122 |  215 |  163 |   86
 talk-lv               |  153 |  132 |   57 |   63 |   28
 talk-mg               |      |   68 |   20 |   28 |   46
 talk-ml               |    9 |  101 |   33 |   29 |    4
 talk-mx               |  139 |  252 |  127 |   79 |   53
 talk-ni               |  169 |  113 |  125 |   59 |   29
 talk-nl               |  417 |  199 |  133 |   53 |   33
 talk-pe               |   71 |  187 |  137 |   40 |   12
 talk-ph               |  547 |  356 |  177 |  155 |  117
 talk-pl               |  726 |  614 |  531 |   74 |   98
 talk-pr               |  142 |   92 |   53 |   29 |    4
 talk-pt               |  372 |  190 |  110 |  113 |   71
 talk-ro               |  204 |  134 |   39 |    2 |    3
 talk-scotland         |   26 |   69 |   42 |   96 |   39
 talk-se               |  230 |  146 |  247 |  263 |  129
 talk-sn               |   64 |  114 |  113 |   75 |   57
 talk-tn               |      |      |   58 |   58 |   37
 talk-transit          |   33 |   42 |   51 |   11 |  131
 talk-tw               |   91 |   54 |   64 |   13 |   18
 talk-us               | 1552 | 1771 | 1108 | 1300 |  847
 talk-us-massachusetts |      |      |   37 |  114 |  248
 tile-serving          |  908 | 1870 |  709 | 1006 |  648
 umap                  |   17 |   49 |   79 |   63 |   36
(84 rows)

Top Authors per Year

SELECT 
    row_number() OVER (ORDER BY message_count DESC) AS rank,
    author,
    message_count
  FROM (
    SELECT
        from_short AS author,
        COUNT(1) AS message_count
      FROM mails
      WHERE
        EXTRACT(YEAR FROM "date") = 2018
        AND from_short NOT IN ('notifications@github.com', 'theweekly.osm@gmail.com')
      GROUP BY author
      ORDER BY message_count DESC
  ) AS a
  LIMIT 20;

 rank |          author           | message_count 
------+---------------------------+---------------
    1 | Martin Koppenhoefer       |          1819
    2 | Warin                     |           569
    3 | Marc Marc                 |           554
    4 | Philippe Verdy            |           506
    5 | Mateusz Konieczny         |           478
    6 | Giovanni Cascafico        |           344
    7 | Paul Allen                |           322
    8 | Graeme Fitzpatrick        |           295
    9 | François Lacombe          |           272
   10 | Simone Girardelli         |           271
   11 | Marián Kyral              |           271
   12 | Christoph Hormann         |           257
   13 | Tom Ka                    |           249
   14 | Volker Schmidt            |           248
   15 | Polyglot                  |           244
   16 | majka                     |           244
   17 | Frederik Ramm             |           236
   18 | Javier Sánchez Portero    |           230
   19 | John Whelan               |           229
   20 | Christan Quest            |           226
(20 rows)

SELECT 
    row_number() OVER (ORDER BY message_count DESC) AS rank,
    author,
    message_count
  FROM (
    SELECT
        from_short AS author,
        COUNT(1) AS message_count
      FROM mails
      WHERE
        EXTRACT(YEAR FROM "date") = 2017
        AND from_short NOT IN ('notifications@github.com', 'theweekly.osm@gmail.com')
      GROUP BY author
      ORDER BY message_count DESC
  ) AS a
  LIMIT 20;

 rank |              author              | message_count 
------+----------------------------------+---------------
    1 | Martin Koppenhoefer              |          1598
    2 | Philippe Verdy                   |           581
    3 | Marc Marc                        |           499
    4 | Marián Kyral                     |           481
    5 | Warin                            |           414
    6 | Marc Gemis                       |           372
    7 | Giovanni Cascafico               |           357
    8 | Simone Girardelli                |           352
    9 | John Whelan                      |           351
   10 | osm.sanspourriel                 |           296
   11 | Christian Quest                  |           291
   12 | Andy Townsend                    |           248
   13 | Volker Schmidt                   |           235
   14 | LogicalViolinist/James2432       |           233
   15 | Polyglot                         |           229
   16 | Frederik Ramm                    |           225
   17 | Dave F                           |           222
   18 | Alessandro Palmas                |           221
   19 | Joost Schouppe                   |           210
   20 | Paul Johnson                     |           210
(20 rows)


SELECT 
    row_number() OVER (ORDER BY message_count DESC) AS rank,
    author,
    message_count
  FROM (
    SELECT
        from_short AS author,
        COUNT(1) AS message_count
      FROM mails
      WHERE
        EXTRACT(YEAR FROM "date") = 2016
        AND from_short NOT IN ('notifications@github.com', 'theweekly.osm@gmail.com')
      GROUP BY author
      ORDER BY message_count DESC
  ) AS a
  LIMIT 20;

 rank |              author              | message_count 
------+----------------------------------+---------------
    1 | Martin Koppenhoefer              |          1781
    2 | Philippe Verdy                   |           506
    3 | Marián Kyral                     |           431
    4 | Simone Girardelli                |           394
    5 | Marc Gemis                       |           385
    6 | John Whelan                      |           347
    7 | osm.sanspourriel                 |           319
    8 | Christan Quest                   |           315
    9 | Giovanni Cascafico               |           306
   10 | Joost Schouppe                   |           302
   11 | Warin                            |           267
   12 | Polyglot                         |           245
   13 | Luca Delucchi                    |           240
   14 | Frederico Cortese                |           224
   15 | Maurizio Napolitano              |           223
   16 | Frederik Ramm                    |           223
   17 | Andrea Lattmann                  |           222
   18 | LogicalViolinist/James2432       |           220
   19 | Colin Smale                      |           215
   20 | Andy Townsend                    |           211
(20 rows)

I converted the email addresses into names manually by entering all email addresses into Google. While copying the results, I noticed that among the top 20 posters since 2016 only a few seem to have English as their native language. There are a lot of people from the French, Italian and Czech community. This is no surprise if you look for the most active mailing lists (see table above).

The OSMF-Talk mailing list was not taken into account for all these numbers (and it was not taken into account for the numbers published in part 1).

This list of the most active posters measured in messages per year will follow in the next part of this series. If you have any other suggestions what to query, don't hesitate to comment.

I would like to ask all who intend to write a comment to stay on topic and don't repeat themselves.