Jochen Topf

The OSM data model with its nodes, ways, and relations has done an amazing job for us over the years. It has seen very little changes since relations were introduced 15 years ago. But there are some real problems with the data model. With the experience of those 15 years behind us, its time to tackle some improvements. This talk will outline the problems with the data model, show ideas for improvements, and discuss possible ways that can move us forward step by step.

The OSM data model is quite different from the "Simple Feature" data model used by most "geo" software. It has some great features, like the open tagging model, which has proven to be a great enabler for all sorts of innovations. But the data model also has its problems. Most often named are the missing area data type and the cumbersome geometry building needed for ways and relations based on their member nodes. This makes use of the OSM data more difficult, more expensive, and slower than it needs to be. There has been some discussions on these topics over the years, mostly after my talk in 2018 at the SotM in Milano, but work on this has stalled. Recently the OSMF Engineering Working Group has taken up this topic and payed me to do a study on the problems with the data model and possible ways forward. This talk will present the findings and should jumpstart the discussions around this in the OSM community.

The osm2pgsql has been around for a long time. Since 2006 it is used to import OSM data into PostgreSQL/PostGIS databases for rendering and other uses. In the last years there have been a lot of improvements to osm2pgsql. With the new "Flex" output, osm2pgsql is now much more versatile which allows new applications.

The osm2pgsql has been around for a long time. Since 2006 it is used to import OSM data into PostgreSQL/PostGIS databases for rendering and other uses. In the last years there have been a lot of improvements to osm2pgsql. With the new "Flex" output, osm2pgsql is now much more versatile which allows new applications. The talk will be about the new developments in osm2pgsql und show how to use the new features. Osm2pgsql is used for rendering bitmap tiles for many maps, including the main OSM map and many others. But it can also be used to import OSM data for generating vector tiles and for many other use cases. It is now possible to tell osm2pgsql exactly what output tables with what fields to create in the database. Transformations from the OSM tags to more or less any format you need in your database can be defined in Lua code. Together with the powerful SQL query language in PostgreSQL and the geometric algorithms in the PostGIS plugin, this makes all sorts of analytical processing possible. Osm2pgsql can be used to import small OSM extracts quickly for one-off processing or run a minutely updated planet-wide database on a reasonably-sized machine making OSM data processing accessible for everybody.

The PostgreSQL database with the PostGIS extension is an important instrument in the toolbox of anybody working with OSM data. This talks explains the basics of working with the SQL database and how it handles geographic data. We'll look at getting OSM data in and out of such a database and what we can do with the data once it is in there.

The PostgreSQL database with the PostGIS extension has always played an important role in the OpenStreetMap project. The main OSM database is a PostgreSQL database, tile rendering is most often done from a PostgreSQL database, data analysis and data transformations using current or historical OSM data can be done with PostgreSQL. But understanding what the database can and can not do isn't always easy. And there are a ton of tools, from osm2pgsql to Imposm to Osmosis to Osmium and beyond that "do things" with OSM and PostgreSQL databases. It can be daunting to understand what they all do and where their place in the larger OSM ecosystem is. This talk is an introduction into some of the concepts of SQL and geographical data in an SQL database as well as a whirlwind tour about uses of PostgreSQL in the OSM context. We'll talk about use cases from rendering, to data analysis to routing. We'll talk about the data models that enable those use cases and the software that implements them. And we'll also talk about where the limits are and what things can better be done outside the database. The audience will walk a way with an idea of how things fit together and how to approach their own projects using PostgreSQL.

Diskussionsrunden zu diversen Themen rund um OSM. https://wiki.openstreetmap.org/wiki/FOSSGIS_2019/OSM-Samstag

Diskussionsrunden zu diversen Themen rund um OSM. https://wiki.openstreetmap.org/wiki/FOSSGIS_2019/OSM-Samstag

Spontane OSM Barcamp Session am Samstag, Text kann noch erweitert werden wenn später mehr Zeit ist. Der Rest des Text dient nur dazu das 100 Zeichen Mindestanforderungsrequirement von Pretalx zu umgehen.

Spontane OSM Barcamp Session am Samstag, Text kann noch erweitert werden wenn später mehr Zeit ist. Der Rest des Text dient nur dazu das 100 Zeichen Mindestanforderungsrequirement von Pretalx zu umgehen.

Die OSM-Daten sind nicht immer einfach direkt zu verwenden, sondern brauchen vor der Nutzung eine Vorverarbeitung. Im Vortrag soll es um die Verarbeitung der OSM-Küstenlinien, der Icesheets in der Antarktis und um die Generalisierung von Wasserflächen gehen, die als Service unter osmdata.openstreetmap.de angeboten werden.

Dieser Vortrag ist ein Ersatzvortrag für "Küsten, Meere, Zeitzonen" von Marc Tobias Metten. Zusammenfassung: "Wir schauen auf mehrere Datensätze, die auf OpenStreetMap basieren aber aufgrund ihrer Größe ohne separate Prozesse nicht in den üblichen Editoren bearbeitet werden können. Als Beispiel erstellen wir ein Polygon der Eurostaaten."

Osmoscope ist ein neues Tool zur Qualitätssicherung von OSM-Daten. Aufbereitung der Daten und Webclient sind komplett getrennt. Jeder kann einfach eigene Layer im Web veröffentlichen und Mapper können sie per Mausklick in Osmoscope einbinden.

Es gibt viele verschiedene Tools, die bei der Qualitätssicherung von OSM-Daten helfen. Viele davon arbeiten nach einer ähnlichen Vorgehensweise: Mögliche Fehler werden in den OSM-Daten erkannt und dann über ein Webinterface dargestellt. Mapper können die Probleme dann im Detail anschauen und beheben. Osmose, der OSM Inspector und KeepRight sind die bekanntesten Vertreter dieser Art. Mit Osmoscope gibt es jetzt ein neues Tool, dass diese Idee aufnimmt, im Gegensatz zu früheren Tools aber offener gestaltet ist: Aufbereitung der Daten und Webclient sind komplett getrennt. Jeder kann einfach eigene Layer im Web veröffentlichen und Mapper können sie per Mausklick in Osmoscope einbinden. Der Vortrag stellt das Tool vor und erklärt auch, wie man eigene Layer dafür baut.