Feed on

As a little Easter present, we published the first version of the ohsome-py Python package today. ohsome-py helps you extract and analyse OpenStreetMap history data using the ohsome API and Python. It handles queries to the ohsome API and converts its responses to Pandas or GeoPandas data frames to facilitate easy data handling and analysis. In this way, you can use Python’s rich plotting libraries to create figures like the one below with just a few lines of code. Check out this notebook to see how it was produced.

The project is still in an early stage, so there might be quite some changes to the package in the future. To learn how ohsome-py works continue reading below or get started with the tutorial.


ohsome-py requires Python >= 3.6. Install ohsome-py using pip:

$ pip install ohsome


Start Python and create an OhsomeClient instance which handles all requests to the ohsome API.

from ohsome import OhsomeClient
client = OhsomeClient()

A simple query to count the number of OSM features tagged as building=* looks like this:

response = client.elements.count.post(bboxes=[8.625,49.3711,8.7334,49.4397],
                                      filter="building=* and type:way")

To send a request to one of the ohsome API endpoints append the single components of the endpoint URL as method calls to the client (similar to regular method chaining in Python) and finally call the post() method which contains all necessary query parameters.

To easily analyse and plot the data, the response can be converted to a Pandas DataFrame or a GeoPandas GeoDataFrame if the response contains geometries.

response_df = response.as_dataframe()

Now you can start your own ohsome analysis of OSM history data!

Further info on the ohsome Framework:

Information on the ohsome OpenStreetMap History Data Analytics Platform and more examples of how to use the ohsome API can be found here:

Related Literature:

For some recent work that has been accomplished using ohsome see for example

Hello dear friends of the disastermappers heidelberg!

At the moment, the Heidelberg International Weeks against Racism 2021 are running – and the disastermappers are also taking part! Why? The unequal distribution of resources is often a consequence of historical (and neo-) colonialism and related racism. This increases the vulnerability of societies in many parts of the world to man-made and natural disasters. What should also come as no surprise: in such areas, there is usually a lack of good maps, which makes it very difficult for aid organisations to intervene.

We are contributing to the collection of important map data with our Mapathon “Mapping for International Solidarity” on 06.04 at 18:30.

The Mapathon – a tool of humanitarian cartography – supports preventive measures and life-saving missions. Several people come together (real or virtual) to map a crisis area. Using satellite images and easy-to-learn computer programmes, volunteers can then quickly put an affected area “on the map” through their efforts and make this available to aid workers on the ground via the internet.

All you need to participate is a desktop or laptop computer, a mouse and an internet connection. You don’t need any previous knowledge, because we support beginners with detailed explanations in German and English – so you are all welcome!

You can join the event with this link https://audimax.heiconf.uni-heidelberg.de/mzt4-vfgk-hy4y-djfp and the following access code: dove ultra tweak sanded oaf.

You can also find more information about the events of the International Weeks against Racism here: https://www.heidelberg.de/1657137.

We are really looking forward to meeting you and making a statement against racism and for global justice!

Your disastermappers heidelberg

Lukas Winiwarter of the 3DGeo group was invited by the Austrian Society of Surveying and Geoinformation (OVG) to give a talk on the application of deep learning on point clouds, which took place on March 24. In his talk, Lukas presented four different state-of-the-art approaches to consider the irregular, unordered structure of point clouds, which allow a deep neural network to learn a representation of the neighbourhood of each point.

Some impressions from the talk (in German):

After presenting to almost 70 participants, a lively discussion showed the relevance of this topic in academia, public administration, and in the private sector. A big challenge in deep learning is the requirement for vast amounts training data, which may in the future be partially provided by simulation - e.g. using our own open-source general-purpose LiDAR simulator, HELIOS++.

We thank the OVG for the organization of the talk and are looking forward to future events.

Open Healthcare Access Map is a new web application by HeiGIT to provide insights into healthcare supply on different spatial scales for many countries worldwide.

The web application is available here: https://apps.heigit.org/healthcare_access/.

Please note that this is a prototype and feedback on improvements and desired functionalities is very welcome. You can reach us at this email address.

The idea for the web app arose from previous analyses on accessibility estimations with the isochrone service from HeiGIT’s openrouteservice and population data from WorldPop. With the open healthcare access map we now provide results from this research in a more interactive format, for more countries and additionally aggregated on three different scales. The data layers used for the application and their spatial relation are shown schematically in figure 1.

Schematic overview of the interaction of the locations of healthcare facilities, the roadnetwork, isochrones and population distribution.

