Hilfestellung bei Kartenerstellung mit PLZ-Markierungen

Hallo Forum,

ich bin leider blutiger OSM-Anfänger, aber ich hoffe, dass mir trotzdem jemand helfen kann.

Ich habe hier eine Tabelle mit ca. 100 deutschen Postleitzahlen, die ich gerne auf einer Landkarte visualisieren möchte, d.h. jede PLZ soll mit einer Markierung auf der Karte gekennzeichnet werden. Geokoordinaten dazu habe ich leider nicht.

Kann mir vielleicht irgendwer erklären, wie ich das am besten anstelle? Bei google.maps (darf man das hier erwähnen?) hat mir das Programm einen Großteil der Postleitzahlen in den USA verortet, keine Ahnung warum.

Würde mich sehr über sachkundige Unterstützung freuen, da es sich um ein “Herzensprojekt” von mir handelt, das vielen Menschen hilft, zueinander zu finden.

Vielen Dank und Gruß aus dem Rheinland,

Henning

Hi Volvonaut und Willkommen in Forum :slight_smile:

Du suchst sowas zB
http://umap.openstreetmap.fr/de/search/?q=plz

Eventuell ist umap auch für Deine Idee verwendbar?
Greets, HirschKauz

du musst als erstes ein Geocoding der PLZ machen, entweder gibt es dafür bereits Flächen in OpenStreetMap oder du kannst die Punkte mit der PLZ zusammensuchen und davon den Mittelpunkt berechnen. Mit den Koordinaten kannst du im nächsten Schritt die Karte machen

Mit dieser overpass Abfrage
http://overpass-turbo.eu/s/17W5
erhälst Du alle PLZ im Saarland mit ihrem geometrischen Zentrum als CSV Tabelle.

Wenn Du Saarland durch ein anderes BL oder “Deutschland” ersetzt, erhältst Du die entsprechenden PLZs.

Vielleicht (oder auch nicht?) ist ja die Darstellung der PLZ-Gebiete mittels MapCSS in JOSM oder overpass-turbo.eu zielführend:

https://wiki.openstreetmap.org/wiki/MapCSS/Examples

Hallo Volvonaut,

du müsstest halt ein paar Dinge konkreter noch mitteilen:

Hier wäre gleich gut zu wissen in welchem Format (ideal einfach die Datei im “Anhang” - also irgendwo hochgeladen) und ob es für dich ein Problem darstellt, diese in ggf. andere Formate umzuwandeln, wie sie dann für eine automatische Verarbeitung benötigt werden.

Ok, was genau heißt für dich “auf einer Landkarte visualisieren”? Soll das dann eine Karte für den Druck werden? Dann muss man da ganz anders rangehen. Oder nur auf dem Bildschirm visualisiert?
Dann halt die Frage wie genau soll es denn aussehen? Sollen nur die Konturlinien zu sehen sein und im Mittelpunkt die 5-Stellige Zahl? Soll eine OSM-Karte noch “durchschimmern”? Sollen alle PLZ-Flächen gleich aussehen oder jeweils unterschiedlich farbiges Mosaik?
Was ist mit dem Bereich außerhalb deiner PLZ-Gebiete aus der Tabelle? Soll das dann alles komplett weiß sein? ausgegraut? oder halt schlichtweg dort nur keine Gebietshervorhebung?

Brauchst du auch nicht, die hat ja OSM :wink:

Wenn nur für den Bildschirm könntest einerseits einfach nur in overpass-turbo entsprechend die Gebiete abfragen und dort direkt anzeigen lassen:
http://overpass-turbo.eu/s/17Y2

Mit ein wenig Rumgetrickse kannst du dort auch alles außerhalb deines Gebietes “ausblenden” (mit weiß überpinseln):
http://overpass-turbo.eu/s/17Y3

Ich denke es ist ersichtlich an welcher Stelle dort die PLZ getrennt mit | halt als Liste einfach anzugeben sind.

Das ganze kannst du auch in uMap übertragen und hast dort noch mehr Einstellungsmöglichkeiten was das Layout angeht.

… als möglich ist vieles, musst schon konkret werden :wink:

Gruß,
asca

Coole Sache, asca, davon kann ich viel lernen.

Verständnisfrage: die erste query, die nach den gewünschten Postleitzahlen, läuft die über die ganze Welt? Wäre es nicht besser, sie auf die bbox einzuschränken (so wie die zweite)? Die Abfrage ist auch so sehr schnell. Mir geht es eher ums Prinzip / den Lerneffekt.

Folgendes ist Offtopic, also @Volvonaut brauchst zur Beantwortung deiner Fragen nicht lesen, sondern geht auf die Frage von smootheFiets ein.

Ich habe jetzt nichts mit den OSM-Geodatenbanken technisch zu tun bzw. denen von Overpass und halt deren Datenstruktur und Abfragelogik, daher sind meine Aussagen jetzt vorbehaltlich und ich kann nur grundsätzlich dazu etwas sagen.

