Falsche Postleitzahlen - Ursache unbekannt

Lampenmann · 2013-10-05 13:53:30

Postleitzahlen werden in der OSM-Suche oft zum falschen Gebiet geordnet, und eine Suche anhand der Postleitzahl ist oft gar nicht möglich.

Beispiel-Suche: "Pleißenbachstraße, Limbach-Oberfrohna" wird gefunden "Pleißenbachstraße, Limbach-Oberfrohna, Zwickau, Sachsen, 09224, Deutschland, Europäischen Union" Die PLZ ist falsch, eine solche Grenze existierte auch niemals. Die Grenze, die ich für derartige Fehler verantwortlich machte - eine Grenze ohne PLZ und die fälschlicherweise um Niederfrohna (ein vollkommen eigenständiger Ort) außen herum führte - habe ich vor 14 Tagen gelöscht. Geändert hat sich seit dem in der Datenbank jedoch nichts. Als Postleitzahlenbuch ist OSM demnach nicht zu verwenden.

OT: Der Tag swimming pool wird in Mapfactor Navigator als POI verwendet. Pleißa sieht daher dort echt lustig aus Das muss ich dort mal posten.

Last edited by Lampenmann (2013-10-05 13:57:13)

rayquaza · 2013-10-05 14:26:30

Du hast die Grenze der Verwaltungsgemeinschaft Limbach-Oberfrohna entfernt, das wolltest du sicherlich nicht.
Ausserdem hat Grenze der gleichnamigen Gemeinde die Postleitzahl 09212, gleichzeitig hat z.B. Wolkenburg-Kaufungen eine PLZ-Relation mit der gleichen Nummer (bei sowas sollte es eine Relation für die Postleitzahl geben).

Du hast die PLZ-Relation von Greinau gelöscht, die PLZ ist jetzt aber nicht an der Gemeindegrenze.

Die Relation der von dir vorhefundenen Postleitzahl (Grüna) scheint allerdings nicht bis Limbach-Oberfrohna zu reichen?

(sry dass das etwas "hingeworfen" wirkt (ich muss die Suche unterberechen), aber vielleicht hilft das ja schon)

couchmapper · 2013-10-05 14:37:20

Das Problem sind wohl ein paar unvollständig gepflegte Hausnummern-Nodes, wie man hier sieht.

09224 (Type: place:postcode, node 1201546126, 15, 0.0270961233791845 GOTO)
09224 (Type: place:postcode, 0.0374823011643247 GOTO)
09224 (Type: place:postcode, node 1201546196, 15, 0.0272824354972261 GOTO)
09212 (Type: place:postcode, 0.0398966083757666 GOTO)

Last edited by couchmapper (2013-10-05 14:45:01)

Netzwolf · 2013-10-05 14:39:51

Nahmd,

Lampenmann wrote:

Beispiel-Suche: "Pleißenbachstraße, Limbach-Oberfrohna" wird gefunden "Pleißenbachstraße, Limbach-Oberfrohna, Zwickau, Sachsen, 09224, Deutschland, Europäischen Union" Die PLZ ist falsch, eine solche Grenze existierte auch niemals. Die Grenze, die ich für derartige Fehler verantwortlich machte - eine Grenze ohne PLZ und die fälschlicherweise um Niederfrohna (ein vollkommen eigenständiger Ort) außen herum führte - habe ich vor 14 Tagen gelöscht.

Ich finde in Limbach-Oberfrohna keine Postleitzahl. Möglicherweise benutzt Nominatim dann, wenn ein Punkt nicht in einem Postleitzahl-Boundary liegt, die nächstgelegene Postleitzahlgrenze? Das würde die 09224 erklären.

Als Postleitzahlenbuch ist OSM demnach nicht zu verwenden.

Vollständigkeit und Fehlerfreiheit sind bei einem offenen und verteilten Projekt nur schwer™ zu erreichen.
.oO( bei geschlossenen und proprietären aber auch. )

Gruß Wolf

Edit: es fängt damit an, das am Ende von “administrative” das “e” fehlt.