Fig. 1: Schematic overview of the interaction of the locations of healthcare facilities, the roadnetwork, isochrones and population distribution.

How to use the web app

On the landing page https://apps.heigit.org/healthcare_access/ you can select a country of interest either from a drop-down list or directly from the map.

Selecting a country opens the respective country view. Each country view has its own URL. For Nigeria this is: https://apps.heigit.org/healthcare_access/countries/nga. The country view initially starts at the country scale with primary healthcare facilities (see fig. 2).

Nigeria country scale for secondary and tertiary healthcare facilities.

Fig. 2: Nigeria country scale for secondary and tertiary healthcare facilities.

You can change the scale and facility type of via drop-down lists. Currently, the facility types available for selection are primary care, secondary & tertiary care, and a combination of the two. Primary care mainly encompasses outpatient and preventive care facilities, while secondary and tertiary care includes inpatient treatment facilities. When selecting a different scale or type, the map loads the corresponding result layer and diagram. For the country scale, a bar graph shows the relative population living within each interval (10minutes) to the nearest health facility.

Other available scales are the first administrative plane and a hexagon layer. The hexagon layer is based on the isea3h hexagonal grid in resolution 8. The hexagon scale is accompanied by a histogram of relative population coverage within 60 minutes travel time to the nearest health care facility (see Fig. 3). The hexagon scale is accompanied by a histogram with the relative population coverage within 60 minutes travel time to the next healthcare facility (see fig.X).

Nigeria country scale for secondary and tertiary healthcare facilities.

Fig. 3: Nigeria administrative (level 1) scale for secondary and tertiary healthcare facilities.

The same histogram is available for the administrative scale. Additionally, a stacked bar chart that allows details about the distribution by 10-minute intervals within each administrative unit (see Fig. 4).

Nigeria hexagon scale for secondary and tertiary healthcare facilities.

Fig. 4: Nigeria hexagon scale for secondary and tertiary healthcare facilities.

Future development

We will expand the application on a regular basis. The next milestones are to cover more countries and to increase the maximum range beyond 60 minutes. It is also very important for us to include quality indicators for facilities and the road network from OpenStreetMap. Another feature is the delineation of catchment areas and population estimates for individual facilities.

We highly appreciate your feedback on this endeavor. Please let us know your ideas and opinion about the app by mail.

Related work:

Online knowledge projects such as OpenStreetMap (OSM) and Wikipedia have gained high importance, trust and even economic value. These projects and their content are maintained and enhanced by online communities that evolve around them. Yet, these communities and their members are often ignored when the respective data or knowledge is used.

In a recent publication a systematic framework is established, to enable a comparable analyses of members of online communities. The framework is tailored towards Volunteered Geographic Information (VGI) but can be easily adapted to any online community that allows and enables the analyses of contributions made by single members.

Influences or context a mapper is exposed to while making a contribution i.e. characteristics of a contribution.

Influences or context a mapper is exposed to while making a contribution i.e. characteristics of a contribution.

The framework identifies a set of dimensions of contextual effect that influence the shape of a contribution to the project. The framework is tested on a specific use-case in OSM: Community Happenings. These happenings, so called mapathons, play a large role in OSM to foster the exchange between mappers but also to tackle a current need for OSM data such as in the aftermath of a humanitarian crisis. To analyse how mapathons change the way mappers contribute to the OSM project, each dimension of the framework was implemented into a set of measurable data proxies. The configuration of these proxies was then computed and compared before and after mapathons.

A hypothetical trajectory of mapping behaviour of a model mapper taking part in a happening along the five abstract dimensions of contextual effects.

A hypothetical trajectory of mapping behaviour of a model mapper taking part in a happening along the five abstract dimensions of contextual effects.

This allowed for a precise description of where, when and how strong mapathons affect their participants and which groups are affected. Happenings that targeted remote regions were compared to happenings that targeted the immediate surrounding of the events venue. In addition newcomers were analysed separately from advanced mappers. All groups were compared to a control group.

Results showed that newcomers adopted a contribution behaviour similar to the contribution behaviour typical for the respective happening they attended: when contributing after the happening, newcomers who attended a remote mapping event tended to concentrate on creating new data with lower quality but high quantity in places foreign to their home region; newcomers who attended a field mapping event updated and enhanced existing local data with high accuracy. The behaviour of advanced mappers stayed largely unaffected by happenings. Unfortunately, our results did not reveal a positive effect on the community integration of newcomers through happenings.

Quantity of contributions for happening participants during events. CFM - Field mapping event; CRM - Remote mapping event, CG - Control group

