addr:city und place=>name gibt es ein "missing streets" für Orte?

Hallo liebe OSMler,
es gibt ja die “missing streets” Auswertung, wo Straßennamen aus addr:street gegen die gefunden Straßennamen verglichen werden.
Gibt es das auch für Orte? Also wenn es keinen “place” gäbe, der zu einer addr:city passt, wäre das doch sicherlich oft ein Fehler, oder?

Ich frage das, weil mir vorstellbar erscheint, dass addr:city Tags auf kleinen, nicht eingemeindeten Dörfern wie
hier zum Wirtschaftshof in Parin https://www.openstreetmap.org/export#map=16/53.9121/11.1930
oft vielleicht beim aktuellen Füllstand (noch) kein korrespoondierendes town,hamlet, village oder suburb aufweisen.
(das Beispiel hat aber ein “village”)

Wie seht Ihr das - muss ich ggf zu den place nodes noch irgendwelche Relationen berücksichtigen, bzw gibt es da schon fertige Statistiken?
Wenns nix gibt, kann ich gerne eine Erstauswertung machen.
Da müsste ich aber vermutlich einen Umkreis definieren, in welchem der zurgehörige place gesucht werden soll.
Oder ich nehme immer die eigene PLZ Region…wenn ich das hinbekomme.

Vielen Dank,
Götz

Spezialfall durch Namensprefix:
node 60635415 ist ein place=village namens “Ostseebad Boltenhagen”
Die diversen addr:city tags in der Stadt beinhalten nun kreuz und quer gemischt diesen kompletten Namen, oder
einfach nur “Boltenhagen” (z.B. Node 302385868).
Durch den Prefix ist das sicher gleich ein Speziallfall, aber ist das aus Eurer Sicht okay so, oder sollte man da mal genauer hinschauen?
Solche Prefixe werden ja manchmal erst später “verliehen”…das ist für alles getaggte natürlich saublöd. Z.B. Hansestadt Stendal…weiss kein Mensch, aber Geburtsurkunden etc müssen kostenpflichtig korrigiert werden…

Hm, ganz ganz eventuell könnte diese Auswertung von Pascal Neise in diese Richtung gehen:

http://neis-one.org/2016/06/unmapped-places-osm/

Ich verlinke den Artikel, weil er erklärt, wie die Auswertung funktioniert. Die Karte dazu gibt es dann unter

http://resultmaps.neis-one.org/unmapped#2/23.7/3.5

Schau’s mal an. Ist das so etwas Ähnliches wie das Gesuchte? Falls nicht, sorry, wollte nur helfen.

Halo Chrysopras,
fast, aber er nutzt die Straßennamen mit und geht auf Radius 700m.
Ich lasse Bezeichung im ganzen Bundesland zu, habe aber, da ich nur auf places & city gehe schon deutlich mehr Beispiele.
Das Beispiel Boltenhagen ist z.B. da nicht erfasst.
Habe gerademal geschaut, Stendal steht noch mit Stendal drin, aber
mit welcher Macht die jetzt überall den Begriff Hansestadt reindrücken, wird das wohl auch mal zu OSM schwappen und dann wohl
einen mech. Edit rechtfertigen.
Warum stellen die Cities (kann ja unsichtbar gerendert werden) kein eigenes “Basisobjekt” dar, so dass in den addr:city tags nur darauf verlinkt wird?
Was ist hier der konzeptionelle Hintergedanke bei OSM?(würde ich gerne verstehen)

Für den bereich Boltenhagen finde ich z.B. folgende falschgeschriebene addr:city tags, die keinen zugehörigen place haben:

Botenhagen (way id=“296096130”)

In Bremen z.B. : Bremerhavenn (way id=“119650191”)
Das dumme ist nur, dass bei den Geofabrik Länder.OSM Dateien dann in Grenzgebieten z.B. bei bremen.osm
ein addr:city mit “Achim” auftaucht, aber der place node dann ausserhalb dieser Datei ist, was dann kein Fehler wäre.
Kann das aber vermutlich durch einladen aller OSM gleichzeitig rausfiltern

Soll ich das mal machen?

