Diary Entries in English

Recent diary entries

Posted by combloop on 21 January 2020 in English.

It took a really long time, but I’m finally done editing the map around Teaneck for now! There were many periods of inactivity, but today I’ve finally finished.

The amount of time that Teaneck took to map is really long, and I feel that this has something to do with not only its geographic size but also its population. Teaneck is the second most populous municipality in Bergen County, with neighboring Hackensack being the most populous.

Next up is North Arlington, and after that will be Fort Lee. I hope that North Arlington will be way quicker to complete.

Click below to see Teaneck!

Location: Teaneck Township, Bergen County, New Jersey, United States
Posted by prispe on 21 January 2020 in English.

December 2019, Unique Mappers Team mapped Erute village in Enugu state Nigeria. In that village, there’s a hill that produces mushrooms year and the team (covered) mapped the hill and the villages around. We the team, used Kobotookbox for data collection the attributes and vocational data. For me, it was fun and new experience in using Kobotookbox.

Posted by Uyan on 21 January 2020 in English.

Something I’ve come across numerous times during the validation process have been unnamed highways. Given how little experience I have mapping roads, I must say that I don’t know what the problem is. These highways are always tagged, but I’m guessing they’re missing their official name e.g. Blue Ridge Parkway.

I wouldn’t know where to get these names except from other mapping services, since if I understand correctly we should not use them as it is not first-hand data (open-source aiming to “build from from the ground up”). And I feel like I’m at the point where I can no longer simply brush off all these warnings, which might indicate that I need to step away from the validation process to take a crash course in road mapping. Perhaps it is that which will lead me down the road to riches.

At the first meeting of the new OSMF Board, we discussed forming a Diversity Working Group, and I was charged to draft a scope of work. I appreciate the opportunity to take up the task to help get this effort moving. It’s fair to say that we all want participation in OpenStreetMap and the Foundation to be more representative of the whole of OSM and the world we want to map. This post sketches my thoughts on how we got here, and what this could look like. I’d love feedback. After some period of discussion, I’ll help organize a meeting (or set of meetings to accommodate time zones) to kick things off.

As background, the topic of diversity has been active for a long time in OpenStreetMap, in posts and mailing lists, including the dedicated diversity-talk@ list, discussed in Board election statements and QA for several years and at Board face to face meetings, and in person sessions at State of the Map. This year’s Board election of all white men from Europe and North America prompted active discussion across Twitter, OSM Diaries, and within the board email group. This discussion was at times difficult, and other times was productive. It became clear to me that there is a wide range of impression on what we all mean by “diversity”, the degree to which it’s a problem, if things should change, and how that change might be accomplished.

These discussions provide us with a broad set of topics to start thinking about an OSMF working group. I find it daunting, but at the same time we are provided with much to reflect on and work through on the topic of diversity. As the OSMF board, we are in a position to help the community channel these discussions into productive, impactful, data-driven and community oriented group. Structurally, this could take the form of a full working group, a working group with a time delimited lifespan, or a Board committee.

Here’s a proposal for questions the group might address

See full entry

Posted by El'Victor on 21 January 2020 in English.

TRAININGS: I received several trainings on open street mapping and GIS at large especially via webinars mostly organized by Victor N. Sunday the National Coordinator UniqueMappers OSM Nigeria. OSM GEOWEEK: I organized a training session at the Nigeria national youth service commission’s orientation camp Asaya Kabba/Bunu Local Government Area of Kogi State Nigeria handled by Geoffrey Kateregga.
NEW CHAPTER CREATION: UniqueMappersTeam Kogi a state chapter of UniqueMappersTeam Nigeria created as a result of the training session handled by Geoffrey Kateregga at the Nigeria national youth service commission’s orientation camp Asaya.
SOTM SUMMIT: I got partial scholarship from HOT to attend the HOT summit at Germany but I couldn’t obtain my Visa as result of the scholarship coming so close to the date of the summit. SOTM AFRICA: I got scholarship to attend SOTM Africa 2019 at Grand Bassam, Ivory Coast. I also attended Understanding Risk conference organized by World Bank in collaboration with OSM Africa for SOTM Africa 2019. UniqueMappersTeam: We had community training relevant to the growth and expansion of OpenStreetMap Nigeria community hosted by Victor N. Sunday the National Coordinator UniqueMappers OSM Nigeria.

Location: Zokoja, Lokoja, Kogi State, 260101, Nigeria
Posted by wille on 19 January 2020 in English. Last updated on 20 January 2020.

Some of the most important elements in the OpenStreetMap database are relations. It’s used to define administrative boundaries, restrictions on the road network (which has a relevant impact on routes), elements made by multiple geometries, etc. Relations are also some of the most difficult elements to monitor and track modifications, as some of them don’t affect the way the data is rendered on the map.

This week we added the possibility to visualize relations on OSMCha! To avoid increasing the number of elements rendered on the map, the visualization of relations works in a bit different way…