Quantity of contributions for happening participants during events. CFM - Field mapping event; CRM - Remote mapping event; CG - Control group

Schott, M.; Grinberger, A. Y.; Lautenbach, S. & Zipf, A. (2021) The Impact of Community Happenings in OpenStreetMap – Establishing a Framework for Online Community Member Activity Analyses In: ISPRS Int. J. Geo-Inf. 10, no. 3: 164. https://doi.org/10.3390/ijgi10030164

Related work (selection):

Herfort, B.; Lautenbach, S.; de Albuquerque, J.P.; Anderson, J.; Zipf, A. The evolution of humanitarian mapping within the OpenStreetMap community. Sci. Rep. 2021, 11. [CrossRef]

Raifer, M.; Troilo, R.; Kowatsch, F.; Auer, M.; Loos, L.; Marx, S.; Przybill, K.; Fendrich, S.; Mocnik, F.B.; Zipf, A. OSHDB: A framework for spatio-temporal analysis of OpenStreetMap history data. Open Geospat. Data Softw. Stand. 2019, 4, 3. [CrossRef]

Grinberger, AY, Schott, M, Raifer, M, Zipf, A. (2021): An analysis of the spatial and temporal distribution of large‐scale data production events in OpenStreetMap. Transactions in GIS. 2021; 00: 1– 20. https://doi.org/10.1111/tgis.12746

Auer, M.; Eckle, M.; Fendrich, S.; Griesbaum, L.; Kowatsch, F.; Marx, S.; Raifer, M.; Schott, M.; Troilo, R.; Zipf, A. (2018): Towards Using the Potential of OpenStreetMap History for Disaster Activation Monitoring. ISCRAM 2018. Rochester. NY. US.Eckle, M.; de Albuquerque, J.P. Quality Assessment of Remote Mapping in OpenStreetMap for Disaster Management Purposes. In Proceedings of the ISCRAM 2015 Conference, Krystiansand, Norway, 24–27 May 2015.

Yan, Y., C. Feng, W. Huang, H. Fan, Y. Wang & A. Zipf (2020): Volunteered geographic information research in the first decade: a narrative review of selected journal articles in GIScience. International Journal of Geographical Information Science, DOI: 10.1080/13658816.2020.1730848

See also ohsome.org

The #ohsome quality analyst (short: OQT) has been online and accessible through its web-interface now for quite some weeks already (see the introductory blog post as a reference). The website is not the only access point to the OQT though. Therefore, the ohsome team at HeiGIT would like to give some insights to the additional components of the OQT.


The OQT has a layered structure: the client-side consisting of a website and the backend-side consisting of different python modules, together with a PostgreSQL GeoDB. To illustrate the components of the OQT we have created the following component diagram. Within the next sections, we will explain the different parts individually.

Application Programming Interface (API)

The first backend entry point, in addition to the end-user oriented website, is through a simple API using one of the various endpoints. The OQT uses the Fast-API python framework and provides at the moment a total of eight endpoints. All endpoints can be accessed via GET and POST requests, though when submitting bigger area of interests, it is recommended to use the POST endpoint. Through the API, the user can request the individual indicators, or reports directly and use the returned JSON file for further processing.

Command Line Interface (CLI)

The second backend access to the OQT functions via a command line interface. Here, the user has the biggest set of different functions and commands available. Some of them are only available though to core developers of the OQT. This includes starting preprocessing jobs for respective indicators and regions that are then stored in the GeoDB. Nevertheless, the CLI is useful for an end-user who is not interested in the processing overhead of the website or the API. Further, it serves as a simple way to test newly developed or integrated indicators.

Data Backend

The GeoDB and the OSHDB serve as the data providers to perform the quality analysis. The OSHDB, a well established database storing the historical OpenStreetMap data to make it easier retrievable and analyzable, is accessed through the RESTful webservice ohsome API. The OQT uses different kinds of endpoints, from data-extraction endpoints like /contributions to compute the saturation indicator, to data-aggregation endpoints like /elements/count for the ghs-pop building completeness, or the POI density indicators.

The GeoDB has two purposes: The first one is to store datasets like the Global Human Settlement Layer, or the Global Urban Footprint to compare it with the OSM data. The second purpose is to store pre-computed indicators and reports. As some indicators require a longer processing time, especially if the area of interest spans over country level, or densely populated areas are analyzed, there’s also the functionality of getting a pre-computed quality analysis. This results in an immediate response to the user when requesting quality indicators within specific regions. These can then easily be retrieved through the OQT website.

Next Steps