Last edited by Netzwolf (2013-10-05 15:12:00)

rayquaza · 2013-10-05 14:48:07

couchmapper wrote:

Das Problem sind wohl ein paar unvollständig gepflegte Hausnummern-Nodes, wie man hier sieht.

Das verstehe ich jetzt nicht: Warum soll dieser Way wegen einer weit entfernten Hausnummer in 09224 sein, wo er doch in Limbach-Oberfrohna (mit der erkannten Postleitzahl 09212) ist? Und was haben "unvollständige Hausnummer-Nodes" damit zu tun?

couchmapper · 2013-10-05 14:52:17

Ich hab auch nicht verstanden, was Nominatim da treibt und nur auf die Analyseseite verlinkt. Aus irgendwelchen Gründe meint die Suche, dass der Knoten 1201546126 maßgeblich für die PLZ im Suchergebnis ist (Type: place:postcode). Könnte ein Bug sein.

Lampenmann · 2013-10-05 15:24:25

rayquaza wrote:

Du hast die Grenze der Verwaltungsgemeinschaft Limbach-Oberfrohna entfernt, das wolltest du sicherlich nicht

doch, das wolte ich, eine PLZ steht in der Grenze nicht drin und Niederfrohna ist nicht in der Verwaltungsgemeinschaft Limbach-Oberfrohna drin.

In der administrativen Grenze von Grainau ist die Postleitzahl drin, allerdings mit OpenGeoDB 82491

Funktionieren tut Grainau so oder so nicht richtig.

Grenze von Limbach-Oberfrohna
Grenze von Hartmannsdorf
Multipolygon von Hartmannsdorf
Grenze von Grainau

Last edited by Lampenmann (2013-10-05 15:27:10)

Lampenmann · 2013-10-05 15:37:45

Ok, offenbar habe ich einen Fehler gemacht. ich werde sehen wie ich das wieder rückgängig machen kann.

Hätte ich nicht gedacht...... Grenzen sind zu schwer für mich....

siehe: https://de.wikipedia.org/wiki/de:Verwal … uselang=de

rayquaza · 2013-10-05 16:00:34

Lampenmann wrote:

Ok, offenbar habe ich einen Fehler gemacht. ich werde sehen wie ich das wieder rückgängig machen kann.
Hätte ich nicht gedacht...... Grenzen sind zu schwer für mich...

Ich wusste auch nicht, dass es "Verwaltungsgemeinschaften" gibt, bis ich in OSM die meiner Gemeinde gesehen habe (ich wollte deshalb eigentlich auch das Wort unterstreichen, aber die Forensoftware wollte nicht).

Zum Reverten: In JOSM das undelete-Plugin installieren, dessen Dialog aufrufen (iirc im Datei-Menü), die ID der oben genannten Relation eingeben, bestätigen. Vor Hochladen nochmal drüberschauen nicht vergessen (besonders, ob es immernoch geschlossen ist)!

rayquaza · 2013-10-05 16:02:56

Lampenmann wrote:

In der administrativen Grenze von Grainau ist die Postleitzahl drin, allerdings mit OpenGeoDB 82491

Die OpenGeoDB-Dinger zählen nicht

Lampenmann · 2013-10-05 17:57:06

Vielen Dank. Werde mal das Undelete-Plugin installieren. Leider habe ich die Relation ohne nochmal ins Forum zu schauen neu erstellt weil mir das mit dem XML-Download zu kompliziert war. Vielleicht schaue ich dennoch dass ich die Original-Relation wiederherstelle.

Grainau werde ich auch noch ändern. Und für die Postleitzahl werde ich eben Postleitzahlen zu den Hausnummern hinzufügen. In Rußdorf hat das jedenfalls geholfen. Nominatim scheint die Grenzen zu ignorieren.

Last edited by Lampenmann (2013-10-05 18:31:43)

viw · 2013-10-05 18:15:02

Lampenmann wrote:

Vielen Dank. Werde mal das Revert-Plugin installieren. Leider habe ich die Relation ohne nochmal ins Forum zu schauen neu erstellt weil mir das mit dem XML-Download zu kompliziert war. Vielleicht schaue ich dennoch dass ich die Original-Relation wiederherstelle.
Grainau werde ich auch noch ändern. Und für die Postleitzahl werde ich eben Postleitzahlen zu den Hausnummern hinzufügen. In Rußdorf hat das jedenfalls geholfen. Nominatim scheint die Grenzen zu ignorieren.

Du solltestet nicht so pauschal urteilen. Es ist nur einfach sehr schwierig in den Daten zu suchen und dabei sämtliche Hirachien zu berücksichtigen. Daher wird den Adressen oft auch die Straße als Tag und nicht über eine Relation beigefügt. Bzw. man überlässt es erst recht nicht dem Auswerter die Zuordnung des Gebäudes zu einer nahegelegenen Straße zu machen.
Das würde nicht nur viel rechenaufwand bedeuten, sondern führt auch zu Fehlinterpretation.

Lampenmann · 2013-10-05 18:48:46

viw wrote:

Zuordnung des Gebäudes zu einer nahegelegenen Straße zu machen.
Das würde nicht nur viel rechenaufwand bedeuten, sondern führt auch zu Fehlinterpretation.

Die Straßennamen werden ja in der Regel in ein Gebäude mit rein geschrieben, nur Postleitzahl und Ort und Ortsteil fehlen häufig.
Straßen kann man deshalb nicht über Relationen hinzufügen, weil sie nicht geschlossen sind. Man müsste Grenzen für Straßen bauen, das wäre sehr aufwendig und das muss genau sein, dass kein Häuschen, das weitab der Straße doch noch dazu gehört, raus fällt aus dem Straßengebiet. Postleitzahlen sind jedoch geschlossene Gebiete und die Grenzen existieren denke ich mal alle. Allerdings sind die Grenzen oft sehr ungenau, so dass Häuser aus dem Gebiet fallen wenn man sie nicht korrigiert. Vielleicht werden die Grenzen deshalb ignoriert. Hätte OSM genaue Grenzen wäre die Postleitzahl, der Ort und der Ortsteil anhand der Grenzen automatisch zu ermitteln. Nicht vorhanden oder selten vorhanden sind Grenzen für Ortsteile die alle dieselbe Postleitzahl haben.

Die Grenze von limbach ist sehr ungenau und viele Häuser waren wirklich auf der falschen Seite. So nahe Röhrsdorf und extrem an der Grenze zu Callenberg, da diese gewissermaßen unlogisch verläuft.

Also kurz gesagt: Ohne funktionierende und genaue Grenzen braucht man vollständige Adressangaben in jeder Hausnummer.

Last edited by Lampenmann (2013-10-05 18:51:23)

rayquaza · 2013-10-05 19:00:13

Lampenmann wrote:

Straßen kann man deshalb nicht über Relationen hinzufügen, weil sie nicht geschlossen sind. Man müsste Grenzen für Straßen bauen

Relation heisst nicht zwingend Grenzrelation: associatedStreet

Lampenmann wrote:

Allerdings sind die Grenzen oft sehr ungenau, so dass Häuser aus dem Gebiet fallen wenn man sie nicht korrigiert. Vielleicht werden die Grenzen deshalb ignoriert.

Allerdings werden die Grenzen auch nur korrigiert werden, wenn sie nicht ignoriert werden. Nominatim als Referenzimplementierung sollte sie imo beachten.

Lampenmann wrote:

Nicht vorhanden oder selten vorhanden sind Grenzen für Ortsteile die alle dieselbe Postleitzahl haben.

Du meinst gar keine (also auch keine administrative) Grenze vorhanden? Das liegt dann vermutlich daran, dass Daten für die Einteilung unterhalb von admin_level=8 (Gemeinden) schwerer zu erhalten sind.

Lampenmann wrote:

Die Grenze von limbach ist sehr ungenau und viele Häuser waren wirklich auf der falschen Seite. So hane Röhrsdorf und extrem an der Grenze zu Callenberg, da diese gewissermaßen unlogisch verläuft.