Ja die Abfragen sollten logischerweise auf die ganze Welt gehen, aber genauso wie aber auch die bbox ja über den ganzen Bestand abgefragt werden muss (ist longitude des Objekts zw. links/rechts bzw. latitude zw. oben/unten). Im Prinzip müsste daher BBox-Abfrage aufwändiger sein, weil mehr vergleiche passieren müssen und Relationen selbst haben ja noch nichtmal Geokoordinaten, sondern nur die zugehörigen Objekte (welche wiederum zugehörige Objekte haben können, …).
Letztlich wird ja möglichst nie bei einer vernünftigen Datenbank in den “Echtdaten” gesucht, sondern es werden immer verschiedene Indizes parallel gehalten und diese durchsucht. Nur wenn es zu einem gesuchten Datenfeld kein Index gibt, dann wird’s aufwändig.
Hast ein Medizinsachbuch in der Hand und willst was über “Migräne” wissen, schaust ja auch nicht auf jede Seite einzeln nach, ob du “Migräne” findest, sondern schaust hintem im Index auf welchen Seiten “Migräne” vorkommt. Oder schaust ganz vorn im Inhaltsverzeichnis und schaust nach, welche Kapitel wohl passen könnte (das entspricht so in etwa einer Partitionierung).
Suchst du hier im Forum nach “asca PLZ” wird die Software hier auch nicht alle Beiträge nach den Worten durchsuchen (würde sie das machen, hättest erst nach Stunden eine Antwort), sondern es gibt ein Wort-Index - quasi: asca kommt in Beitrag #123, #234#, #345, … vor und PLZ kommt in #111, #234#, #543, … vor. Dann wird halt aus beiden die Schnittmenge genommen und fertig ist das Such-Ergebnis.
Gibt jetzt auch noch verschiedene Formen von Indizes, aber das ginge jetzt hier zu weit.

Ich wette genauso hat Overpass halt über wesentliche Attribute Indizes. Somit kann overpass aus sämtlichen Relationen schnell rausfiltern, welche “boundary” sind. Ggf. sogar schon ein Index über die verschiedenen Boundary-Arten wie “postal_code”. Naja und dann in der Handvoll (im Vergleich zur Gesamtheit aller Relationen) “boundary=postal_code”-Relationen entsprechend nach Werten zu filtern ist ja kam mehr viel.
Da mir at hoc nichts kleveres einfällt, wie man Relationen nur innerhalb einer BBox suchen kann, würde ich gar meinen, das dürfte aufwändiger sein. Sicherlich dürfte es nicht so gelöst sein, dass sämtliche Relationen erstmal (über ggf. Unterrelationen, Ways und letztlich die Nodes) bis zu den Geokoordinaten aufgelöst werden um dann zu schauen, welche reinpassen in die BBox. Aktuell könnte ich mir nur vorstellen, dass also erstmal alle Nodes der BBox geladen werden (das kann halt via Index schnell beantwortet werden) und dann wird geschaut an welchen Relationen letztlich diese Nodes alles hängen und hat dann “alle Relationen in der BBox”. Ist zwar auch noch fix möglich, dürfte aber schon etwas mehr Resourcenaufwand sein.

Soviel halt allgemein dazu, vl. kann sich ja jemand noch dazu äußern, welcher konkrete Details über Overpass und dessen Datenhaltung hat.

Gruß,
asca

PS: Oh, länger geworden als geplant :-/

ich weiß auch nicht genau wie overpass api funktioniert, aber sicherlich sind die Daten mit einem räumlichen Index abgelegt so dass man bei einem bbox Query nur in der bbox sucht, daher schont es die Ressourcen im Vergleich zur globalen Abfrage, signifikant.
Zu den Relationen kann ich auch nichts sagen, meine Vermutung wäre dass man bboxen von Relationen evtl. vorberechnet und abspeichert, so dass man schon mal ne grobe Idee hat. Wird beim Updaten dann aber komplizierter.

Sowas in der Richtung dachte ich mir auch. Overpass wird sicherlich nicht für alle Tags einen Index anlegen (kostet ja auch Ressourcen) sondern nur für die wichtigsten. Welche das sind: keine Ahnung. Einen räumlichen Index für alle Nodes gibt es aber mit Sicherheit, schließlich sind wir eine Geodatenbank. Guter Punkt von asca, allerdings, dass Relationen (und, bei Lichte betrachtet, Wege genauso) an und für sich keine Koordinaten haben.

Um es völlig ins off-topic zu treiben: Ich hab mich für dieses hübsche Projekt schlaugelesen über räumliche Indizes: https://smoothefiets.ddns.net/html/verkeersbordenkaart/index.php?lat=53.214812674&lng=6.552159190&z=18
Die niederländische rijksoverheid (die nicht nur komisch heißt, sondern auch recht fortschrittlich ist in Sachen open data) hat einen Datensatz mit allen Verkehrsschildern des Landes freigegeben, gut 2 Millionen Stück. Um damit mappen zu können, muss man die auf einer Karte visualisieren. Das hat ein besserer Programmierer als ich programmiert, allerdings ohne räumlichen Index an der Datenbank. Bei jedem Mal Karte verschieben / zoomen dauerte es 10s, bis die komplette Datenbank durchsucht war. Damit war der Datensatz praktisch unbrauchbar. Das hab ich geforkt, einen R-Baum dran und noch anderen Kleinkram verbessert. Jetzt läuft es flüssig auf meinem schwachbrüstigen Raspberry Pi.
Nur so, um euch den Mund wässrig zu machen. Ziemlich albern, wie restriktiv die deutschen Landesregierungen mit Geodaten umgehen.

(Sorry, Volvonaut, dass ich deinen Thread kapere. Ich höre schon auf. Schöne Grüße zurück von einem gebürtigen Mittelrheinländer!)

Es gibt für alle key-value Paare sowohl einen globalen, als auch einen lokal organisierten Index. Je nach Größe der BBOX kann es sinnvoll sein, die BBOX ganz wegzulassen und global zu suchen, statt sehr viele verschiedene Bereiche im lokalen Index zu untersuchen. Hier im Beispiel sind die PLZs global gesehen wohl eindeutig, und liefern auch nur wenige Ergebnisse, d.h. die BBOX würde eher mehr Kosten bedeuten. Je nach Tagging kann bei diesem Ansatz aber viel Beifang dabei sein, Beispiel: rel[name=“Berlin”]