Also ich habe in den addr:city ca 245.000 wo es kein 100% Pendant zu einer Relation bzw einem place (suburb,village,hamlet) gibt.
Oftmals ist es der Hauptort, der irgendwie mit Bindestrich/Schrägstrich den Ortsteil angebunden hat.
Im Mapping hat der Ortsteil dann den Präfix aber nicht…hier mal die ersten 100 von 245000.
Vieles aus der Bundesgrenzregion ist aber vermutlich noch auszufiltern, weil im OSm Extrakt der place/relation im Gegensatz zu einzelnen
addr:city eben fehlt.

Sollten wir da mal was machen?
Zum Beispiel Stolberg (Rhld.) fände ich als Namen für den Place/Relation schon besser, als einfach nur Stolberg, in fast allen Belangen (sicher auch Ortsschild) ist der Zusatz (Rhld.) wichtig und wird benutzt.
Wenn Ihr wollt kann ich alles irgendwohin als Zip abladen…

Immenstaad;WY355573036;;Baden-Wuerttemberg
Dorsten-Rhade;WY254069424;;Nordrhein-Westfalen
Lauchheim-Röttingen;WY408707371;;Baden-Wuerttemberg
Thum-Jahnsbach;WY147444927;;Sachsen
Neuburg / Donau;ND2471338860;;Bayern
Rödental-Oeslau;WY373758329;;Bayern
Leichlingen (Rheinland);ND3962569401;;Nordrhein-Westfalen
Neuburg / Donau;ND2465786922;;Bayern
Ilsenburg OT Drübeck;WY442294372;;Sachsen-Anhalt
Berg - Neumarkt;ND3569218193;;Bayern
Balve - Beckum;ND773272195;;Nordrhein-Westfalen
Wald / Kippach;WY197758326;;Bayern
Oberkirch-Nußbach;WY238530321;;Baden-Wuerttemberg
0935736;WY385899441;;Brandenburg
Windeck-Hoppengarten;WY235961936;;Nordrhein-Westfalen
Adelberg Württ;WY382957807;;Baden-Wuerttemberg
Haigerloch-Gruol;WY303141040;;Baden-Wuerttemberg
Westendorf / Dösingen;WY216837211;;Bayern
Eberdingen/Nussdorf;WY182089191;;Baden-Wuerttemberg
Hohwald-Langburkersdorf;WY191714344;;Sachsen
Kabelsketal - Gröbers;ND3983616521;;Sachsen-Anhalt
Linsengericht-Eidengesäß;WY165310845;;Hessen
Landsberg - Queis;ND4127080516;;Sachsen-Anhalt
Dorsten-Lembeck;WY255127571;;Nordrhein-Westfalen
Aalen-Hofherrnweiler;WY246062625;;Baden-Wuerttemberg
Balve - Mellen;ND568131902;;Nordrhein-Westfalen
Römerberg Mechtersheim;WY132580143;;Rheinland-Pfalz
Landau / OT Godramstein;ND2389018804;;Rheinland-Pfalz
Stolberg (Rhld.);WY442251524;;Nordrhein-Westfalen
Burgwald-Ernsthausen;WY211133814;;Hessen
Worms - Heppenheim;WY263614771;;Rheinland-Pfalz
Mainz-Ebersheim;WY390266698;;Rheinland-Pfalz
Sehmatal-Neudorf;WY154904587;;Sachsen
Frankfurt/Main;WY51776500;;Hessen
Schwielowsee, OT Caputh;WY392084899;;Brandenburg
Untrasried Hopferbach;ND1107865929;;Bayern
Euskirchen-Flamersheim;WY288800747;;Nordrhein-Westfalen
Heiligenstadt i. OFr.;WY112951412;;Bayern
Füssen / Oberkirch;WY88497196;;Bayern
Aalen-Dewangen;WY259945266;;Baden-Wuerttemberg
Rödental-Waldsachsen;WY262149002;;Bayern
Edertal-Böhne;ND931913498;;Hessen
Neuburg / Donau;ND2471383338;;Bayern
Neustadt b. Coburg;WY380202814;;Bayern
Euskirchen-Kleinbüllesheim;WY255702148;;Nordrhein-Westfalen
Oelde-Stromberg;WY380235547;;Nordrhein-Westfalen
Titisee-Neustadt - Titisee;WY235543923;;Baden-Wuerttemberg
Germaringen / Obergermaringen;WY135252619;;Bayern
Aalen-Wasseralfingen;WY254733458;;Baden-Wuerttemberg
Seeg / Hitzleried;WY202646539;;Bayern
Eching, Viecht;WY47519273;;Bayern
Rödental-Fischbach;WY376710870;;Bayern
Traben Trarbach;WY220336604;;Rheinland-Pfalz
Chemnitz (Einsiedel);ND1366396157;;Sachsen
Stephansposching-Wischlburg;ND2312803399;;Bayern
Ruhstorf a.d. Rott;WY300719921;;Bayern
Seevetal GT Maschen-Heide;WY425101378;;Niedersachsen
Zell u.A.;WY319392485;;Baden-Wuerttemberg
Bergen im Chiemgau;WY183767753;;Bayern
Vetschau / Spreewald;WY159030695;;Brandenburg
Römerberg Berghausen;WY133319094;;Rheinland-Pfalz
Neukirchen - Vluyn;WY336529429;;Nordrhein-Westfalen
Worms - Abenheim;WY263188957;;Rheinland-Pfalz
Germaringen / Untergermaringen;WY94766980;;Bayern
Düren-Lendersdorf;ND469181543;;Nordrhein-Westfalen
Ense-Bremen;WY316709590;;Nordrhein-Westfalen
Rödental-Oeslau;WY34956533;;Bayern
Bad Hindelang / Bruck;WY100459420;;Bayern
Neuhof a. d. Zenn;WY245051393;;Bayern
Gundelfingen/Wildtal;WY89514777;;Baden-Wuerttemberg
Edertal-Böhne;ND931913629;;Hessen
Seeg / Seeweiler;WY175851466;;Bayern
Sonthofen / Illersiedlung;WY394936332;;Bayern
Rettenberg / Kranzegg;WY123295072;;Bayern
Altdorf (Kreis Böblingen);WY35969000;;Baden-Wuerttemberg
Dettingen Unter Teck;ND1658263121;;Baden-Wuerttemberg
Laerkamp;WY290228574;;Nordrhein-Westfalen
St Märgen;WY108752131;;Baden-Wuerttemberg
Ueberlingen;WY238384308;;Baden-Wuerttemberg
Leichlingen (Rheinland);ND4306298435;;Nordrhein-Westfalen
Dorsten-Wulfen;WY253335692;;Nordrhein-Westfalen
Raesfeld-Erle;WY261594746;;Nordrhein-Westfalen
Altdorf bei Nürtingen;WY49677092;;Baden-Wuerttemberg
Schwalmstadt-Ziegenhain;ND2916355103;;Hessen
Oy-Mittelberg / Faistenoy;WY127245566;;Bayern
Pforzen / Irpisdorf;WY122768308;;Bayern
Dusslingen;WY372507264;;Baden-Wuerttemberg
Xanten-Vynen;WY304906155;;Nordrhein-Westfalen
Gronau (Westfalen);WY253531232;;Nordrhein-Westfalen
Bidingen / Bernbach;WY167163204;;Bayern
Kulmbach-Blaich;WY431827384;;Bayern
Haigerloch-Owingen;WY142163523;;Baden-Wuerttemberg
Vilshofen a.d.Donau;WY370408357;;Bayern
Stolberg-Büsbach;WY305455943;;Nordrhein-Westfalen
Laubach,Lauter;ND974984407;;Hessen
Wetzlar-Dutenhofen;WY348035640;;Hessen
Landau / OT Godramstein;ND2393235852;;Rheinland-Pfalz
Kleines Wiesental - Sallneck;WY438458358;;Baden-Wuerttemberg
Riedstadt-Leeheim;WY72478043;;Hessen
Marktoberdorf / Sulzschneid;WY111050757;;Bayern