Meinst du Postleitzahl- oder Verwaltungs-Grenze? Bei letzterer prüfe vor Verschiebungen unbedingt genau, welche Quelle genauer ist (bei ersterer natürlich auch, aber da sind nötige Korrekturen eher wahrscheinlich).

Lampenmann wrote:

Also kurz gesagt: Ohne funktionierende und genaue Grenzen braucht man vollständige Adressangaben in jeder Hausnummer.

Würde ich anders sehen: Ohne funktionierende und genaue Grenzen braucht man funktionierende und (hinreichend) genaue Grenzen

viw · 2013-10-05 19:21:35

Wenn jede Adresse auch PLZ und Ort enthält dann kann jeder Texteditor diese in der OSM Datei finden.
Wenn man sich hier jedoch auf Grenzen verlässt, dann erfordert das entweder große Vorbereitungen oder aber eine Datenbank die damit umgehen kann. Aber wenn schon zwei Informationen von verschiedenen Grenzen geprüft werden müssen, dann wird das auch nicht schneller oder leistungsfähiger.
Wenn man dann auch noch eine unscharfe Suche zulassen möchte dann wird er Suchraum sehr groß.

seichter · 2013-10-05 20:08:04

Es gibt zwei Möglichkeiten für die PLZ:
- per Relation/Grenze entweder eigenständig als boundary=postal_code oder als Zusatzangabe an einer administrative-Grenze
- im Node/Way/MP des Gebäudes als addr:postcode
Beides zusammen ist theoretisch redundant, in der Praxis aber doch hilfreich.

Die Auswerter tun sich mit postcode am Gebäude viel leichter als per Auswertung ob innerhalb einer boundary. Insbesondere sind die PLZ-boundaries innerhalb Gemeinden oft nur sehr grob, so dass an den Grenzen die Zuordnung häufig nicht stimmt.

Anders sieht es aus, wenn Gemeindegrenzen und PLZ-Grenzen übereinstimmen, da die admin-Grenzen z.B. in BaWü ziemlich genau sind. Da konnte ich mit der Postcode-Map von wambacher (als sie noch verfügbar war) einige falsch getaggte addr:postcode an Gebäuden identifizieren und korrigieren. Das kommt vor allem an Stellen zu tragen, an dem Wohn-/Gewerbegebiete direkt aneinander grenzen. Auf dem flachen Land, wo die besiedelten Gebiete weit auseinander liegen, reicht die PLZ an den Grenzen eigentlich aus.

Wie so häufig ist keine der beiden Methoden für sich allein die einzig wahre.

geri-oc · 2013-10-06 09:19:39

Grenzen von Gemeinden und PLZ sind durch Gemeindezusammenschlüsse meist schon unterschiedlich. Dazu kommen Grenzen von Verwaltungsgemeinschaften, die auch mehrer Gemeinde- oder PLZ-Grenzen enthalten können. Auch auf dem flachen Land liegen teilweise Gebäude verschiedener Grenzen (Verwaltung, Gemeinde, PLZ) eng nebeneinander.

Die einfachste Methode, auch für Neueinsteiger, ist das setzen des kompletten addr:* Blockes (was allerdings von Nominatim nicht genutzt wird (?) - und durch naheliegende places oder Grenzen "falsch" gefunden wird).

couchmapper · 2013-10-06 09:32:43

Die beiden unvollständigen Hausnummern-Knoten habe ich jetzt mal in das umgebende Gebäude geschoben (Changeset 18207763) und die beiden Knoten gelöscht. Immerhin tauchen diese beiden Knoten sowie die beiden aktualisierten Gebäude jetzt nicht mehr bei Nominatim auf der Analyseseite auf.

Last edited by couchmapper (2013-10-06 09:33:26)

seichter · 2013-10-06 10:25:35

geri-oc wrote:

Grenzen von Gemeinden und PLZ sind durch Gemeindezusammenschlüsse meist schon unterschiedlich. Dazu kommen Grenzen von Verwaltungsgemeinschaften, die auch mehrer Gemeinde- oder PLZ-Grenzen enthalten können. Auch auf dem flachen Land liegen teilweise Gebäude verschiedener Grenzen (Verwaltung, Gemeinde, PLZ) eng nebeneinander.

Es ist nicht erforderlich dass die PLZ-Gebiete und Gemeindegebiete übereinstimmen, es reicht, wenn die PLZ-Grenzen Teile der administrativen Grenzen "mitnutzen". Das muss dann natürlich in eine eigene postal_code-Relation, die sich schnell aus Mitgliedern der admin-Relationen zusammenstellen lässt.

Dass auch auf dem flachen Land bewohnte Gebiete aneinander stoßen können, ist klar. Da ist addr:postcode dann hilfreich. Ich meine nur, dass diese redundanten Tags in weiten Gebieten nicht notwendig bis überflüssig sind.

Fehlzuordnungen per näher liegendem place-Nodes sprechen eher dafür, die place-Informationen nicht an einen mehr oder weniger geschickt gewählten Knoten irgendwo im Gebiet zu heften, sondern in die Gebietsgrenze oder -relation mit aufzunehmen.

Damit kommen wir aber wieder an das Grundproblem, wie stark wir das Taggen an die Fähigkeiten und Probleme der Auswerter wie Nominatim anpassen. Wir taggen zwar nicht für den Renderer, aber auch nicht so gern nur für die Datenbank, sondern für den Nutzer.

wambacher · 2013-10-06 11:36:54

seichter wrote:

Fehlzuordnungen per näher liegendem place-Nodes sprechen eher dafür, die place-Informationen nicht an einen mehr oder weniger geschickt gewählten Knoten irgendwo im Gebiet zu heften, sondern in die Gebietsgrenze oder -relation mit aufzunehmen.

+1

Place-Nodes beschreiben -für mich- "places" (Plätze/Lokalitäten): überschaubare Bereiche mit geringer Ausdehnung.
Städte, Stadtteile oder PLZ-Gebiete gehören nicht dazu.

Aus einem Knoten die Eigenschaften einer (undefinierten) Fläche ableiten zu wollen, halte ich für sehr gewagt.

Gruss
walter

EvanE · 2013-10-06 13:25:11

wambacher wrote:

seichter wrote:
Fehlzuordnungen per näher liegendem place-Nodes sprechen eher dafür, die place-Informationen nicht an einen mehr oder weniger geschickt gewählten Knoten irgendwo im Gebiet zu heften, sondern in die Gebietsgrenze oder -relation mit aufzunehmen.
+1
Place-Nodes beschreiben -für mich- "places" (Plätze/Lokalitäten): überschaubare Bereiche mit geringer Ausdehnung.
Städte, Stadtteile oder PLZ-Gebiete gehören nicht dazu.
Aus einem Knoten die Eigenschaften einer (undefinierten) Fläche ableiten zu wollen, halte ich für sehr gewagt.

Hallo Walter

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.

Edbert (EvanE)

Last edited by EvanE (2013-10-06 13:27:50)

Lampenmann · 2013-10-06 15:43:20

rayquaza wrote:

[Würde ich anders sehen: Ohne funktionierende und genaue Grenzen braucht man funktionierende und (hinreichend) genaue Grenzen

Dort wo ich die Grenze verschoben habe, wusste ich ganz genau, dass die betreffenden Gebiete zu Limbach-Oberfrohna gehören und habe das mit einem Postleitzahlenbuch überprüft. Ich habe festgestellt, dass Nominatim die Grenzen komplett ignoriert. Da wir mit Nominatim suchen, finden wir ohne den Auswerter nichts und sollten so taggen, dass die Orte in der Suche richtig gefunden werden. Ich werde ggf. mal zur die Stadtverwaltung gehen und um Grenzen für Ortsteile bitten... Aber eher nicht um sie einzupflegen, sondern um addr:suburb in Hausnummern zu taggen. Die Grenzen wurden glaube ich sowieso in einem automatisierten Verfahren eingefügt.

Ich würde eher nicht Adressen korrigieren die nicht mit Grenzen übereinstimmen, denn im Zweifel stimmt die Grenze nicht - möglicherweise auch in baden Württemberg, wobei ich dort noch nicht die Möglichkeit hatte die Genauigkeit der Grenzen zu überprüfen.

Google hat teilweise total falsche Adressen die an total falschen Orten angezeigt werden, Hier hat OSM dem Google schon etwas voraus, denn falsche Adressen gibt es wohl eher selten.

Durch falschen Grenzverlauf sind sogar Fehler in Bing. ich denke auf Grenzen sollte sich OSM auf lange Sicht nicht verlassen, denn es ist wohl eher unmöglich die in absehbarer Zeit 100% hinzubekommen.

wambacher · 2013-10-06 16:17:52

EvanE wrote:

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.

Gruss
walter

seichter · 2013-10-06 16:53:58

Lampenmann wrote:

Ich würde eher nicht Adressen korrigieren die nicht mit Grenzen übereinstimmen, denn im Zweifel stimmt die Grenze nicht - möglicherweise auch in baden Württemberg, wobei ich dort noch nicht die Möglichkeit hatte die Genauigkeit der Grenzen zu überprüfen.

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.

Lampenmann · 2013-10-18 16:43:30

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.

Last edited by Lampenmann (2013-10-18 16:45:10)

Announcement

#1 2013-10-05 13:53:30

Falsche Postleitzahlen - Ursache unbekannt

#2 2013-10-05 14:26:30

Re: Falsche Postleitzahlen - Ursache unbekannt

#3 2013-10-05 14:37:20

Re: Falsche Postleitzahlen - Ursache unbekannt

#4 2013-10-05 14:39:51

Re: Falsche Postleitzahlen - Ursache unbekannt

#5 2013-10-05 14:48:07

Re: Falsche Postleitzahlen - Ursache unbekannt

#6 2013-10-05 14:52:17

Re: Falsche Postleitzahlen - Ursache unbekannt

#7 2013-10-05 15:24:25

Re: Falsche Postleitzahlen - Ursache unbekannt

#8 2013-10-05 15:37:45

Re: Falsche Postleitzahlen - Ursache unbekannt

#9 2013-10-05 16:00:34

Re: Falsche Postleitzahlen - Ursache unbekannt

#10 2013-10-05 16:02:56

Re: Falsche Postleitzahlen - Ursache unbekannt

#11 2013-10-05 17:57:06

Re: Falsche Postleitzahlen - Ursache unbekannt

#12 2013-10-05 18:15:02

Re: Falsche Postleitzahlen - Ursache unbekannt

#13 2013-10-05 18:48:46

Re: Falsche Postleitzahlen - Ursache unbekannt

#14 2013-10-05 19:00:13

Re: Falsche Postleitzahlen - Ursache unbekannt

#15 2013-10-05 19:21:35

Re: Falsche Postleitzahlen - Ursache unbekannt

#16 2013-10-05 20:08:04

Re: Falsche Postleitzahlen - Ursache unbekannt

#17 2013-10-06 09:19:39

Re: Falsche Postleitzahlen - Ursache unbekannt

#18 2013-10-06 09:32:43

Re: Falsche Postleitzahlen - Ursache unbekannt

#19 2013-10-06 10:25:35

Re: Falsche Postleitzahlen - Ursache unbekannt

#20 2013-10-06 11:36:54

Re: Falsche Postleitzahlen - Ursache unbekannt

#21 2013-10-06 13:25:11

Re: Falsche Postleitzahlen - Ursache unbekannt

#22 2013-10-06 15:43:20

Re: Falsche Postleitzahlen - Ursache unbekannt

#23 2013-10-06 16:17:52

Re: Falsche Postleitzahlen - Ursache unbekannt

#24 2013-10-06 16:53:58

Re: Falsche Postleitzahlen - Ursache unbekannt

#25 2013-10-18 16:43:30

Re: Falsche Postleitzahlen - Ursache unbekannt

Board footer