Recent diary entries
Missing Maps Leaderboard Updates
When Missing Maps started, it was impossible to imagine what it would ultimately become. The goal was to simply make more open map data available before disasters and to help the Humanitarian OpenStreetMap Team build more local mapping communities.
Early on we realized we needed better ways to quantify and track the impact of Missing Maps to OSM. Nearly 4 years later, we are making great progress on both of those fronts. Our efforts eventually produced the Missing Maps leaderboards, which sought to track individual users and teams.
The Missing Maps leaderboard technology is a streaming, real-time look at who is supporting our work. Initially funded by the Cisco Foundation, the leaderboards became a major way to engage and reward mappers. We were blown away when 4,000 mappers helped out on Missing Maps projects during the first year. Four years later, 52,000 mappers contributed to 1,200 mapping Missing Maps projects, the vast majority of those mappers were making their very first edits to OSM. In 2017, 10% of all new OSM mappers made their first edits in support of Missing Maps. The scale of tracking all these new users created problems for our system.
Thanks to a generous grant from Microsoft Philanthropies, Pacific Atlas migrated the stack to Microsoft Azure, completed a full analysis backfill, and rewrote large chunks to enable things to scale better in the future without dropping edits. As always, all the code is open, including the leaderboard code and the osm-stats infrastructure. We are always looking for help to create new badges or suggest new ideas.
- Total Contributors: We did a complete backfill of OSM history using OSMesa to capture dropped edits and editors (and to update our calculations). You'll notice that our number of total contributors is well over 52,000 now.
- Total Edits: The total number of edits has increased.
- Building Edits: This is a big change. In the past we we tracked Buildings Added to OSM. After doing some reflection, this wasn't a good representation of the total volume of edits Missing Maps contributes. Building Edits now reflects both new additions and the contributions of our validators to clean up and coach new mappers.
- Road Measurements: We've got some egg on our face here. We fixed some math errors (briefly: edits were counting the full length) and we are now correctly reporting the total km of roads added and edited.
- New Data: We now have data for all changesets (previously we'd only been tracking
#hashtaggedones). This means that user profile pages now include all edits made, rather than only those associated with hashtags. Users can still find their contribution to an individual hashtag by searching for the hashtag and user name in the leaderboards.
- More POIs: Edits with
amenity=*were previously the only POIs accounted for; we've expanded the set of tags tracked to better match Missing Maps editing activity.
- New Leaders: With the new data we've got some new leaders. I'm totally amazed at the commitment and dedication of Missing Maps mappers. From the first-time mapathon volunteer who manages to complete 40 buildings to the repeat mappers who make literally hundreds of thousands of edits.
- User Map: We changed the way the user contribution map is showing. Instead of a heatmap, we now display a simple choropleth that breaks down contributions by country.
- Badges: We dropped support for the GPS Tracks Badge. We weren't seeing a big uptick in new tracks added to OSM and this is already supported on the OSM user profiles.
- Slightly less real-time: Due to the increased volume of data that we're tracking, we had to reduce the aggregation frequency in order to keep things sprightly. Expect data to update approximately every 10-15 minutes.
- OSM Stats API: OSM Stats API now supports some additional queries and options, not all of which are documented yet but will be in the coming days.
- OSM Stats Workers: OSM Stats Workers was almost completely rewritten; metric calculations have been simplified and stream handling made more robust.
Today, v4.9.0 of the openstreetmap-carto stylesheet (the default stylesheet on the OSM website) has been released. Once changes are deployed on the openstreetmap.org it will take couple of days before all tiles show the new rendering.
- A bug where closed ways with natural=cliff or natural=tree_row were not rendering has been fixed. This required fixing a transform bug. The fix will apply to all objects when they are created in OSM, but there is no migration for existing databases. Deployments will have to decide if the effects are serious enough to require them to reload the database.
- Adding place=square name rendering
- Adding rendering for different types of towers and masts
- Making gardens to use grass color with plant nursery pattern
- Adding rendering for intermittent water bodies
- Give oceans outline and simplify shapefiles on z0-7
- Simplify (generalize) admin borders
- Move natural=grassland and landuse=meadow earlier
- Start rendering aerialway name
- Adding icons for amenity=bbq, amenity=shower, leisure=sauna and advertising=column
- Adding special icons for shop=dairy, shop=medical_supply and shop=music
- Move amenity=toilets to higher zoom levels
- Fixing some SVG icons artifacts
- Make military=danger_area font dark pink and slanted
- Changing rendering for construction=steps to distinguish it from roads
- Changing label colour of private parking
- Small documentation and code fixes
Thanks to all the contributors for this release, including james2432, Penegal and jragusa, new contributors.
For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v4.8.0...v4.9.0
As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues
Yesterday, a unit of the Social Welfare Department organized and hosted MapaBabae - an OpenStreetMap workshop for Women, with Women - in their central office in Quezon City, to mark Women's Month, and to introduce OSM as a tool for mapping, and to promote the value of diversity and inclusiveness in any community.
Kudos to the organizers for a refreshing take of mapa-thons, and the interesting discussion about language, empowerment, the potentials of open data in their work.
Jen, draws inspiration from the local Geo Ladies first (and only?) meet-up from 2014
As with other mapping activities, they also learned and edited maps of their communities. However, I found the discussions, and questions, more interesting.
A notable query was: "what's the tag for baby feeding rooms?" I did a quick search, and to my surprise (and dismay), there's no accepted convention. And yet, a proposal for baby_care was made in 2015.
I wish to see (and hope to support) more outreach activities to encourage diverse participation, and with more people organizing thematic mapping activities, to help map the communities they live in, work with, or simply because they love to map. The challenge of gender and language (and even the use of "mapa-thon") as a possible discouragement to mapping was eye-opening.
Helping change the ratio. 17:24
There are a few more photos here.
Turn restrictions are pretty common to OSM, them being the second most popular relation type, after multipolygons. Usually a restriction is a relation with two highway ways, "from" and "to" and a "via" member connecting these. The value of "restriction" tag adds a meaning: which kind of turn is forbidden on this route. For example, "restriction=no_left_turn" (and any other no_* value) forbids going from "from" to "to" way using "via" intermediate objects. Alternatively there are "only_*" values, forbidding any routes from the "from" way except the one leading to "to".
Usually "via" members are nodes, which makes them redundant for all types of restrictions except "no_u_turn" (which has the same way in "from" and "to" roles). Thus supporting them in a routing libraries has been easy. But — a "via" member can also be a way. For example, on a dual-carriageway, like the one pictured below. Supporting ways for "via" members is hard, but they constitute less than 3% of all restriction relations, so developers have often ignored these.
On the 5th of March, a new major version of iD editor was released. Among the changes, one stands out: the restriction editor got a big update. Now — finally — it allows adding "only_straight_on" restrictions (and others of the kind). And using ways in "via" roles. It looks awesome, and I'd like to thank Bryan for this feature. It is very intuitive, and I like that the iD team puts user experience first.
This change will obviously affect the number of restriction relations that have ways in "via" roles. And these have been hard to deal with. I don't know if all routing engines support such restrictions. MAPS.ME currently does not.
So to decide if supporting these restrictions should be a priority, I conducted a small research on how the change to the editor affected the map. First, I looked at the number of restriction relations by "last edited" date:
The black vertical line marks the day before the announcement.
You can clearly see that after the announcement, mappers started adding all kinds of restrictions, not just the new supported types. The most popular kind are "no_*" restrictions (e.g. "no_left_turn") with a node in the "via" role. But you can notice the surge in "only_*" restrictions (e.g. "only_straight_on") after the announcement, which by now has almost receded to the pre-March levels, ~100 a day. And there is a clear rise in new relations having ways in the "via" roles, from 10-20 before the new iD version, to 50-200 (!) after. While coming in waves, the number does not seem to decline.
Let's calculate percentages of these previously rare kinds of relations:
I have extended the period a bit, to account for a "calm" two-month period. Obviously, the rate of "only_*"-type restrictions did not change at all. The increase in their absolute numbers coincided with the similar increase in relations of other types.
But the percentage of relations with ways in "via" roles has definitely started to rise. From 3-5% before the new iD to 10% and rising after. It is entirely possible this line will settle on around 15-20%, which means around 300-400 new such relations every day. Which means, if you make a routing engine, you can no longer ignore relations with ways in "via" roles.
Traditionally such relations were made for restricting u-turns on a double-carriage highways. This chart confirms it:
The main increase is still in u-turn restrictions: as many as 260 a day the week after the announcement. Naturally, a developer might think they need to implement the support for only that type of a relation with a way in "via" role. It probably could be done with some kind of a shortcut patch.
Alas, other types of restrictions with ways as "via" are no longer virtually non-existent. From 1-2 a day, mappers now add 20-40 relations of other types daily. Here is the list of restriction types for relations with "via" member ways (thanks Roland and Martin for the Overpass stack!):
- 23429 no_u_turn
- 690 no_left_turn
- 442 only_straight_on
- 386 no_right_turn
- 240 no_straight_on
- 185 only_left_turn
- 114 only_right_turn
- 7 only_u_turn
Okay, no way around this issue. Looks like any routing engine that does not support ways in "via" roles won't be able to route properly from now on. And we in MAPS.ME have to catch up.
But... Is that all? Let me show you this:
Yay, iD editor supports restrictions that span two and more ways! We had 800 such relations in total before March, and in just two weeks mappers have added 150 more. I am pretty sure there are no more than two routing engines supporting such chains of "via" members, and that's being generous. So — get to work, developers: the routing over OpenStreetMap has just got much more complicated.
I had not taken OSM seriously until I began to need info and wanted to correct current map information in my locality. But I only edit maps here whenever I am in the mood or when I have time. In the early part of my mapping on osm, a great part of that was dedicated to correcting info on places that I am very familiar with.
My being female of the species has not really concerned me until I read an article today regarding the small percentage of women among mappers. In the listed members of WikiProject Philippines, I could see that I am only 1 of about 4 female names among 49 contributors. This made me edit Preferences on my wikipage. I clicked on "She edits wiki pages" on the question, "How do you prefer to be described?"
Let me emphasize another fact.
I belong to an indigenous community.
I am a full-blooded indigenous person.
OSM SHANTOU PROJECT
Greeting to all OSM editors,
As (former) local citizen of Shantou city I've recently begun to edit the Shantou Area OSM (Wikipedia of Shantou: https://en.wikipedia.org/wiki/Shantou). The project is not, however, limited to Shantou municipal area. Several modifications of mine were located in Jieyang and Chaozhou (the Chaoshan Intl. Airport and Chaoshan Railway Station as well as their proximity areas).
So far I've completed some blocks of the center city area of Shantou, particularly those around big commercial center, schools and some hospitals. The airport and railway stations are also completed from my point of view.
Since I've lived in the center city, the local knowledge serves well.
Generally there are already some works done at Shantou area: most of the main streets and highways, the coastline. I believe that there were some OSM editors who had already made some contributions (probably students of Shantou University since there is a well structured STU area on OSM now).
The project consists rougly of:
- The center of the Shantou City (Jinping* and Longhu Districts): buildings, neighbourhoods, local streets and alleys, etc. which is relatively easy for me to complete.
- The rural area (Chenhai, Haojiang, Chaoyang, Chaonan Districts, of which I don't possess enough local knowledge for these areas).
- The island Nao'ao County: I've made some modifications about the landscapes and added some buildings but it's far from done.
The project can be expanded to a Grand Chaoshan Area Project if local editors of Chaozhou and Jieyang City join in.
- It would be very interesting if the historical area of Jinping District (老市区), especially the area of Sun Yet-Sen Memorial Pavilion (小公园纪念亭) be completed by marking all historical buildings. It would be useful for the memorial protection work (actually some NGO in Shantou has done some remarkable works, ex. 汕头山水社).
#Premium DigitalGlobe imagery
With Premium DigitalGlobe imagery at 100m you can see buildings and it is not comfortable to edit them at this zoom level being too small but the height when you zoom out 50m the buildings disappear. As I use JOSM frequently, I tried ID editor and it's the same thing. That's weird. photo 1 zoom at 100 m photo 2 zoom at 50 m
It is with great pleasure that I announce the launch of the 3D Model Repository, available at https://3dmr.eu!
The main aim of the project is to enable a better 3D rendering of OSM data, placing 3D models at everything from landmarks, such as the Eiffel Tower, to benches on the street.
Starting off from my Google Summer of Code project, over the past few months, along with my mentors, Jan and Tobias, I have been working hard on setting up the infrastructure required for the launch, namely a web server and the domain, which have been warmly provided by FOSSGIS. Along with this, some new features and bugfixes were added to the repository, including a PR by dkiselev. Finally, the last few miscellaneous issues before the launch have been resolved, and a few sample models were added to the repository.
On the renderer side, -karlos- has been making great progress with OSM go, having provided us with an easy way to show off the features of the repository. An example rendering can be seen here or in the picture below.
Contributions are always welcome, in any form! There's several ways to contribute to the repository, such as modelling or developing. If you know how to use Blender or SketchUp, you can get started right away modelling features of your town, consult the wiki for more information. Otherwise, if you'd rather develop, you can implement the repository in a 3D renderer (more information available on the wiki and the API documentation), or add new features to the repository itself (a Gitlab repository is available). Other than that, if you have any other idea, make sure to get in contact.
Hope to see your additions!
I am testing "taginfo" instances:
- "Taginfo is a system for finding and aggregating information about OSM tags and making it browsable and searchable. It was created by Jochen Topf." link
You can reach my testing site here for the next 2 weeks( after I will shut down )
- Africa: every country - daily refresh
- Central-America: every country - daily refresh
- Antarctica: daily refresh
- other (Asia ,Antartica and Oceania, Europe, North-America, South-America, Russia )
- just some examples ... - no refresh .
About ~ 120 testing areas, some examples:
- Berlin: http://eu-de-be.taginfo-dev.opengeodata.hu/
- California: http://na-us-ca.taginfo-dev.opengeodata.hu/
- Istanbul http://eu-tr-34.taginfo-dev.opengeodata.hu/
- Burkina Faso : http://af-bf.taginfo-dev.opengeodata.hu/
- Costa Rica : http://ca-cr.taginfo-dev.opengeodata.hu/
- Cuba: http://ca-cu.taginfo-dev.opengeodata.hu/
- Haiti: http://ca-ht.taginfo-dev.opengeodata.hu/
- Kenya: http://af-ke.taginfo-dev.opengeodata.hu/
- Madagascar: http://af-mg.taginfo-dev.opengeodata.hu/
- Mali : http://af-ml.taginfo-dev.opengeodata.hu/
- Nicaragua : http://ca-ni.taginfo-dev.opengeodata.hu/
- Sri Lanka : http://as-lk.taginfo-dev.opengeodata.hu/
- Tanzania: http://af-tz.taginfo-dev.opengeodata.hu/
I am also looking hosting/dev sponsors - if it is useful.
After 2 weeks - you can reach the latest info in the source code repo : https://github.com/taginfo/dockerized-taginfo
Wikimania 2018 is happening in Cape Town, South Africa on July 18-22, 2018, it's the annual international conference that celebrates Wikipedia and its sister free knowledge projects.
The previous year, Montréal, Canada, was the host of this conference. The OSM community in Montréal had set up a booth and did an amazing work of introducing people to the OSM project. It also became a great place for answering questions related to OSM as well as explore more ways to collaborate with different Wiki projects.
There were some interesting sessions related to OpenStreetMap in the previous Wikimania:
- Workshop - Mapathon! Contribute and connect OpenStreetMap and Wikipedia using Wikidata
- OpenStreetMap project and how to get involved
- OpenStreetMap loves Wikipedia
The last date for submitting proposals for talks/sessions/workshops was 18th March but the community can still attend and give a lightning talk and/or organise a Birds of the Feather (BoF) session.
It’ll be great if the South Africa/Cape Town OSM communities would want to do something along these lines. OpenStreetMap and Wikipedia communities have a lot in common, let's meet, collaborate and make the most of this opportunity!✨
Specialising in providing the best circus-themed entertainment for almost any event imaginable, from corporate events and company fun days to gala dinner shows and parties our expert knowledge enables you to select circus acts that are choreographed to your exact requirements.
First, thank you all for improving the mapping of subway networks all around the world! In just half a year, we made more than 150 networks routable, of 180 total. That is very impressive. Today, OpenStreetMap has more data on subways than any other source, open or proprietary.
Last week, I have made a few improvements to the validator. The major one is a change to how stations are counted. We had an issue of transfer stations: for some cities they were counted once, for other — twice, depending on how they are mapped. This simplified calculating a projected total number of stations (just copy it from wikipedia), but affected mapping.
Now, thanks to disc12, it sums up numbers of stations for each line. This is more predictable and allows for different interchange mapping styles. In the spreadsheet, counts of stations have been mostly updated in form of a formula: =line1+line2+...+lineN. You can clearly see how many stations it expects for each subway line. If you find an error there, add a comment and I'll update the number.
Having trouble with missing or extra stations? Click on "Y" near the city name, and you'll get a YAML file with all stations, transfers and lines. What's new is a number of stations for each line (calculated as a number of unique stations for all its itineraries), along with a list of stations. Comparing it to wikipedia is much easier.
There are some improvements planned still. For example, handling of stations under construction: you cannot add these to routes at the moment, or you'll get an error. And there is a "nowhere near the tracks" error that is hard to track — I really should do something with it. And the preprocessor calls for a GTFS output.
Thanks for mapping, now let's finish the last cities and then monitor the world for new subway and light rail stations. If you are an app developer, please consider using the validator output for your app. Contact me if you have any questions.
Although Ubuntu 18.04 ("Bionic Beaver") isn't released yet, it's due out fairly soon and daily builds can be downloaded from here. There are actually very few changes from the 16.04 version - mostly just updated versions of software (including some Mapnik fixes). Following these instructions shouldn't take more than a couple of hours for small areas - the longest period of the setup is waiting for the shapefiles used by the style to download.
As before, the page is designed to be "the least you need to do" to get a rendering server working. As before I also wrote a wiki page which goes into a bit more detail, including other things that you might want to do.
It's also worth mentioning than there are many more resources available now than there were a couple of years ago - see for example Ircama's tutorials, and also this guide that covers the setup of an OSM Carto renderer within Docker.
Visited Grahame Park estate in Colindale on Saturday 17 March for an in-depth survey of the revised road and building layout. Further research of the development plan for the area indicates that there will be a lot more substantial changes in the coming months, however, the following has been done.
New road added: Bristol Avenue
Changes to following roads: Lanacre Avenue; Hazel Close, Five Acre; Hundred Acre; Cherry Close; Lower Strand; Percival Avenue; Valentina Avenue
Removal of following roads: Belvedere Strand; Further Acre, which no longer exist. Removal of associated footpaths and meadows which have changed too.
Addition of new Points: Barnet Southgate College, Colindale Library and adjustment of former Grahame Park library to a Hindu temple.
New residential buildings added and a small number of buildings removed.
Movement of bus stops from previous locations and alignment of bus routes to the new layout.
Other small-scale editing took place in the Golders Green, Edgware, Hendon and Borehamwood areas, mainly changes to building names
The beta release of 10.2 that is now available in the beta channel on the google play store, or from the releases on github does not change an awful lot that is end user visible outside of a new upload UI, however there are two core changes that I want to touch on quickly.
Support for "network" location providers
Historically Vespucci has only supported using the on-device GPS location provider, or nothing at all. That meant that you were unable to get a rough location approximation on devices that didn't have onboard GPS, or that had GPS disabled for example to reduce power requirements. The main reason for this is that on the one hand we wanted to avoid location information potentially tainted by your devices Android provider and avoid our users position being tracked by them.
We now support using so-called "network" location providers, that is location sources that derive your position from the mobile network, WLAN and other signals your device is receiving. If you've enabled such providers on your phone, more on that later, Vespucci will use all available providers for centering the map display on your position and for auto-downloads, tracks will still exclusively be generated from GPS data.
The change in opinion is mainly due to less and less people caring about such matters and at least google tracking in any case (see for example https://www.theverge.com/2017/11/21/16684818/google-location-tracking-cell-tower-data-android-os-firebase-privacy), further allowing such providers enables better indoor positioning which is a clear advantage.
If Vespucci detects that network positions can at least potentially be used, it will display this icon instead of the classic GPS icon on the screen and will alert you to which provider it is currently using via toasts (the short on-screen messages).
Modern devices running a google variant of Android have three location mode setting (besides turning location services completely off):
- Device only - use only the on device GPS location information, does not require sharing your location data with google
- Battery saving - doesn't use GPS, instead uses mobile network, WLAN and other signals to determine your location, requires sharing of your location data with google
- High accuracy - uses GPS and other signals to determine your location, requires sharing of your location data with google, this is typically only more "accurate" than Device only if receiving GPS signals is seriously impaired
Vespucci does not use the Google play servers "fused" location service and remains usable independent of if you are running it in a Google sanctioned environment or not.
Better https support
Given the push for more and more services on the Internet to be accessible only via encrypted transport (https) Android apps are faced with two challenges:
- the standard Java API for accessing http services does not support protocol level redirects, that is http to https or the other way around this is not difficult to work around but would still require codes changes at every impacted place in the code
- more and more sites are turning off TLS 1.0 support for security reasons, unluckily TLS 1.1 and 1.2 are only supported from Android 4.1 on and are only enabled by default since 4.4, again addressing this requires touching all the same code as above
In the end I decided to address these issues by migrating all the networking code to OkHttp that we've already been using for some things, for example for map tile retrieval since 10.1. As OkHttp exposes a different programming model and it didn't require massive changes, it wasn't a drop in replacement and we appreciate all feedback on the changes as some aspects of the networking code are difficult to test automatically.
- yes this means that users with devices running Android 4.0 and older are not able to access any services that have turned off TLS 1.0, for example you will not be able to update the imagery configuration on the fly from github.
- modern Android versions actually use OkHttp under the hood wrapped in code that emulates the standard Java API, so we are not doing anything particularly exotic.
I finally got around to adding statues in Ylham Park between Gorogly and Azady streets. The Mapillary imagery is available for those interested in seeing what the statues look like.
Ann and I spent a chunk of this weekend collecting street names and GPS traces of unmapped streets in Bagyr and Yanbash, former villages (and before that, Soviet collective farm villages) that are now formally neighborhoods of the city of Ashgabat since being annexed. It had rained, and some of the streets were muddy enough we had to use four-wheel-drive! Over the two days we shot over 3,000 Mapillary images while searching for street signs and marking mosques, schools, and other POIs on the GPS. The GPS traces are public so anybody has access to them.
With these two neighborhoods largely done, we have completed base mapping of all neighborhoods of the greater Ashgabat metropolitan area, i.e., everything inside the new city limits. Much remains to be done--more POIs, new buildings soon to be under construction in central Ashgabat, and a number of streets with no names (and we missed a few in Bagyr this weekend), but we are in a better place now than before.
Chinese proverb says "The journey of a thousand miles starts with a single step". Well, I did not know it was my first step towards a long journey when I walked into the "Map your community" workshop arranged by Save the Children International in Bangladesh. The workshop was arranged for the "Kolorob" project, aiming to completely map two slum areas where the Kolorob app will be launched. The purpose of the app was to provide slum dwellers with necessary information so they can make informed decision. The chosen map was OpenStreetMap. In the two days workshop, I was first introduced to mapping and I got hooked.
I had no idea how maps were made, no idea about GPS, no idea about anything related to mapping. As a completely new area, it was able to grab my attention pretty tight and I started learning more about it. I was hired by "Save the Children" as a volunteer mapper in Kolorob project and I started doing field mapping using different tools. I also assisted in OSM traning and lead field mapping team for the "Data4Action" project by American Red Cross in association with Bangladesh Red Crescent and Red Cross Society.
My interest stretched out to GIS and I started learning the basics by myself. Along with my learning, I continued mapping and became an active member of the OpenStreetMap Bangladesh (OSMBD) team, which is the OSM community in Bangladesh who were actively working with OSM as it's contributor, advocate and as a learning sharing platform.
I joined Save the Children as a Project Officer in OpenStreetMapping and as a graphic designer in the "Kolorob" project, the same project that started my OSM journey. Here I lead my team to map, collect data, take GPS track to map road network etc. Through work in professional area, my knowledge and expertise level grew a lot. I became more interested in GIS and started learning QGIS and ArcGIS. I took courses in advanced ArcGIS which helped clarifying a lot of concepts and made me aware of the numerous possibilities that GIS give access to. I also started volunteering for Tanzania Development Trust as a mapper and also as a member of the mapping group. These interactions helped me learn more and more and gave me the opportunity to expand my knowledge and understanding of OpenStreetMap.
We (me and some other members of OSM community) did not want to limit ourselves to mapping only. We wanted to use mapping and merge our other ideas together to form a group that will work for humanitarian and development purposes which ultimately will contribute to the wellbeing of our environment, society, country and our planet. So we formed Bangladesh Open Innovation Lab (BOIL) and Bangladesh Humanitarian OpenStreetMap Operational Team (BHOOT which means Ghost in Bengali, indicating the mappers behind the map whose actions are so visible, but they themselves are not) to expand our scope of work.
Data is nothing if it is not used by people. You may have thousands of data on how to improve wellbeing of your society, but if that data is not open and not used, that data amounts to nothing. That is where OSM is making the difference. The data is open here, open for anyone to use, analyze and share. This presents myriads of opportunities to create different platforms to utilize this data in sectors such as humanitarian, disaster risk reduction, environment and conservation, road and transport network etc. and even to day to day life for navigation or finding your nearest shop.
My journey continues. My mapping continues and with each step I am learning more, and realizing more of the potential that is around us. All we need to do is take the first step and the path will stretch out before us.