Feed on
Posts
Comments

We are proud to present the newest HELIOS++ release, v1.0.6, with numerous bugfixes and support for the unique LiVOX scan pattern (using Risley prisms - the color indicates point indices and increases from blue to red):

Furthermore, the Easter bunny left some Easter eggs in the ‘toyblocks’ scene:

You can find the changlelog for the new release along with source code and precompiled executables for Windows and Linux on GitHub.

Gemeinsam mit dem Deutschen Roten Kreuz (DRK) hat das HeiGIT heute das Dokument “Die häufigsten Fehler beim „mappen“ mit dem iD-Editor & deren Lösung” veröffentlicht. Das Dokument ist komplementär zum Handbuch zur Veranstaltung von Mapathons, welches bereits 2020 veröffentlicht wurde. Das neue Dokument beschreibt kurz und bündig häufig auftretende Fehler beim Mappen und soll so noch unerfahrenen Mapper*innen beim Einstieg ins Kartieren helfen. In erster Linie richtet sich das deutschsprachige Dokument an Mitglieder des DRK, es ist jedoch frei als PDF auf der Missing Maps Seite des DRK downloadbar.

Wie das Handbuch zur Veranstaltung von Mapathons wurde das Dokument vom “25 Mapathons”-Projektteam erstellt. Das Projekt “25 Mapathons” ist ein Kooperationsprojekt des HeiGIT und des DRK Generalsekretariats, welches zum Ziel hat, Wissen über humanitäres Mapping und das Potenziale von Geoinformationssystemen innerhalb des DRK zu verbreiten. Des Weiteren soll damit die Zusammenarbeit zwischen dem haupt- und ehrenamtlichen Personal des DRK und den nationalen Ehrenamtlichen verstärkt werden.  Ausführlichere Informationen über das Projekt finden Sie im Beitrag “Kick off of the 25 Mapathon project”.

Neben der Veröffentlichung des “Die häufigsten Fehler beim „mappen“ mit dem iD-Editor & deren Lösung” Dokuments hat das “25 Mapathons”-Team im Februar 2021 vier Mapathons mit den DRK Bereitschaften Tübingen, Freiberg und Kaiserslautern durchgeführt zudem einen deutschlandweiten Mapathon.

Das Projekt 25 Mapathons läuft noch bis Sommer 2021. Wenn Sie und ihr DRK Verband auch Interesse daran haben, an dem Projekt teilzunehmen, können Sie sich gerne an Katharina Lorenz wenden (katharina.lorenz@drk.de).

Last week we introduced Open Healthcare Access Map. Our new web application for interactively sharing results of accessibility estimates based on OpenStreetMap healthcare facilities and openrouteservice isochrones.

A new update now shows motorized accessibility estimates of mass vaccination sites in Germany. Accessible via this directlink:
https://apps.heigit.org/healthcare_access/#/countries/deu/covid19_vaccination/adm0

Accessibility estimates towards COVID-19 mass vaccination sites in Germany

Accessibility estimates towards COVID-19 mass vaccination sites in Germany

These results are based on an analysis by Sven Lautenbach  published in a blog early January this year. As explained in the blog post, according to official regulations in Germany, it is not possible to get vaccinated in a state where one does not reside.  Therefore, only accessibility within federal states was taken into account. The difference becomes clear in the border areas of the states and in comparison with layers of accessibility towards primary and secondary/tertiary care. The data basis of the vaccination centers is based on a more recent export from 03/25/2021. This is to take into account changes such as the relocation of centers (Sonthofen case).

Population share in range of 10 minutes towards vaccination site

Population share in range of 10 minutes towards vaccination site

The URL now also reflects the selected scale level and facility type in addition to the country. This facilitates the direct sharing of the respective contents of interest.
https://apps.heigit.org/healthcare_access/#/countries/deu/covid19_vaccination/adm0

Once again we highly appreciate your feedback on the app! Please feel free to reach out via mail.

Related work:

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.

Installation

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

$ pip install ohsome

Usage

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],
				      time="2010-01-01/2020/01-01/PY1",
                                      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.

Components

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.

Older Posts »