Together with other ongoing GIScience/HeiGIT projects like IDEAL-VGI, or the Global Exposure Data for Risk Assessment, the number of quality indicators and reports within the OQT will further increase within the upcoming minor releases, which we plan to publish roughly every 4-5 weeks. As the OQT is a relatively new project, the code base is so far only internally accessible. We are already making plans though to follow other GIScience and HeiGIT repositories and will go public this spring. In case you are very eager to get to know the OQT from its inside already, you can always reach out to us via ohsome(at)heigit(dot)org and we would be happy to communicate with you.

Sie lieben Open-Source-Geoinformationsdienste zu entwickeln, die täglich von Tausenden genutzt werden? Sie sind ein hochmotivierter Java Backend-Entwickler und Algorithmen-Designer? Und Sie wollen OpenStreetMap für leistungsstarke GI-Dienste mit globaler Abdeckung einsetzen und verbessern?

Dann haben wir vielleicht einen passenden und interessanten Job für Sie.

Software Engineer OSM Routing Services (m, f, d)

Backend & Algorithmen

Die HeiGIT gGmbH ist ein gemeinnütziges Start-up mit den Zielen Technologietransfer und angewandte Forschung im Bereich der Geoinformatik, insbesondere in Bereichen wie humanitärer Hilfe oder anderen gemeinnützigen Zielen zum Wohle der Gesellschaft und der Umwelt. Zu diesem Zweck suchen wir einen motivierten und erfahrenen Software Engineer (m, f, d) im Bereich OSM Routing Services (Java Backend).

Ihre Aufgaben im Bereich Routenplanung und intelligente Mobilität beziehen sich auf mindestens eines der folgenden Themen:

Agile Entwicklung innovativer Routing-Services, Algorithmen, Anwendungen und Erweiterungen für das bekannte Open Source-Projekt http://openrouteservice.org (Java)

Erweiterung der globalen Dienstinfrastruktur verschiedener ortsbezogener Dienste mithilfe von OSM

Entwicklung leistungsfähiger Algorithmen, Methoden und GI-Webdienste, insbesondere zur Analyse und Datenanreicherung heterogener globaler Geodatensätze

Wir erwarten:

einen Team-orientierten, hochmotivierten Backend-Entwickler mit solider Erfahrung in Java

einen überdurchschnittlichen Universitätsabschluss in einem der Fächer wie Geoinformatik, Informatik, Geographie, Mathematik, Physik oder ähnlichem,

Interesse an Arbeiten nahe an der Wissenschaft

Deutschkenntnisse bevorzugt, aber „nur Englisch“ möglich

Wir bieten

eine attraktive Position in einem interdisziplinären Team in einem hochdynamischen und wachsenden Bereich. Die HeiGIT gGmbH arbeitet eng mit der GIScience Research Group der Universität Heidelberg zusammen, die Mitglied des Interdisziplinären Zentrums für Wissenschaftliches Rechnen (IWR) und des Heidelberger Zentrums für Umwelt (HCE) der Universität Heidelberg ist. Wir bieten ein anregendes interdisziplinäres Forschungsumfeld mit vielen Möglichkeiten zur persönlichen Entwicklung. HeiGIT erhält eine Basisfinanzierung durch die Klaus Tschira Stiftung (KTS).

Die Stelle soll so bald wie möglich und aus administrativen Gründen zunächst auf 3 Jahre begrenzt werden - mit der Option einer nachhaltigen Verlängerung. Bitte senden Sie Ihre aussagekräftige Bewerbung mit Lebenslauf, Zeugnissen, Referenzen usw. baldmöglichst als PDF an stefan.gumbrich@heigit.org.

Since 2010 organized humanitarian mapping has evolved as a constant and growing element of the global OpenStreetMap (OSM) community. With more than 8,000 projects in 150 countries humanitarian mapping has become a global community effort. Due to this large amount of projects, it can be difficult to get an overview on mapping activity. This is why we worked on the “Humanitarian OSM Stats” website to make it easier to find the information you are looking for. It combines data from the open-source Tasking Manager (TM4) hosted by the Humanitarian OpenStreetMap Team (HOT) and information from OpenStreetMap (OSM) that has been processed using the ohsome OSM History Data Analytics Platform developed by HeiGIT.

As one of the founding members of the Missing Maps program, the American Red Cross (AmCross) has used OSM to support their work for the last seven years.  Primarily focused on preparedness programs that relate to climate change and natural hazards, the team has also supported MRI vaccine campaigns and many other projects.  Over the years, their Missing Maps engagement has grown and they are now hosting almost daily mapathons and engage with 10,000+ mappers annually.

