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.
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
در تگ 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
06.11.2018-12.11.2018
Picha
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
kwamba atasimama kama mgombea wa uchaguzi wa bodi ya OSMF.
Matukio
HOT ilitangaza mkutano wa HOT Summit 2019 utafanyika mnamo tarehe 19-20, Septemba huko Heidelberg, Germany.
Mkutano wa FOSS4G 2018 Okayama
(Okayama) ulifanyika mnamo tarehe 4-5 Novemba, mkutano wa FOSS4G 2018 Tokyo ulifanyika mnamo tarehe 9-10 Novemba. Tweets
kuhusiana na matukio hayo yote yalikusanywa .Kikundi cha meetup cha Montana GIS and Geospatial ilikuwa na mkutano wa kutengeneza ramani huko Helena, Montana ya GIS Day mnamo tarehe 14 Novemba. Washiriki walifahamika na zana za OSM na kuchangia kwa HOT task #5355 - Missing Maps: Myanmar.
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 (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
- Gazeti la mtandaoni ya Brazil imeripoti kuhusu Geochicas kujaribu kutumia 'Las calles de las mujeres' ili kutekeleza tahadhari kwa njia zilizoitwa baada ya wanawake muhimu.
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 |
|
|Mannheim |Mannheimer Mapathons |2018-11-15 |
|
|Freiberg |Stammtisch |2018-11-15 | |
|Pamplona |Mapatón Pamplona - Médicos sin Fronteras |2018-11-16 |
|
|Barcelona |Mapes i Birres (Trobada trimestral usuaris d'OSM) |2018-11-16 | |
|Como |ItWikiCon 2018 |2018-11-16-2018-11-18|
|
|Como |Mapping Party during ItWikiCon 2018 |2018-11-17 | |
|Brno |State of the Map CZ 2018 |2018-11-17 |
|
|Bengaluru |State of the Map Asia 2018 |2018-11-17-2018-11-18|
|
|Vantaa |OSM GeoWeek 24h HOT Mapathon |2018-11-17-2018-11-18|
|
|Wakayama |オープンデータソン in 雑賀崎 |2018-11-18 |
|
|Cologne Bonn Airport |Bonner Stammtisch |2018-11-20 | |
|Lüneburg |Lüneburger Mappertreffen |2018-11-20 | |
|Derby |Pub Meetup |2018-11-20 |
|
|Reading |Reading Missing Maps Mapathon |2018-11-20 | |
|Melbourne |FOSS4G SotM Oceania 2018 |2018-11-20-2018-11-23|
|
|Toulouse |Rencontre mensuelle |2018-11-21 |
|
|Karlsruhe |Stammtisch |2018-11-21 | |
|Lübeck |Lübecker Mappertreffen |2018-11-22 | |
|Alajuela |ES:State of the Map Costa Rica |2018-11-23-2018-11-25|
|
|Manila |【MapaTime!】 |2018-11-24 |
|
|Dublin |Monthly Mapping Party |2018-11-24 |
|
|Ivrea |Incontro mensile |2018-11-24 | |
|Graz |Stammtisch Graz |2018-11-26 |
|
|Bremen |Bremer Mappertreffen |2018-11-26 | |
|Arlon |Espace public numérique d'Arlon - Formation Contribuer à OpenStreetMap|2018-11-27 |
|
|Reutti |Stammtisch Ulmer Alb |2018-11-27 | |
|Düsseldorf |Stammtisch |2018-11-28 | |
|San José |Civic Hack Night & Map Night[1] |2018-11-28 |
|
|Toronto |Mappy Hour |2018-12-03 |
|
|Praha - Brno - Ostrava|Kvartální pivo |2018-12-05 | |
|Stuttgart |Stuttgarter Stammtisch |2018-12-05 | |
|Toulouse |Rencontre mensuelle |2018-12-05 | |
|Bochum |Mappertreffen |2018-12-06 | |
|Dresden |Stammtisch Dresden |2018-12-06 | |
|online via IRC |Foundation Annual General Meeting |2018-12-15 ||
|Heidelberg |State of the Map 2019 (international conference) |2019-09-21-2019-09-23| |
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)
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.
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 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:
- Creating a new object
- Slightly editing an existing object's geometry (move the nodes around in a way)
- Majorly editing an existing object's geometry (delete or add nodes in a way)
- Edit an existing object's attributes (tag changes)
- 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:
- Download Jupyter
- Clone this repository: jenningsanderson/sotmus-analysis
- 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
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!
Сумерки Ночной клуб / SUMERKI Disco club
Posted by Артем «Тёмич» Сидоренко on 5 December 2018 in Russian (Русский)Добавьте пожалуйста правильный адрес клуба)
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!
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/
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! -> 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:
vs
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:
(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...
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.
30.10.2018-05.11.2018
Picha
Pristina, mji mkuu wa Kosovo, imetengeneza ramani yao rasmi ya utalii na OpenStreetMap na MapOSMatic^1^. | © OpenStreetMap contributors na Manispaa ya Pristina
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_boxkatika 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>nalanguage:<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
(tafsiri ya moja kwa moja).Nicolas Bétheuil alieleza kuhusu ramani yake ya usafiri wa umma katika orodha ya burua pepe ya Kifaransa .
(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
- Project-insanity ameandika makala kuhusu hatua zinazohusika katika kutengeneza mwenyewe ramani ya Mapbox GL JS.
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 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.
Hi there!
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.