Ach peb12345, Du sprichst mir aus dem Herzen ;o) In den Mengen, wie einige User Postleitzahlen einfach semi-automatisch hinzufügen, sind sie niemals überprüft worden, sondern vermutlich einfach von der umgebenden PLZ-Relation kopiert worden. Damit machen es aber genau diese Postleitzahlen quasi unmöglich, die PLZ-Relationen zu korrigieren. Naja, es gibt immer ein paar, die der Meinung sind, ihr Tagging ist das einzig Wahre. Ich gehe jedenfalls davon aus, dass wenn an einem POI/Gebäude die PLZ getaggt wurde, dass sie auch überprüft wurde. Bei addr:city wiederum lösche ich gnadenlos in meiner Heimat, Ihr glaubt gar nicht, wie falsch man „Erding“ schreiben kann. Einige Spezis schreiben da auch den Namen des Stadtteils rein - hauptsache alle Felder ausgefüllt. Und addr:country=Deutschland oder Germany? Ja neee, is klaaar…
Richtig. Ich sehe aber ein (klitzekleines) Argument für addr:city, das deren Apologeten bisher nicht vorgebracht haben (und auch nicht danach handeln):
Man kann addr:city als den Gemeindenamen verstehen oder als Ortsteil. Da macht jede/r was er/sie will. Man könnte aber auch sagen, addr:city entspricht genau dem, was die DPAG als Ort für die Adresse angibt. Das ist sehr sehr unterschiedlich. Nicht jede PLZ ist einer Gemeinde zugeordnet, sondern vielleicht auch explizit nur einem Ortsteil. Der Gemeindename steht dann gar nicht in der DPAG-Datenbank. Manchmal ist die Postangabe auch einfach falsch. Klingt alles komisch, ist aber so. Damit könnte man den postalischen Ort dann exakt so erfassen, wie er von der Post erwartet wird.
Man kann es aber auch einfach lassen…
Wäre das dann nicht eher ein Fall für die PLZ-Relation?
Vielleicht. Das wäre dann aber ggf. eine PLZ-Unterrelation (gewissermaßen postal_code_level=9/10), wenn die PLZ nicht nur einem Ort/Ortsteil zugewiesen ist.
Mit “Ort der PLZ” meinte ich übrigens eher “Ort für die Adresse”.
Hin und wieder kann es durchaus sinnvolll sein, addr:city anzugeben. So wie in der ehem. Gemeinde Ketzerbachtal, in der alle eingemeindeten Orte doch ihren Namen behielten. Das ließ sich damals nicht aus den administrativen Grenzen herleiten. Aber sowas ist eher der Ausnahmefall.
edit: Link ergänzt:
Stadtgliederung Nossen
Genau so ist es. Das trifft sich ja gut, dass du dich hier einbringst. Ich bin da wohl anderer Meinung als du und finde es sinnvoller, da wo PLZ-Relationen und administrative Grenzen gut erfasst sind, nur Straßenname und Hausnummer einzutragen.
Wenn ich mir deine Beispiele anschaue, dann scheint es mir da eher darum zu gehen, dass man die Adresse nicht doppelt einträgt und dass man neben der Hausnummer auch die Straße angibt. Das sehe ich ja genau so und die Probleme mit den doppelten Hausnummern oder der unklaren Straßenzugehörigkeit lassen sich so vermeiden, auch ohne die anderen Tags. Wo aber ein fehlendes addr:country oder addr:state Tag in der betroffenen Region (Erfurt-Hochheim) wirklich ein Problem darstellen könnte, kann ich nicht ganz nachvollziehen. Aber sei’s drum, ich werde so weiter machen wie bisher und du wahrscheinlich auch. So lange du mich nicht gezielt verfolgst und alle meine Adressen ergänzt, kann ich damit leben. 
Guten Tag an alle Mapper,
wenn ihr so gegen addr:country und addr:state seit, dann wendet euch doch bitte an die Entwickler der JOSM-Plugins.
Wenn es nach mir ginge, würde der Landkreis und die Verwaltungsgemeinschaft oder Erfüllenden Gemeinde an die Adresse noch angehangen.
Allein für Erfurt gibt es ja schon das Problem mit 2 mal Rhoda.
Und sich auf die Grenze-Relationen zu verlassen ist auch nicht so sinnvoll . Sucht bitte mal in openstreetmap die Grammemühle und überlegt mal was dort an den erfassten Daten falsch sein könnte. Kleiner Hinweis , der Fehler ist selbst in der aktuellen TK 10 drin.
PLZ-Relationen haben um Erfurt rum ja auch keinen Mapper so richtig interessiert und es wurde sich wohl mehr oder weniger auf den Mapper wambacher (OSM Postcode Map) verlassen, der aus allen PLZ 991xx 990xx machen sollte ? Man hätte ihn ja wenigstens rechtzeitig darauf hinweisen können, dass sich hier was ändert.
Sich auf PLZ-Relationen zu verlassen ist also auch nicht immer sinnvoll, da die Mapper vor Ort ihre Informationen nicht immer weiter geben.
Wie schon in meinem 1 Post geschrieben, bei vielen herscht reines Technickdenken.
Solche Aussagen wie “Der Computer (die Software,die App) macht das schon.” begegnen mir seit ich mir meinen ersten “PC” mit einem U 8080 zusammengelötet habe .
Daten die ich erfasse und dann an die openstreetmap-Datenbank schicke sind auch nicht mehr meine Daten, sondern unsere Daten.
Bevor ihr jetzt alle über meinen Post meckert und darauf im Forum antwortet erfasst lieber die Öffnungszeit eures Lieblingsbäckers, der Stammkneipe oder Hausarztes.
MfG
Senni
Ist da denn nun noch etwas falsch oder nicht?
Änderungern der Plz-Daten werden übrigens jedes Quartal von der Post bekanntgegeben. Wenn Mapper vor Ort schon früher informieren, ist das natürlich noch besser. Aber die DPAG-Bekanntmachungen werden schon zeitnah in OSM übernommen.
Hallo Gehrke,
die PLZ stimmen, habe ich mit Mapper wambacher ende letzten Jahres geklärt.
MfG
Senni
Bin zwar ü50 aber daran kann ich mich erinnern In Erfurt war einiges faul und das wurde mittels aller legalen Infos bereinigt. Ob das jetzt noch korrekt ist, ist mir nicht bekannt.
Gruss
walter
Laut DPAG gibt es nicht in Alperstedt,sondern in Kranichborn (OT von Großrudestedt) eine Straße Grammühle.
Sonst finde ich nur Quellen, die das nach Alperstedt zuordnen.
Auch wenn ein Eingabefeld existiert heißt das nicht, dass man jedes Feld ausfüllen muss.
Da du vorhin das Karlsruhe-Schema zitiert hast, da steht drinnen:
→ Rest ist optional
Warum korrigierst du die Grenze dann nicht oder bittest jemand anderen darum? Einer der Vorteile von OSM ist doch, dass wir äußerst flexibel sind und jeder etwas ändern kann.
Hallo Gehrke und alle anderen Mapper,
die Straße Grammühle ist tatsächlich in Kranichborn OT von Großrudestedt, die Grenzen sind dort falsch eingetragen und das eben auch noch immer in der aktuellen TK 10 Thüringen.
Wer es nicht glaubt kann mal den Geoproxy Thüringen aufrufen und sich die Layer Grenzuebersicht-Gemeindegrenzen und Geobasisdaten-DTK 10 anzeigen lassen.
Aber bitte nur ansehen, die Daten sind nicht für OSM feigegeben und auch nicht verwirren lassen, die Ortsbezeichnung ist tatsächlich Grammemühle und die Straße wurde als Grammühle benannt.
Der Fehler war in meinem Schulatlas von 1977 noch nicht drin, in dem von meinem Sohn aus 1991 aber schon.
Grüsse
Senni
@ JohnDoe23,
ich werde mich hüten diese Grenze anzufassen da der Geoproxy Thüringen nicht als Quelle für openstreetmap genutzt werden darf und auf den Grenzsteinen vor Ort steht nicht zu welcher Gemeinde sie gehöhren und dort sind viele Steine.
Ich möchte mich auch nicht mit anderen Mappern rumstreiten welche Grenze die richtige ist, es gibt ja schon Diskussionen wenn ich ein DE oder Erfurt an eine Hausnummer hänge.
Ich habe dort ein is_in hingesetzt und den Straßennamen gemappt.
Dein Beispiel sagt also weniger etwas über die Grenzqualität in OSM als über fehlerhafte Grenzdaten im Allgemeinen.
Trotzdem sollte Dich nichts davon abahlten, die Grenze schon mal so grob zu korrigieren, dass die Siedlung in der richtigen Gemeinde liegt.
Niemand kann Dir verbieten, Dein Wissen in OSM einzutragen. Wir reden hier ja nicht von einem Datenimport.
Es wäre natürlich schön, wenn jemand wie Du, sennewald63, immer dann, wenn Du einen Fehler in den Relationen findest, nicht einfach nur an ein Gebäude davon abweichende Werte einträgst, sondern gleich die Relation korrigierst. Du musst ja nicht als Quelle den Geoproxy nehmen, es reicht ja, wenn Du die Relation zunächst so änderst, dass sie mit Deinen eingetragenen Daten nicht im Konflikt steht. Das widerspricht sich doch nicht und ist definitiv ein Gewinn für alle :O)
My apologies for replying in English, but did the OP tried to find the address with the wrong village on osm.org (using Nominatim) after adding the correct city in the addr:city tag ?
As far as I know, Nominatim ignores all address information of a POI (addressnode) except for the housenumber. All other information is computed with “nearest” or “enclosed” algorithms.
Even the addr:street tag is ignored. Nominatim always takes the nearest street as street name. You can work around this by using an associatedStreet-relation. See http://wiki.openstreetmap.org/wiki/Nominatim/FAQ
Luckily, this is not true. Nominatim honours all data of a POI, but sadly ignores the data of the building around the POI. What it does is trying to find the nearest street, yes, but even this very poorly, because it doesn’t take entrances into account, etc.
I haven’t yet tested nominatim-results with associatedStreet-relations, but as for POIs outside relations, you have to add addr:housenumber and addr:street to be absolutely sure that nominatim gets them right. See this troubleticket for examples. postcode, city, country, etc. all work as expected though.
As for your original question: no, the thread-owner wasn’t searching for anything, he was just asking whether he should always add addr:country addr:postcode and addr:city, because right now he only tags addr:street and addr:housenumber and someone else (namely sennewald63) adds countrym postcode and city as well. Turns out there’s different opinions and different views on the subject - as always - and now everyone will let this thread die and wait for some months until this question pops up the next time and the discussion continuous where it left off.
I hope I could shine a little light on the discussion :0)
/edit: typo
Thanks for you reply, Nadjita
I just tried a couple of searches in my neighborhood, the algorithm must have been changed. We have several streets with 2 names (on the administrative border between 2 villages) and up to half a year ago, it returned to combined name ( on the street) instead of the addr:street on the building or from the associatedStreet. Or maybe, it finally knows how to use the associatedStreet (see below)
I still believe the following is true (from the Nominatim FAQ)
When you look on how Nominatim solves the address, it’s still not looking at the addr:street tag on the building:
http://nominatim.openstreetmap.org/details.php?place_id=5979954906
it’s clear that it uses a way from the associatedStreet to find out the name (and not the nearest street segment)
As far as I know, addr:postcode is ignored completely and it only works when postcode areas are in place.
I did many tests about half year ago, before I added postcode areas like in Germany. It was the only way to get the correct postcode back from Nominatim.
// edit
When I referred to the OP and the Nominatim query, I meant the street that is not in the right city or postcode because the boundary is wrong