In this post we will focus on validation activity in the HOT Tasking Manager. Validation is an essential part in humanitarian mapping projects for which many beginners do their first map edits in OSM. In the Tasking Manager experience users can mark tasks as validated after a task has been mapped. During this step the so called “validator” either directly fix mistakes (e.g. add missing buildings or correct tagging for highways in OSM) or request that this task should be mapped again by invalidating a task. Once a task has been validated, all data requested by this project should have been completely added to OSM in a correct way. Validation has been in the center of some controversial discussions about humanitarian mapping in the past. Hence, it has gained importance for many humanitarian organizations and some of them are setting up dedicated validator teams or validation events.

The American Red Cross is one of these organizations which has imposed itself to do better when it comes to validation. Over the years, they have hosted a dedicated team of validators in addition to hosting validation focused mapathons. For this piece we will focus on their most recent recruitment efforts. Starting in Fall 2020, the American Red Cross recruited, interviewed, and onboarded 30 new volunteer validators. This group is very diverse in regards to OSM experience, demographics, locations, and skill sets.  What unified this group is their shared interest in data, geography, and humanitarian principles.

Officially getting started in January 2021, the group was on-boarded using a three step process. First, volunteers learned about the OSM community, the Missing Maps project, and got familiar with TM4 and its primary editing tool, iDEditor.  This was to make sure they understood the new mappers experience. Next, the volunteers transitioned to mapping in JOSM.  Last, they became comfortable validating and sharing advice with their fellow mappers. Each class was offered multiple times to accommodate professional and school schedules and time zones. Each class had homework assignments that were discussed at the following class. Two weeks were blocked for each learning module. At the conclusion of their formal learning schedule, weekly Buddy Sessions were held so the group could continue to learn and practice together. Volunteers acted as that week’s Buddy and helped their fellow validator tackle any problems or new learning objectives.

During their time volunteering, monthly check in meetings and guest speakers are also organized for the larger group of volunteer validators. Once confident with the validation activity, monthly goals are set and tracked. We would also like to mention that this group joined forces with a similar program run by the Canadian Red Cross. This partnership was very successful and allowed the mappers to see multiple training styles and mapping behaviors. Next, we will use the humstats website and statistics to check how much progress has been reached already.


In this blog post we will pursue three relatively easy goals that focus on validation:

  1. Find out how many people are mapping and validating in the HOT Tasking Manager.
  2. Check if mapping and validation activities are balanced or skewed.
  3. Find out who is doing most of the validation work.

How to get the information from the website

  1. Visit the humstats.heigit.org website and select your organization and click on “go”. This will direct you to a new site with the statistics for the selected organization.
  2. We then take a look a the Tasking Manager section and navigate to the contributors graph. This plot shows how the activity of the mapping community fluctuates over time. We see that in months with more mappers we usually also see a higher number of validators. In October 2020 a long-term maximum of 180 validators per month have been counted. However, in December 2020 and January 2021 only about 30 volunteers helped to validate tasks in the Tasking Manager. This could be a reflection of a new group getting started and the team focusing on their class 1 learning objectives.
  3. In the next step we investigate validation performance by comparing the number of tasks that have been mapped against the number of tasks that have been validated. The “Equilibrium” plot shows a dark blue bar for validated and lighter green bar for mapped tasks. We see that in most months more tasks get mapped than validated. But there are also exceptions. Between November 2017 and September 2018 AmCross did really well when it comes to validation. This time period coincides with the creation of their Validation Group. Recently the ratio of mapped and validated tasks seems to have stabilized. For the last four month validation activity accounted for around 40% and mapping for around 60% of AmCross’ overall activity in the Tasking Manager. This time period coincides with a serious uptick in semi-unplanned mapping. As the world settled into a new normal, virtual volunteer events became more and more attractive to larger populations. As we know, it is generally easier to upscale mapping compared to validation. This trend can also be seen following our annual Geography Week events.
  4. Finally, to check who is actually doing the validation we scroll down to the users section on the website. We learn that in the last month there have been 6 users who did the major validation work: Bluemlisalp, jaggededge, crazy_mathi, AngleTarn, Ranek and Puxan. Each of these users validated more than 100 tasks in the Tasking Manager. Whereas it is somehow “normal” for a project like OSM that users contribute differently, from an organization perspective it would be good if validation work could be spread on more shoulders. Monitoring these numbers can help AmCross to improve their validation share and find the best way to engage more validators (in such difficult times where in person meetings are not possible).
Step 1: Select your organization.
Step 2: Check monthly numbers for mappers and validators.
Step 3: Check monthly ratio of mapped and validated tasks.
Step 4: Check user contributions for last month (February 2021).