Grundsätzlich ist das eine Aufgabe für eine graphische Darstellung.

In deiner Liste ist Brandenburg dreimal vertreten. Eine Fläche liegt aber in Polen: WY385899441 (Grenzbereich zu Frankfurt/Oder).

Die anderen beiden Schreibfehler (WY159030695), bzw. Tagging-Fehler(Schwielowsee, OT Caputh).

Adressfehler sind gerne systematische Folgefehler.

Eine Sture Liste abarbeiten?.. nö…

Sven

Hallo Streckenkundler,
das mit Polen war mir bewusst. (die Ländergrenzen sind hier noch nicht angewendet)
Ich denke ,dass man schon analog der missing streets Auswertung
unterschiedliche Schreibweisen gut rausfiltern könnte.
Ich finde eigentlich eher wichtig, wie die Community die Schreibweise beim Rendering bewertet.

Sollte der Place/Relation vielleicht soch Stolberg (Rhld.) heissen, oder wirklich nur Stolberg?
(Stolberg (Rhld.) allein ist bei mir im Gesamtfile 4370x vertreten und man bekäme es weg, wenn man die eine Relation/Place umbenennt, wenn das eben auch im OSM Sinne richtig wäre)
Bei den Ortsteilen könnte ich mir vorstellen, dass man das in Textfiles durchaus zusammengesetzt (und normiert!) haben möchte
beim Rendering das ganze aber unerwünscht lang und redundant aussieht. (auch wenn man es bei Normierung, z.B. mit Begriff OT z.B. ja wieder reduzieren könnte)
(Köln-Porz, Köln-X,Köln-Y,Köln-Z…) - da nervt das wiederkehrende “Köln” vermutlich

