In the past month, MapComplete was part of Open Summer of Code where 4 students and myself did make a lot of improvements and a new theme.
With this diary entry, I’d like to give you some insights in what we’ve done the past 4 weeks.
What is Open Summer of Code
Open Summer of Code (or OSOC) is a programme organized by Open Knowledge Belgium, which is a small belgian NGO that promotes Open Source and Open Data.
For OSOC, they search clients (organizations or governmental institutions) which have an interesting problem that they want solved and with budget to pay a team of about 4 students.
These 4 students will be guided by a coach (such as me) to make sure something useful comes out of it.
The actual problems are varied. We’ve had a planning tool for building new homes, a calendar application based on SOLID, a tool to discover research papers, …
The bottom line is that data must be open and that all produced software and tools will be open sourced. If possible, the programs should reuse existing tools and datasets, such as OpenStreetMap or wikidata.
OnWheels: the wheelchair accessibility map
One of the projects this year was paid for by BOSA (a belgian gov organization) requested by OnWheels - a belgian application which helps wheelchair users to navigate the world. They have a database of shops, restaurants and other amenties together with some info about them, such as name, contact details and opening hours, but also information about the width of the door, the height of the kurb at the entrance, …
During the past years, the idea of opening this data has grown within OnWheels, for various reasons. By opening the data, more people can reuse it. Furthermore, by switching to OSM, the cost of maintaining this data is shared amongst more people.
However, making the switch is not easy. With the OSOC-project, we wanted to create a first version of how an OnWheels 2.0 might work.
Whom is this app for?
During our scoping sessions, we identified three groups of people who will be interacting with this app:
- People with reduced mobility
- Data contributors
- Users which might export or analyze the data
People with reduced mobility
The first group of users is the obvious group - they are the main group of users and should be able to get the information they need quickly and easily. They include wheelchair users, but many more groups of people are served by having good data; including people without a disability. In a way, people with e.g. a stroller can benefit from this information as well.
The second group of people are the data contributors. They include the casual mapper, the group of people who do a mapathonn (e.g. as a teambuilding) to a municipality who has a dataset lying around that they want to import.
The last group are the data reusers, whom want to reuse and analyze the data. A typical example here is a government or municipality who wants to create a report about the accessibility in their city.
What is good wheelchair accessibility data?
OSM has a long tradition of mapping wheelchair-accessibility with
wheelchair=*. As it turns out, this is rather limited. Some wheelchairs are wider then others, some wheelchairs are pretty long (e.g. wheelchairs with a third wheel in front; electric scooters often used by old people, …).
Some wheelchair users can cross big kerbs (e.g. by getting up, stepping over, lifting their wheelchair over the kerb and sitting down again), whereas other people with reduced mobility might not be able to cross a kerb of even 2 cm.
In other words, we want more detailed information!
This also raises an important data question. Should we add this information on the POI of the shop, on the enclosing building or on the door? We decided to add the information on the individual door objects. For example, the shop might move, but the door will stay for the next shop. Furthermore, a building (and thus a shop) might have multiple entrances with different properties… By keeping this information on the doors, the data model stays pretty clean.
We also tested this in real life, by going out with the team in wheelchairs for a stroll through the city. Quite an adventure, especially taking the subway… You can find a movie about it on the project site.
With these three groups of users in mind, we set out to create an application which served all of them.
Of course, MapComplete already goes a long way serving these groups. The main focus lay thus on creating a mapcomplete-theme for wheelchair users, with a few extra needed features on the sides.
The first important layer where we all deal with are entrances. For wheelchair users, they are very important: if the entrance is too small or the kurb to high, it becomes an insurmountable obstacle.
Indoor navigation and level selector
The first major, new feature is the level selector. When there are features in view over multiple levels, an elevator will appear on the right where users can select which level they want to view.
In tandem, a layer showing indoor mapping features (such as rooms and corridors) was developed.
When mixing the
pedestrian_paths-layers, we get a basic indoor viewer. A good testing ground is the building we were at during the project.
_NB: this indoor viewer replaces the previous theme ‘entrances’
A dash of magic
Having an indoor viewer is cool, but doing some automatic analysis of the data makes all the difference.
walls_and_buildings received an update. Every
building-feature will calculate which
entrance-objects are located within or on the edge of the building. These can be neatly shown on the building, giving an neat overview:
Layers: Toilets, reception desks, elevators and some more layers
Other important features for wheelchair users are toilets, reception desks and elevators. The toilet layer received some extra questions to gather data relevant for people with reduced mobility; and a layer with reception desks and elevators was added.
The elevator layer asks for information about the physical size of the elevator and offers the possibility to mark an elevator as broken or closed which, sadly, is often the case as we noticed during our wheelchair trip .
The kurbs-theme got some improvements too.
At last, a hotel layer was added as well to have some feature parity.
Features for data reusers
Last year, a feature to download the current view (as geojson or CSV) was already added (even though this feature is disabled by default - it can be enabled by adding an URL-parameter or by enabling it in the theme config).
For the professional data reusers, a ‘dashboard’ was added as well, where some stats can be seen in the blink of an eye.
To import data, a layer to read maproullette tasks has been created which works similar to the import notes. More information on that will come soon.
Mixing it together
All these layers and features are mixed together in the OnWheels theme
At last, the onwheels-theme also ‘steals’ the doors-overview from the enclosing
building-layer. Clicking a feature within a building with doors, will reveal the information about those doors.
More info on the project page: https://osoc22.github.io/project-on-wheels/
Some other changes
The shops theme has received an update as well. I ~~stole~~ parsed the id-tagging-scheme-files and extracted the different shop types with their icons. As a result, the shops how have very nice individual icons.
As scrolling through a long list (~160) of options became cumbersome, I did implement a new way of presenting this view which offers a searchable list of options.
In the mean time, the educational theme has launched. This one features a list of languages that one can choose as school language. This list was queried from Wikidata and is very long (>1000 entries) - immediately breaking this new searchable options tool… It was amended to only show the official languages of the country the school is located in (again: wikidata info and a bit of magic). If the school still uses another language to teach, searching will probably reveal this information.
And, as usual, many translations came in and some miscellaneous bugfixes and question updates were added as well.