Download the data in a spreadsheet

If you are interested to get the data behind these numbers and plots continue reading. On the website we offer a list of files to download. The activity.csv is the ones that you need for the monthly numbers for mappers, validators and to calculate the share of mapped and validated tasks. The user statistics can be obtained from the user_activity_sessions_per_month.csv file. For instance, for AmCross, this file will be located here: https://humstats.heigit.org/api/export/arc/activity.csv and https://humstats.heigit.org/api/export/arc/users_activity_sessions_per_month.csv.

To be continued

This is the 5th blog post of a series of posts we are currently working on. If you are interested please reach out to us (benjamin.herfort@heigit.org) and we can try to cover your questions in a future post.

We would like to send a big THANK YOU to all of our current validators. Your attention to detail and kind encouragement for our mappers is integral to our work and so appreciated. If you are interested in becoming a validator, please check out the Missing Maps website where new training materials will be added in Spring 2021.

Selected Related Publications

Herfort, B., Lautenbach, S., Porto de Albuquerque, J., Anderson, J., Zipf, A.The evolution of humanitarian mapping within the OpenStreetMap communityScientific Reports 11, 3037 (2021). DOI: 10.1038/s41598-021-82404-z  https://www.nature.com/articles/s41598-021-82404-z

Raifer, Martin; Troilo, Rafael; Kowatsch, Fabian; Auer, Michael; Loos, Lukas; Marx, Sabrina; Przybill, Katharina; Fendrich, Sascha; Mocnik, Franz-Benjamin; Zipf, Alexander (2019): OSHDB: a framework for spatio-temporal analysis of OpenStreetMap history data. Open Geospatial Data, Software and Standards.

Auer, M.; Eckle, M.; Fendrich, S.; Griesbaum, L.; Kowatsch, F.; Marx, S.; Raifer, M.; Schott, M.; Troilo, R.; Zipf, A. (2018): Towards Using the Potential of OpenStreetMap History for Disaster Activation Monitoring. ISCRAM 2018. Rochester. NY. US.

Scholz, S., Knight, P., Eckle, M., Marx, S., Zipf, A. (2018): Volunteered Geographic Information for Disaster Risk Reduction: The Missing Maps Approach and Its Potential within the Red Cross and Red Crescent Movement. Remote Sens., 10(8), 1239, doi:10.3390/rs10081239.

Last November, we covered the recent increase of healthcare related objects in OpenStreetMap (OSM) in India. In less than a year, the amount of facilities has increased from 6.956 to 48.101. This is mainly due to an import run by RMSI - an Indian GIS consulting company. In this blog we will take a closer look at attributes that provide further information on the type of healthcare facility and services offered.

Increase of healthcare related OSM objects over time

Fig. 1: Amount of healthcare related keys over the year 2020.

First of all, we note that the second half of 2020 saw a further strong increase in the amount of facilities. It has more than doubled. From 48.101 at the beginning of July to 123.073 in January 2021. All four tags that identify healthcare facilities show a growth of more than 50%.  Healthcare (78%) and doctors (91%) even clearly exceed this level. The keys clinic and doctors have plateaued over the past four months. However, looking at the growth of the keys healthcare and hospital, especially over the last few months, it seems that the import process may not yet complete. How the share of the other keys will develop in comparison to the hospital key remains open. Currently, the hospital key accounts for almost half of all facilities, a highly questionable ratio.

Frequency of tags

Fig. 2: Relative frequency for selected attributes in healthcare related OSM Objects (n=123.073).

This time, we do not stop at analyzing the changes in the amount of facilities over time. Rather, we look at the occurrence of attributes of the facilities. Attributes that allow for assessing the type of facility and available capacity are of particular interest. We start by calculating the frequency of every available attribute for our 123.073 facilities in India. The most common attribute is name (98%, see figure 1). The second most frequent attribute is addr:full. The name attribute can provide useful information in order to identify a facility beyond the amenity and healthcare tags. The addr:full attribute however, is mostly interesting for geocoding applications.  The next most frequent attributes are already amenity and healthcare. Both attributes can occur for the same object. This is the case for 8.45% of all facilities. With these two tags we also already undercut the 50% frequency, meaning that less than half of all healthcare related facilities do bear more than three tags. Important tags are rarely tagged. For example, the bed (0.08) attribute, which provides information on the inpatient care capacity of facilities. The emergency (1.03%) tag is another example that provides information about the presence of emergency care. Also rarely tagged is the key healthcare:speciality. The second part of the blog is dedicated to this key.