osmcha relations

By default, we show the bounding box of all relations that were created, modified or deleted by a changeset. When you click on a relation, it will hide all other ways and nodes and add to the map the elements that are (or were) members of that relation.

See full entry

I’ve been trying some light contributions to OSM’s Chef repository. In the OpenAddresses project we learned early that reliable and responsive continuous testing and integration make it easier for contributors to approach our project, and I’m hoping to build similar tests for OSM Chef. We already do a basic syntax lint, but these new tests would run each complete cookbook on a clean disposable host and notify Github of the results:

kitchen test --parallel --destroy=always all && notify-passed || notify-failed

Contributors would see an additional green check-mark in their pull requests, and OSM admins would be able to accept contributions confident that they’ve been fully tested.

Why Mess With Chef?

I’ve been in a long conversation with Andy Allan about small ways to help with OSM’s operational infrastructure. He nudged me in the direction of OSM’s Chef configuration, which shouldn’t be a surprise: Chef is how OSM manages the configuration of all the servers run by the OpenStreetMap Foundation’s Operations Working Group. Contributions to Chef are specifically cited in Andy’s Getting Involved post and mentioned in policies for both the Operations Working Group (OWG) and the Sysadmins group.

Andy recommended that I pay special attention to the Wiki cookbook: it’s the system that has the most outside interest from non-sysadmins over the last three years. For people who would like to change the configuration of wiki.openstreetmap.org a working cookbook would make it easier to test locally with test-kitchen and offer contributions that are known to work prior to deployment. Today, “we only find out if the changes actually work when we run them on the live servers.”

See full entry

Posted by Valor Naram on 18 January 2020 in English. Last updated on 3 March 2020.

There’s an ongoing questionnaire I’ve started to see what did it effort to motivate mappers to participate, to join OSM and to help to improve the map. This little diary provides an anonymized overview of the answers:

Survey

  • Opportunity to help providing an alternative source for geo-data that is corporative and free for all.
  • Opportunity to access free topography data.
  • Opportunity to see changes on the map immediately instead of days or months after. This way you get a good reward yourself (you feel like “Oh wow! That was just me! I helped to improve something sustainable and innovative!”).
  • OSM is more detailed than the maps of other Map Providers.
  • Saw that objects were missing on the map
  • Free license
  • Privacy
  • Enjoying that people come together, work together and make something non-commercially.
  • OSM allows “creative use of geodata”, allows more than just one user group to profit from.
  • Geodata can be used offline.
  • Enjoy that you can improve the map by yourself rather than relaying on others.
  • Enjoy that you get to know the world around you better.
  • Your contributions are yours and not Googles or some other company.
  • I can actually help people to navigate and find places better.
  • Spotted a mistake and enjoyed that I can improve it right away.
  • I love the friendly community.
  • The maps in my area from various map providers were catastrophic.

Result of the survey

The result is a promotional text we will use for Hamburg but which can also be used in other cities and countries with slight differences:

Variation 1 (Translated from german)

The open project OpenStreetMap aims to create free map data for walkers, car drivers, cyclists, hiker and many more. Our collected data are used by HVV (Hamburger Verkehrsverbund) and the Tagesschau but also by games such as Pokemon Go. Everybody can participate. You don’t need any technical background or to know how to work with maps.

Variation 2

See full entry

Posted by n76 on 17 January 2020 in English.

My native language is a dialect of the lingua franca of the late 20th and early 21st centuries. And I live in a culture that is notorious for being adamantly monolingual. But I thought I had some understanding of the issues of mapping names in a way friendly for internationalization.

It seems pretty clear cut when you read the wiki. Put the local name, in the local language, as the value for the “name” tag. You may also put it in the “name:<lg>” tag value too.

To be clear, I am not worrying about the legal name, short name, international name, alternate name, or other various names for a place. Just “the common default name” to put in the “name” tag.

I make paper maps for myself and if traveling like to have both the local name as I will find on signs and the name in English, if available, both rendered. For example:

काठमाडौ
Kathmandu

I may not be able to read the local language but I can compare the glyphs on my map with the glyphs on a sign to see I am entering a specific village. And if an English name exists, even if only (automatic) transliteration, I will have something to verbalize.

But my attempt to produce a map of a trekking destination in Nepal showed that it is not that simple.

First, the local mappers in Kathmandu and apparently throughout Nepal decided to put “Romanized” versions of their names in the name tag. I am not sure what “Romanized” means in this context as they did not specify what phonetics might be used when “Romanizing”. The current tagging of Kathmandu breaks Internationalization:

name=Kathmandu
name:ne=काठमाडौ

Please, please, don’t do this. It is specifically discouraged in the wiki. If a transliteration is needed, it can be done automatically by the data consumer. The tagging should be:

name=काठमाडौ
name:ne=काठमाडौ

See full entry