Zuordnung von POIs in OSM-Grenzdaten
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 88 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/56744 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
16
20
32
34
45
46
67
75
78
79
80
85
00:07
MetadataInflection pointMittelungsverfahrenDatabaseInformationLevel (video gaming)MetadataAttribute grammarTable (information)Computer animation
03:28
IMPACT <Programmierumgebung>Fehlende DatenOpen sourceComa BerenicesNumberGeometryComputer animation
04:39
MARKUS <Unternehmensspiel>
Transcript: German(auto-generated)
00:13
Zur Ordnung von POIs in USM-Grenzdaten. Ich stelle hier einen Workflow vor, welcher
00:21
benutzt werden kann, um POIs in deren Grenzregionen zuzuordnen. Dieser wurde in einem Projekt eingesetzt, in welchem verschiedene Metadaten von allen POIs in einer Region aggregiert werden sollen. Als Ausgangslabne haben wir die POIs im Bild rechts und als Ziel wollen wir die POIs und
00:41
in deren administrativen Region. Das heißt Land, Region und Subregion. Hier nochmals die genaue Ausgangslage. Wir haben POIs mit Metadaten wie zum Beispiel jene im Bild. In diesem Fall sind das Verkaufsstellen mit
01:01
Informationen über die Umsatzzahlen. Diese POIs möchten wir nun in einem Land und falls möglich eine Region und Subregion zuweisen. Dazu benutzen wir die OSM-Grenzdaten oder auch bekannt als OSM Administrative Boundaries.
01:23
Da die POIs über die ganze Welt verteilt sind, ist es nicht möglich nur eine Region oder ein einzelnes Land zu nehmen und wir brauchen Grenzdaten, die über die ganze Welt verteilt sind. Als erstes wird eine Liste von Ländern bestimmt, welche die POIs beinhalten und für jedes Land wird
01:48
festgelegt, welches administratives Level, das in den OSM-Daten vorhanden ist, benutzt wird. Das machen wir, weil wir mit maximal drei administrativen
02:03
Regionen arbeiten und es bei OSM einige Levels gibt, wobei nicht alle in dem Land Daten aufweisen. Das Bild zeigt ein Beispiel von vorhandenen administrativen Levels in einem Teil Europas. Wenn wir also nun bestimmt
02:23
haben, welche Regionen für welches Land benutzt werden kann, können wir mittels Overpass API einen Datenextrakt generieren. Zusammen mit den POIs und dem generierten Datenextrakt müssen die POIs jetzt gemapped
02:45
werden. Dies wird in diesem Beispiel direkt in der Datenbank mittels SQL Scripts gemacht. Die OSM-Daten werden in eine eigene Tabelle in der selben Datenbank wie die POIs geladen. Mittels SQL Scripts werden
03:05
die OSM-Daten mit den POI-Daten in neue denormalisierte Tabelle zusammengefügt. Sodass nun die denormalisierte Tabelle die Attribute der POIs enthält, so wie das Land, die Region und die Subregion,
03:23
in welcher sich der POI befindet. Was kann man jetzt mit diesen Daten machen? In dem Beispiel hier wird über die Region von einem Land in verschiedenen Jahren aggregiert. So können die Zahlen verglichen und visualisiert werden. Weshalb wurde OSM
03:50
verwendet? Es weist eine hohe Flexibilität auf, auch bezüglich den Lizenzen. Es ist möglich, Daten zu ergänzen, wo etwas fehlt
04:01
und so etwas an die OSM-Community zurückzugeben. Die Geometrien haben eine hohe Genauigkeit. Dies ist vor allem wichtig für POIs, welche sich nahe an der Grenze befinden. Damit haben wir auch bei den Aggregationen eine höhere Genauigkeit. Ich bin
04:24
meinem Baumgartner und bin für die Firma Camp2Camp als Open-Source-Entwicklerin tätig. Herzlichen Dank für Ihre Aufmerksamkeit.