Frequency of healthcare:speciality values

Fig. 3: Absolute frequency of the 10 most common values for the key healthcare:speciality

The key healthcare:speciality was introduced with the healthcare tag back in 2010.  It was established to capture information on available medical specializations. From these specializations, eventually existing diagnostic/therapeutic capacities can be derived. The case that a facility has several specializations is represented by the multiple values scheme. Different values for the same key are separated by “;”. We extracted every value and ordered them by frequency (see fig. 3). Due to different spellings and typos, we also manually grouped some values. We found that “general”,  “gynaecology”, “paediatric” and “dental care” were the four most frequent speciality values mapped in India. Where “general” is the most common value, with more than three times as many occurrences than the second most common value.

Distribution of healthcare:speciality values

Fig. 4: Facet map of the distribution of the four most common values for the key healthcare:speciality

The four most frequent speciality values are further investigated with regard to their spatial distribution in India (see fig. 4). Four facet maps are shown, each for one of the values. The values are spread all over India, but with varying densities. These spatial variations values are almost identical for each of the values. Large clusters are located in the South-West (Kerala state), West (Maharashtra state) and North-West (Haryana, Delhi, Himachal Pradesh states). The occurrence of specialized hospital facilities seems to correspond to urban centers within the named states (Delhi, Chandigarh, Mumbai, Hyderabad, Kochi). The most dominant clusters are spread over the almost entire state of Kerala as well as along the axis of Shimla-Chandigarh-Delhi-Karnal. States like Assam, Kashmir and Odisha are rather sparsely covered with specialized facilities.  It remains open whether the clusters are due to an underlying process of locating specialized facilities in central places or whether they reflect the urban-rural divide within OSM.


Our descriptive analysis shows the import in India continues. Plenty of healthcare infrastructure data has been added. Though, for the vast majority of facilities critical information beyond the simple classification by the amenity tag is missing. The distribution of the few facilities with this information indicate a strong correlation with highly urban spaces. It cannot be determined what influence real world processes and bias in OSM have on this fact.

In a forthcoming analysis, we will broaden our scope of investigation. We will look at the distribution of healthcare facilities in OSM globally. How are they distributed and where are critical tags mapped and where not.

Related Literature and earlier work:

(deutsche Version siehe unten)

Up-to-date traffic information is a prerequisite for navigation solutions to determine the best route and travel time. However, there is no freely available traffic information on a global and federal level. “SocialMedia2Traffic uses freely available data from social media such as Twitter messages,” says Prof. Zipf, “to determine current traffic information such as traffic density and speed for navigation.”

The SocialMedia2Traffic (SM2T) project is funded with a total of 97,463 euros by the the German Federal Ministry of Transport and Digital Infrastructure (BMVI) as part of the Modernization Fund (”mFUND”) funding. SocialMedia2Traffic started on 01.02.2021 and runs until 31.01.2022. The HeiGIT gGmbH (Heidelberg Institute for Geoinformation Technology at the University of Heidelberg) as the network coordinator and the GIScience Research Group (Department of Geoinformatics, University of Heidelberg) as the project partner are working hand in hand on this project.

In the SocialMedia2Traffic project, conclusions about current traffic density and speed are derived based on the geocoding of data from social media. “This traffic information will be made freely available via an interface and integrated into the open and free routing service OpenRouteService,” says Prof. Zipf. “The result is a better prediction of estimated arrival time depending on day of week and time of day.”

In the form of a feasibility study, selected regions will be used to show that this time-dependent traffic information can be derived in the federal territory and worldwide using machine learning. This information is to be made available per road segment. The evaluation of the results will be based on external open reference data. All results will be made available as open data and open source. Thus, the traffic information and further results can be used by everyone.

About HeiGIT gGmbH:
The goal of HeiGIT gGmbH is to improve knowledge and technology transfer from basic geoinformatics research into practice based on innovative geoinformation technologies. It is managed by Prof. Alexander Zipf. The development of HeiGIT is supported by the
Klaus Tschira Stiftung gGmbH. We work closely with the staff of the Department of Geoinformatics at the Institute of Geography at Heidelberg University. In this way, we realize innovative solutions at the cutting edge of research and technology. In this project, too, the synergies between research and development are used to achieve forward-looking results at an international level.

About GIScience Research Group (Department of Geoinformatics, University of Heidelberg):
The GIScience Research Group at Heidelberg University is engaged in innovative basic and applied research and state-of-the-art technology at the interface between geography and computational sciences.

