Nominatim kann nur das verwenden, was da ist. Nun gibt es zwei Möglichkeiten:
Es gibt eine Flächendefinition für die Postleitzahlen
Es gibt nur einen Punkt für die Fläche.
Bei Punkt eins, kann die Fläche für die Postleitzahl falsch definiert sein. Das liegt an der Quelle des PLZ-Imports, die in sich unregelmäßig gegen die realen Gebiete verschoben ist. In Bonn z.B. wurde der Ost-West-Versatz anhand des Rheines korrigiert, der kleinere Nord-Süd-Versatz blieb unkorrigiert. Die PLZ-Bereiche sind deswegen an ihren Nord- bzw. Süd-Grenzen falsch positioniert. Das wird in anderen Orten, wo die PLZ-Grenzen nicht mit den administrativen Grenzen übereinstimmen ähnlich sein.
Punkt zwei kenne ich bei Postleitzahlen nicht, gab es aber auch in DE lange bevor die meisten Orts(teil)-Grenzen erfasst waren.
Nachtrag:
Ich warte darauf, dass deine Rechnerprobleme behoben werden, damit ich das Problem zumindest für Bonn angehen kann.
Ich auch. Hatte 'nen Plattencrash bei einem Raid5 (3x2TB) weil eine Platte die Grätsche gemacht hat. Normalerweise verträgt ein Raid5 das schmerzlos und läuft dann im degraded Mode weiter - meines nicht Da die Ersatzplatte immer noch nicht eingetrudelt ist, hab ich mal eben so 114 € abgezweigt und mir heute eine neue Platte gekauft. Mal sehen was eher kommt (Di/Mi ist angesagt) und ob das Raid dann hochkommt. Ansonsten muß ich alles neu aufsetzten. Eine nicht ganz aktuelle Dasi hab ich aber das kann dann dauern.
Die admin-Grenzen bis level 8 (Gemeinden) in BaWü sind nach meiner Erfahrung mindestens hausgenau. Widersprechende Eintragungen bei Gebäuden waren in allen mir untergekommenen Fällen definitiv falsch.
Reine PLZ-Grenzen jedoch sind in den mir bekannten Fällen immer zu ungenau gewesen, um Häuser zuordnen zu können. Das gilt in abgeschwächter Form auch für die admin-Grenzen >8 (Stadtteile, -bezirke u.ä.).
Ich habe sogar Zweifel, ob Gebiete (Grenzrelationen) überhaupt geeignet sind, die PLZ in solchen Gebieten vernünftig zu erfassen: Die Post stellt nicht nach Gebiet, sondern nach Straßen(-abschnitten) zu. Da kann es sein, dass sich kreuzende Straßen auch noch weit über die Kreuzung hinweg zu verschieden PLZen gehören. In den Überlappungszonen gibt das nicht nur ein unübersichtliches Zickzack, sondern auch jede Menge Mini-Enklaven und Exklaven. Da tut man sich mit dem Tagging der Gebäude viel leichter.
Ich würde aber trotzdem nicht behaupten, dass das Zuordnen der PLZ zum Gebäude in allen Fällen die bessere Wahl ist. Auf dem flachen Land sieht es (meist) ganz anders aus. Da ist das PLZ-Gebäude-Taggen Overkill.
Die Suche “6, Am Jahnhaus, 09212, DE” ergibt: “Haus 6, Am Jahnhaus, Rußdorf, Limbach-Oberfrohna, Zwickau, Sachsen, 09212, Deutschland, Europäischen Union” obwohl der Teilort “Rußdorf” nicht getaggt ist, sondern “Oberfrohna”,
Ich sehe nicht mehr durch, was Nominatim macht, denn einerseits weitet Nominatim Postleitzahlen über Grenzen hinweg aus, und andererseits braucht Nominatim Grenzen um Teilorte auf Gebiete auszudehnen…
Ich weiß noch nicht ob es sich lohnt die Teilortgrenzen einzufügen, zumal Gehrke, der die Grenze weitgehend verbessert hat, Wolkenburg-Kaufungen gelöscht hat und eine Postleitzahlverdoppelung eingefügt hat. Bin mal gespannt wie sich diese doppelte Postleitzahl auf das nächste Mapfactor-Update auswirkt.
Du kannst bei der Ausgabe von nominatim unter “details” nachsehen, wie nominatim darauf kommt, dass Am Jahnhaus in 09212 Rußdorf, Limbach-Oberfrohna liegt: “Rußdorf” kommt vom nahegelegenen place node 36127034 Aus der Relation 283719 kommt “Limbach-Oberfrohna” und die Postleitzahl… Die fett gedruckten Zeilen sind die berücksichtigten Objekte.
Tod dem Place-Node - ich kann es wohl nicht oft genug wiederholen Die Teile sind veraltet, inzwischen** für Orte und Ortsteile unnötig** und stiften nur Chaos Unfrieden.
Dem von dir schon fett geschriebenen muss ich leider widersprechen: Ortsteilen fehlen leider fast immer die Grenzen, wodurch die Place-Nodes noch notwendig sind.
Der place-node hat übrigens nichts wenig damit zu tun, wie ein Objekt gefunden wird. Hier würde auch “6, Am Jahnhaus” reichen, weil der Straßenname so selten ist.
Nominatim ist nur bei der Ausgabe ganz besonders verliebt ins Detail (Hausummer, Straße, Bezirksteil, Stadtbezirk, Stadt, Kreis…), wobei manche dieser Details eben auf Schätzungen wie “Node in der Nähe” beruhen.
Altes OSM-Vorgehen: Wenn bestimmte Grenzen (hier die von Ortsteilen) nicht 100% bekannt sind, improvisiert man die halt. Das wurde ein “meiner” Ecke so gemacht - allerdings sind das räumlich getrennte Dörfer, die Teile einer Gemeinde sind. Da ist es ziemlich egal, welcher Acker in welchem Ortsteil liegt, Hauptssache die Residentials stimmen einigermaßen. In Ballungsgebieten/Großstädten sieht das natürlich anders aus.
Auf der Wikipedia gibt es Karten vom östlichen Rhein-Main-Gebiet (weit umfasst) die auch Ortsteilgrenzen beinhalten. Die sind soweit ich das erblicken kann alle PD und somit zum Abzeichnen super geeignet. Auch die Ortsgrenzen auf den Karten sind viel genauer als das was wir haben.
Ist zwar nur ein kleiner Teil Deutschland, aber besser als nichts.
Solange der “Ersteller” dieser Grafiken auf WikiCommons keine konkrete Quelle bebennt, würde ich mal bestreiten, dass er diese Grafiken wirklich *komplett * selbst erstellt hat.
Denn die Grenzverläufe dort muss er von irgendwo als Vorlage her haben. Ob er dann diese Bilder als PublicDomain veröffentlichen kann bzw. darf, halte ich für fraglich.
Was ich immer nicht verstehe: Wie soll uns ein Amt eigentlich die Nutzung von amtlichen Grenzverlaufdaten freistellen (denn da müssen sie ja wohl am Ende des Tages herkommen), wenn es darauf per Gesetz gar kein Urheberrecht gibt?
Man geht Streitigkeiten über künstlerische Fragen, Datenbankrechte, Schüpfungshöhen … aus dem Weg und beruft sich gar nicht aufs Urheberrecht, sondern schreibt ein eigenes Gesetz dazu (hier z.B. für Bayern im Artikel 4): “Die Ergebnisse der Landesvermessung dürfen nur mit Genehmigung der staatlichen Vermessungsbehörden vervielfältigt, verbreitet oder wiedergegeben werden …”