Ich habe die Schreibweise (Freundin wohnte da mal) schon so oft mit Klammer gesehen, dass ich auch vermute, dass es so auf dem Ortschild steht.
Setzt sich ein Label aus Ort samt Ortsteil zusammen, kann man das sicherlich auch erkennen und dann die Schreibweise irgendwie vereinheitlichen.

Das man so mit der Liste nix anfangen kann ist mir klar…ich wollte nur mal ein paar Beispiel rausnehmen.
Anschauen kann man ja z.B. Hessen, das ist nur von anderen Bundesländern umgeben, da gibts zumindest das Grenzproblem nicht.

Auch sowas ganz eigene Fehlerkategorien:
wolfsburg;WY233508840;;Niedersachsen
papenburg;WY415135285;;Niedersachsen(Kleinschrift)

Oberursel (Taununs);WY124859187;;Hessen (Taunus)
Osterode am Harz;WY199984166;;Niedersachsen (Fantasieergänzung)
Maintal -Bischofsheim;WY220109139;;Hessen(Leerzeichenfehler)
Landau / OT Godramstein;ND2393235851;;Rheinland-Pfalz (Schrägstrich plus OT, doppelt gemoppelt)
Schönebeck / OT Pretzien3;WY447080297;;Sachsen-Anhalt (doppelt gemoppelt und Ziffer drin)
Graal Müritz;WY127584110;;Mecklenburg-Vorpommern (Bindestrich fehlt)

Ich schätze, grob 10% sind solche Dinge.
Wenn man nur eine offizielle und lizenzmäßig nutzbare Orts/Ortsteilliste bekäme gegen die man abgleichen könnte…

Allein wie Ort und Ortsteil verbunden werden… da sehe ich hier 20 Varianten.
Frage: was will OSM? als verbundene Schreibweise wird man beides doch kaum auf einem aufgestellten Schild finden (Info wahrscheinlich oft zweizeilig), d.h. man könnte und sollte das doch dann eventuell normieren, oder?

Nur, der Way 159030695 ist von 2012 (genau 11.4.2012). Das ist doch schon recht lange her. Ich denke, zu der Zeit waren die Fehlerprüf-Werkzeuge bei weitem noch nicht soweit, wie heute.

Ein Versuch einer graphischen Implementierung solcher Fehlerprüfung sollte auf jeden Fall mal getestet werden.

Was man aber dabei beachten sollte: die von der Post vergebenen Namen entsprechen nicht immer denen der administrativen Grenzen. Dieser Konflikt lässt sich nicht ohne weiteres auflösen…

Meiner Meinung nach sollte bei addr:city der postalisch vegebene Ortsname rein und bei addr:suburb der postalisch vergeben Ortsteil. Man hat da aber bereits eine Datendoppelung, denn mit addr:postcode ist addr:city eigntlich überflüssig. Lediglich addr:suburb ist gelegentlich nötig für Postleitzahlenbereiche, wo die Straßennamen nicht vereinheitlicht sind.