About mFUND of German Federal Ministry of Transport and Digital Infrastructure (BMVI):
As part of the mFUND research initiative, the BMVI has been funding research and development projects related to data-based digital applications for Mobility 4.0 since 2016. In addition to financial funding, the mFUND supports networking between stakeholders from politics, industry and research with various event formats as well as access to the mCLOUD data portal.
Further information can be found at www.mfund.de.

Projektstart von SocialMedia2Traffic - Ableitung von Verkehrsinformationen aus Social–Media-Daten

Aktuelle Verkehrsinformationen sind die Voraussetzung für Navigations-Lösungen, um die beste Route und Fahrzeit zu bestimmen. Es gibt jedoch keine frei verfügbaren Verkehrsinformationen auf weltweiter- und Bundesebene. „SocialMedia2Traffic nutzt frei verfügbare Daten aus sozialen Medien wie zum Beispiel Twitter-Nachrichten“, sagt Prof. Zipf, „um daraus aktuelle Verkehrsinformationen wie Verkehrsdichte und Geschwindigkeit für die Navigation zu bestimmen.“

Das Projekt SocialMedia2Traffic (SM2T) wird im Rahmen der Förderrichtlinie Modernitätsfonds („mFUND“) mit insgesamt 97.463 Euro durch das Bundesministerium für Verkehr und digitale Infrastruktur gefördert. SocialMedia2Traffic startete am 01.02.2021 und läuft bis zum 31.01.2022. Die HeiGIT gGmbH (Heidelberg Institute for Geoinformation Technology an der Universität Heidelberg) als Verbundkoordinator und die GIScience Forschungsgruppe (Abteilung Geoinformatik, Universität Heidelberg) als Projektpartner arbeiten Hand in Hand an diesem Projekt.

In dem Vorhaben SocialMedia2Traffic werden anhand der Geokodierung der Daten aus sozialen Medien Rückschlüsse auf die aktuelle Verkehrsdichte und Geschwindigkeit abgeleitet. „Diese Verkehrsinformationen werden über eine Schnittstelle frei verfügbar bereitgestellt und in den offenen und freien Routingdienst OpenRouteService integriert,“ sagt Prof. Zipf. „Das Ergebnis ist eine bessere Vorhersage der Ankunftszeit in Abhängigkeit von Wochentag und Uhrzeit.“

In Form einer Machbarkeitsstudie soll anhand von ausgewählten Regionen gezeigt werden, dass diese zeitabhängigen Verkehrsinformationen im Bundesgebiet und weltweit mit Hilfe von maschinellem Lernen abgeleitet werden können. Diese Informationen sollen je Straßensegment verfügbar gemacht werden.  Die Evaluierung der Ergebnisse erfolgt anhand externer offener Referenzdaten. Alle Ergebnisse werden als Open Data und Open Source zur Verfügung gestellt. Damit können die Verkehrsinformationen und weiteren Ergebnisse von jedem genutzt werden.

Über die HeiGIT gGmbH:
Das Ziel der HeiGIT gGmbH ist es den Wissens- und Technologietransfer aus der Geoinformatik-Grundlagenforschung in die Praxis auf Basis innovativer Geoinformationstechnologien zu verbessern. Es wird von Prof. Alexander Zipf wissenschaftlich geleitet. Der Aufbau des HeiGIT wird von der
Klaus Tschira Stiftung gGmbH gefördert. Wir arbeiten eng mit den Mitarbeitern der Abteilung Geoinformatik am Geographischen Institut zusammen. So realisieren wir innovative Lösungen auf dem aktuellsten Stand der Forschung und Technik. Auch in diesem Projekt werden die Synergien zwischen Forschung und Entwicklung genutzt, um zukunftsweisende Resultate auf internationalem Niveau zu erzielen.

Über die GIScience Forschungsgruppe, Universität Heidelberg:
Die GIScience Research Group der Universität Heidelberg beschäftigt sich mit innovativer Grundlagen- und angewandter Forschung und neuester Technologie an der Schnittstelle zwischen Geographie und computational sciences.

Über den mFUND des BMVI:
Im Rahmen der Forschungsinitiative mFUND fördert das BMVI seit 2016 Forschungs- und Entwicklungsprojekte rund um datenbasierte digitale Anwendungen für die Mobilität 4.0. Neben der finanziellen Förderung unterstützt der mFUND mit verschiedenen Veranstaltungsformaten die Vernetzung zwischen Akteuren aus Politik, Wirtschaft und Forschung sowie den Zugang zum Datenportal mCLOUD.
Weitere Informationen finden Sie unter www.mfund.de.

« Newer Posts - Older Posts »