mal 'ne etwas provokante Frage: Wenn ich in meinem in D liegenden Wohnort ein Gebäude taggen möchte, habe ich in Bezug auf die Adresse 5 Tagging-Möglichkeiten: country, city, street, housenumber und postcode. Ist es wirklich nötig, jedem Gebäude alle 5 Tags zu verpassen. Wenn jemand auf die Karte schaut, ist offensichtlich, daß mein Wohnort in Deutschland liegt und die Straße zu diesem gehört. Insofern könnten die Tags Straße (wichtig speziell bei an Straßenecken gelegenen Häusern), Hausnummer (sowieso) und PLZ (es gibt in meinem Wohnort Fälle, wo Straßenseiten unterschiedliche PLZs zugewiesen wurden) doch reichen. Oder bin ich da zu pragmatisch?
Das ist eine Streitfrage, auf die du vermutlich 100 verschiedene Antworten bekommen wirst. Ich setze pragmatisch nur Straße und Hausnummer (und PLZ da wo ich weiß, dass die PLZ-Grenzen nicht eindeutig sind), kenne aber Kollegen, die das anders machen.
Genau hier liegt dein eigentliches Problem: ich denke doch, dass du - hoffe ich zumindest - mitbekommen hast, dass du nicht für die/eine Karte mappst, sondern für eine globale Datenbank dahinter
Um nun Anwender mit rudimentären IT-Kenntnissen es “einfach” zu ermöglichen, alle relevanten Daten aus der Datenbank zu extrahieren, kann man die Addr:* Daten vollständig erfassen.
Was wäre z.B. wenn der Export dir einfach nur “Rue de là XYZ 123” ausspuckt? Frankreich? Belgien?
Klar sei auch gesagt, dass man mit erweiterten IT-Kenntnissen die auf den ersten Blick fehlenden Informationen eben über spatiale Abfragen noch ermitteln kann. Sogar für deine PLZ, sofern die PLZ Grenze korrekt erfasst ist. Und auch dem Ort, sofern eine genaue Ortsgrenze existiert! (Aber es müssen halt dann auch Grenzen oder allgemein gesagt Polygone existieren, in denen diese Punkte dann auch liegen.
Die “saubere” Lösung wäre es meiner Meinung nach, viele viele Relationen zu benutzen. Aber das ist für viele Leute zu kompliziert zu mappen und zu nutzen.
Andererseits ist es ohne Relationen vermutlich nicht trivial, eine Abfrage zu machen wie “gib mir alle Hausnummern an Straße A in B”.
Dazu kommt, dass wir zwar in DE schön strukturiert Adressen vergeben und eine Zuordnung über Grenzen recht sicher machbar ist, in anderen Ländern fallen Postadressen und verwaltungstechnische Grenzen aber oft auseinander. Dort müssen solche Angaben also zwingend gemacht werden. Warum es dann also nicht einheitlich überall machen?
ich trage “in der Stadt” meist auch nur Hausnummer, Straßenname (und falls ich es habe PLZ) ein, auf dem Land je nach Situation öfters auch mal komplett. Im Prinzip ist es nicht schlimm, die Redundanzen zu haben, aber es bringt auch nicht viel wenn man in einer Großstadt im Landesinnern ist. Die gröberen Tags sind jeweils interessant, wenn man sich am jeweiligen Rand befindet, Land kann z.B. in Grenznähe nützlich sein, etc.
ich wollte jetzt eigentlich lesen, wie du weißt/wissen kannst/ermittelst, dass sich deine/die Daten am Rand befinden und du zusätzlichen Daten benötigst oder nicht.
Weil sonst müsste man sagen, dass man es nie wissen kann, und somit immer alles vollständig taggen müsste.
Mal ein Beispiel: 98667 Schönbrunn. Wenn man da mappt wird man wissen, ob man im Nähe der Bundesgrenze ist, und falls ja wird man eher ein addr:country taggen als wenn nicht.
Oder wenn man in Berlin auf dem Alexanderplatz steht wird man wissen, dass man nicht in der Nähe vom Stadtrand ist (selbst als Tourist ohne große Ortskenntnis), und wird vermutlich addr:city weglassen, oder könnte das zumindest ohne nennenswertes Risiko tun.
Wenn man assiociatedStreet-Relationen komplett hätte, könnte man sogar addr:street weglassen :D.
Es ist in diesem Zusammenhang schon ausführlich erläutert worden, weswegen Redundanz (Über-Tagging) für etliche Anwendungsszenarien hilfreich ist und die unbestrittenen Nachteile von Redundanz aufwiegt.
Ich seh schon, wir reden wohl aneinander vorbei: Du redest aus der Menschen-/Touristensicht mit deren einfachen selbstverständlichen Blick auf die Welt, ich rede von Anwendern/Programmierern welche die Daten mit letztendlich dummer Software verwenden und auswerten wollen.
ganz komplett dumm sollte sie besser nicht sein, wenn sie OSM Adressen auswerten will, bzw. sollte man dann die Daten vorverarbeiten, bei OSM kommt es so häufig vor, dass die Adressteile nicht vollständig sind, dass es sich lohnt, da was zu vererben
Eigentlich ist schon alles gesagt, nur nicht von jedem. Woher soll ein Programm (!) wissen, innerhalb welcher Grenzen der Punkt liegt, wenn mal wieder (soll ja öfters vorkommen, siehe Walters Auswertung für administrative oder meine für die deutschen Postcode-Boundaries) eine Grenze beschädigt wurde?
Verstehe ich Dich damit richtig, dass Du lieber empfiehlst den vollständigen Adresssatz zu verwenden?
Naja, ich erfasse Adressen eher äußerst selten bis nie (ist nicht so meine oberste Priorität) bis auf Adressen an POI-Objekten (meist am node-Element).
Von meiner Seite stört mich diese Redundanz nicht. Im Gegenteil, ich mag es ganz gerne, wenn an einem node-POI der vollständige Adresssatz angegeben ist. Also auch dann, wenn dieser node sich in einer Gebäudefläche befindet an der ebenso schon die vollständige Adresse erfasst ist.
Nebenbei, ich habe letztens jemanden, der in der Gegend fleissig on-the-ground Adressen erfasst hat, mal einen Tipp zu Deinem Tool (https://osm-suspects.gbconsite.de) gegeben. Das hat derjenige bereits mehrmals benutzt. Nun ist mir allerdings aufgefallen, dass dadurch ab und zu die doppelten Adressen an den von mir erfassten POIs entfernt wurden
Könnte da im suspect-Tool ggf. eine Warnung für nicht zu löschenden POIs Adresssätze eingebaut werden? Oder diese gar nicht erst zur Fehlerkorrektur angezeigt werden?
Diese Angst vor “doppelten Adressen”. Gut, Adressen als Feature sind idealerweise (und in der Regel) einzigartig, aber wenn man für die Adresseigenschaft von anderen Features wiederum dieselben tags verwendet, dann ist es ja klar, dass in diesem Zusammenhang dieselbe Adresse öfters mehrfach vorkommen wird, weil ein Haus mehrere Nutzer haben kann.
Wenn man die Adressfeatures als Fläche gemappt hat, dann sind dieselben Daten auf anderen Features innerhalb dessen klar redundant.
Hat man hingegen die Adressfeatures als Punkte gemappt, dann kann man entweder die Adresseigenschaften jeweils wiederholen (wenig komplex, weniger elegant aber dafür einfacher für alle Beteiligten, und etwas mehr Arbeit beim Ändern, also ggf. etwas stabiler)
oder aber man setzt die Beziehung zwischen Adresse und Feature an der Adresse explizit per Relation,
oder man hat die Info nicht und kann nur raten anhand der Entfernungen.