Ein Abgleich von addr:cty zu place funktioniert meiner Ansicht nach nur äußerst begrenzt. Zuerst muß sichergestellt sein, daß place der realen amtlichen Schreibweise entspricht (was schon schwierig wird). Ob dann immer sichergestellt ist, daß der postalisch vergebene Name eines PLZ-Bereiches (nicht Ortes!!) immer der, des weitestgehend entsprechenden administrativen Bereiches entspricht, wage ich zu bezweifeln…

Sven

Hallo Sven,
wenn der Ortsteil nach addr:suburb sollte, müsste man bei addr:city aber massiv aufräumen, der OT ist hier extrem oft drin.
PLZ 23948 gehört zum Ort Klütz mit vielen Ortsteilen.
(wg Dopplung) Aber es gibt ja nun oft Dörfer, wie in diesem Beispiel Parin (place:village) , die nicht eingemeindet sind und die gleiche PLZ haben.
(Zusammenhänge laut gemeindeschlüssel habe ich noch nicht herangezogen)

Was postalisch okay ist, definiert ja nur die Post. Ich hatte eigentlich primär versucht erstmal eine Ort/Ortsteilauswertung zu machen - und bekomme das überhaupt nicht hin - was mir aber schon prophezeit wurde…
Das mit Stolberg (Rhld.) hat mich dann noch auf ein anderes Problem gebracht.
Ich finde der Place/Relation müsste doch eigentlich auch so heissen, nicht nur in postalischer Hinsicht…
auf der Webeite der Stadt stehts auch so…
Und genau solche Dinge wird man hunderte Male in Deutschland finden.
Was anderes sind da “softe” Schmucktititel wie Ostseebad, Hansestadt, Lutherstadt XY…aber auch da müsste es eigentlich ein Extratag geben, oder?Die harten wie “Bad” sind sicher untrennbar…

Frage:
Westendorf & Dösingen sind zum Beispiel benachbarte Dörfer in Bayern.
Soll nach OSM Bestpractice überhaupt eine künstliche Schreibweise “Westendorf/Dösingen” in addr:city für eine
Objekt im Grenzbereich genommen werden - auch wenn man die Schreibweise so nirgends auf Schildern findet?

Und ewig grüsst das Murmeltier. Diese Diskussion hatten wir bereits schon vor 2-3 Wochen.

Für die “weichen” finde ich name:prefix=* angebracht.
Es gibt auch noch name:suffix=.
Damit kann man dem Renderer die Entscheidung überlassen, was er anzeigt, und dem Suchprogramm, was es auswertet.
Bei name=
hat der Renderer keine Wahl (außer komplett weglassen).

Ich wundere mich, einerseits wird der Schattenwurf von Bäumen ausgewertet und tiefste botanische Experise eingebracht, aber zum an der Frage, wie genau Orte und Ortsteile aufgenommen werden, interessiert sich keiner. Obwohl es bei dieser Frage auch noch um die größten gerenderten Texte auf einer Karte geht.

Dabei ist es bei OSM idR so, dass Schilderangaben übernommen werden sollen.
Bei OT ist die Angabe auf den Schildern so wie ich es meist sehe ZWEIZEILIG - in den Daten ist Zeilentrenner nicht vorgesehen, also
nutzt der eine OT, der andere Schrägstrich, der andere Bindestrich, wieder einer Bindestrich mit Schrägstrich und das ganze dann noch in diversen Kombinationen mit Leerzeichen… Sieht da keiner Handlungsbedarf?!

Oder gibt es zu dem Thema schon eine Festlegung ?- bitte Info

Ja… hat mich heute auch wieder gegrüßt… Nettes Kerlchen :wink:

Das hatten wir ja auch bei der PLZ-Grenz-Geschichte seinerzeit auch durchgekaut… Von der Sache her ist die Angabe addr:city eh Quatsch. Hatten wir damals glaube ich auch schon herausgearbeitet.

Diese sorgt mitunter dafür, daß Zuordnungen nicht stimmen. Das passiert dann, wenn ein Haus administrativ im einem Gebiet liegt, dem eine Postleitzahl zugeordnet ist, das Haus aber einem anderen Postleitzahlgebiet zugeordnet ist… diese Grenzfälle…
Hier eines meiner Beispiele in meiner Nähe: http://www.openstreetmap.org/?mlat=52.08420&mlon=13.89414#map=18/52.08420/13.89414&layers=N

Die Häuser mit den Hausnummern 19 und 20 liegen administrativ im Amt Unterspreewald mit der für diesen Bereich gültigen PLZ 15913 (Straupitz). Postleitzahlenmäßig sind diese aber der 15910 (Schönwalde) zugeordnet. addr:city ist derzeit nicht erfasst. Das hat zur Folge, daß diese nicht immer gefunden werden. Bei osmand finde ich die nur über den Ort Hohenbrück, was falsch ist. OSRM im gegensatz findet die Hausnummer 19, wenn ich “Neu Lübbenau, Hohenbrücker Straße 19” eingebe.

Dann, und nur dann ist die Angabe addr:city, addr:postcode und addr:suburb hilfreich. In allen anderen Fällen kann addr:city über die administrativen Grenzen ermittelt werden, die Angabe selbst ist redundant.

Das fehlen von addr:city und addr:suburb bei den o.g. beiden Hausnummern zeigt, daß diese trotzdem gefunden werden, wenn auch nicht von allen. OSMand müsste da seine Suchalgorythmen eventuell nacharbeiten.

Da sie nun aber mal vorhanden sind, sollten diese vorhandenen Daten aber fehlerkorrigiert werden. (z.B. Auswertung in OSMI)

Sven

Danke streckenkundler, jetzt habe ich noch ein Problem mehr was ich vorher nicht hatte.
:slight_smile:

Bisher habe ich die addr:postcode bewusst ignoriert, weil mir die
PLZ Grenzen sehr korrekt erschienen und ich dann zur Sicherheit die Koordinaten gegen deren Polygone gecheckt habe.
Heisst das nun, ich muss doch addr:postcode nutzen, auch wenn diese bestimmt nicht immer alle bei Verlegung einer Grenze
mitkorregiert werden und man sich andere Fehler miteinschleppt?

Bei der Dahlmannstr 19-24 in Göttingen hatte wambacher extra die PLZ Grenze mit einem kleinen Zusatzpolygon verlegt.
Wäre das hier dann nicht auch richtig?

Das Tag addr:postcode wird regelmäßig über Walters Seite Fools: https://osm.wno-edv-service.de/fools/ geprüft. Wenn etwas da auftaucht, kann das zwei Gründe haben:

  1. die PLZ in addr:postcode ist falsch
  2. PLZ-Grenze liegt falsch.

Grundsätzlich kann der PLZ-Server https://www.postdirekt.de/plzserver/ zur Fehlerrecherche verwendet werden.

Im ersteren Fall muß die PLZ in addr:postcode geändert werden.
Bei zweiterem muß die PLZ-Grenze (nicht die administrative Grenze!!!) angepasst werden.

In meinem Beispiel wurde von mit die PLZ-Grenze angpasst.

Sven

Ja, das war auch notwendig, da die PLZ-Grenzen dort definitiv falsch waren. Und das ist bestimmt an sehr vielen Stellen immer noch so.

Meine Vorgehensweise: auf https://www.postdirekt.de/plzserver/ Stadt und Straße suchen und dann genau die Liste der angezeigten Adressen mit OSM vergleichen. Und dort war zu erkennen, dass die addr:postcode der nördlichen Dahlmannstraße in OSM falsch erfasst waren.
Um diese falschen PLZ-Angaben herum lagen die Grenzen natürlich in sich “korrekt” - waren aber dennoch falsch.

So ist es jetzt:

also: addr:postcode ändern und dann Grenzen anpassen. Was ein weiterer Fehlerfall wäre (beides falsch), was meine Fools aber nicht finden können.

Gruss
walter

Vergleiche zu alledem auch unsere schöne, immer noch interessante, leider mMn etwas „ergebnisoffene“ Diskussion:

https://forum.openstreetmap.org/viewtopic.php?id=52428