Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

wambacher · 2013-04-04 11:03:35

g0ldfish wrote:

Ist das eigentlich abgeschlossen? Hier laufen immer noch alte und neue Linie parallel und sind beide mit boundary=administrative getaggt:
http://www.openstreetmap.org/browse/way/42557946
http://www.openstreetmap.org/browse/way/207106803

Nö, natürlich nicht - genausso wie ich es erwartet habe. und die obsolete_boundary sind auch noch alle da.
der Herr treibt sich jetzt lieber in wärmeren Gefilden rum: http://www.openstreetmap.org/user/seichter/edits

seichter · 2013-04-05 17:48:34

g0ldfish wrote:

Ist das eigentlich abgeschlossen? Hier laufen immer noch alte und neue Linie parallel und sind beide mit boundary=administrative getaggt:
http://www.openstreetmap.org/browse/way/42557946
http://www.openstreetmap.org/browse/way/207106803

Das und weitere (meist Kreisgrenzen) wurde bereinigt. Am Rand des bearbeiteten Gebietes (im wesentlichen RegBez TÜ) bleiben aber doppelte Linien, da sonst weitere Grenzen "im Leeren" enden würden.
"obsolete_boundary" darf jeder gerne löschen, der vor Ort sicher ist, dass die LGL-Grenzen besser sind und wenn sie in keinen aktiven Relationen (z.B. admin_level=7,9,10) mehr enthalten sind.
Off Topic @wambacher: Rumnörgeln vom hohen Roß herunter wirkt nicht unbedingt motivierend, hilfreiche Hinweise fände ich besser, in grauer Vorzeit gab es mal etwas namens Netiquette ...

Last edited by seichter (2013-04-05 18:28:08)

g0ldfish · 2013-04-08 16:46:16

Ich bin nicht aus der Ecke, und ich bin nicht ganz so "import-kritisch" wie manch einer hier. Trotzdem wäre aus meiner Sicht eine andere Vorgehensweise angemessener gewesen:

Entweder den Import komplett planen, wenn eine vorhergehende Diskussion den Schluss zulässt, dass die Daten insgesamt besser sind als die vorhandenen. Komplett hieße dann aber auch inkl. Übertragen der Relationszugehörigkeiten, Entfernen (oder noch besser Ersetzen) der alten Grenzlinien, Plan für die absehbaren Probleme wie die angesprochenen Anschlüsse an den Außengrenzen des Imports.

Oder, wenn manuelle Nachbearbeitung unumgänglich erscheint, vorab lokale Mapper zusammentrommeln, die dazu bereit sind, bzw. nur das Hochladen, was man selbst nachbearbeiten kann und will.

Oli-Wan · 2013-04-08 17:10:28

Die doppelten Knoten sind jedenfalls mit Ausnahme einer Grenze nördlich von Ulm beseitigt. Zu mehrfachen Wegen kann ich nichts sagen.

Aber falls jemand anderweitig aufräumen will, es gibt auch Doppelknoten aus sonstigen Quellen. Aktuell für BW: http://toolserver.org/~mapjedi/dupenodes_bw.osm.bz2
(Diese Datei nicht bearbeiten/hochladen, sondern als Hintergrund/Hilfsebene verwenden, um Hotspots zu finden. Die kontaminierte Region in eine neue Ebene laden, bearbeiten, hochladen.
Für Fortgeschrittene: Vor dem Herunterladen der tatsächlich zu bearbeitenden Daten die Knoten in der Hilfsebene auswählen, nach dem Bearbeiten bereinigen -nicht: löschen.)

mmd · 2013-04-08 21:59:06

.

Last edited by mmd (2013-04-27 21:58:26)

MetiorErgoSum · 2013-04-10 18:01:56

Gerade ist mir aufgefallen, dass am 10.3. in diesem Changeset mit dem wenig aussagekräftigen Kommentar "obsolete -> multipolygon" zahlreiche bayerische Gemeindegrenzen von boundary = administrative auf obsolete_boundary = administrative gesetzt wurden, z.B. diese Grenzlinie. Diese Grenzen sind natürlich nicht obsolet und das Tag ist falsch.

seichter · 2013-04-10 21:32:57

MetiorErgoSum wrote:

Gerade ist mir aufgefallen, dass am 10.3. in diesem Changeset mit dem wenig aussagekräftigen Kommentar "obsolete -> multipolygon" zahlreiche bayerische Gemeindegrenzen von boundary = administrative auf obsolete_boundary = administrative gesetzt wurden, z.B. diese Grenzlinie. Diese Grenzen sind natürlich nicht obsolet und das Tag ist falsch.

Danke für den Hinweis. Da habe ich beim Filtern einer Auswahl offensichtlich übersehen, dass ich auch ein paar Grenzen im Freistaat Bayern mit erwischt habe. Müsste behoben sein.

whb · 2013-04-15 16:21:35

seichter wrote:

Dies ist problemlos möglich, da die Ways und Nodes aus Bayern und aus BW bis auf weniger als 1 m übereinstimmen.

Soeben habe ich die Shape-Dateien (Gemeinden) mit QGIS nach WGS 84 transformiert und dabei die BeTA2007-Daten verwendet.
Die Grenzen (BW/BY) stimmen jetzt sehr gut überein, maximale Abweichung liegt unter 1 cm (0,01 m).
Ob jetzt die Transformation von seichter oder mir genauer ist, weiß ich nicht.

Danach habe ich mit GRASS die geschlossenen Grenzringe passend segmentiert, so dass sich angrenzende Gemeinden dieselben Linien teilen.
Diese Shape-Datei habe ich dann mit dem OpenData-Plugin für JOSM in eine OSM-Datei umgewandelt, mit passenden source-Tags ergänzt und hochgeladen:
https://www.dropbox.com/s/lmmi7jnc9quqj … zen_BW.osm
Datenquelle: LGL, www.lgl-bw.de
Lizenz: CC BY 3.0

Viele Grüße,
whb

Last edited by whb (2013-04-15 16:23:29)

wambacher · 2013-04-15 17:14:11

whb wrote:

Diese Shape-Datei habe ich dann mit dem OpenData-Plugin für JOSM in eine OSM-Datei umgewandelt, mit passenden source-Tags ergänzt und hochgeladen:
https://www.dropbox.com/s/lmmi7jnc9quqj … zen_BW.osm

toll, und nu?
bisher haben wir in OSM da unten noch den Altbestand (obsolete_boundary) als Ways und Relationen, dann die von einigen Wochen importieren Daten und jetzt schon wieder neue Datensätze. Hatte mich erst erschrocken, da man deinen Beitrag auch mit "hab ich dann nach OSM hochgeladen" interpretieren konnte. War zum Glück nicht so - bist ja Profi.

Aber dennoch: wat nu?

Gruss
walter

whb · 2013-04-15 18:59:14

wambacher wrote:

toll, und nu?

Fehler gefunden?

wambacher wrote:

bisher haben wir in OSM da unten noch den Altbestand (obsolete_boundary) als Ways und Relationen

Dafür kann ich nichts.
Aber ich bemühe mich sehr ernsthaft darum, es richtig zu machen.
Hilfst du mit?

wambacher wrote:

Hatte mich erst erschrocken, da man deinen Beitrag auch mit "hab ich dann nach OSM hochgeladen" interpretieren konnte. War zum Glück nicht so - bist ja Profi.

Entschuldigung, dass du dich erschrocken hast.
Profi bin ich sicher nicht.

wambacher wrote:

Aber dennoch: wat nu?

Wenn die Daten in Ordnung sind, dann werde ich mich um die Aufteilung in kleinere Pakete kümmern, so wie hier:
http://wiki.openstreetmap.org/wiki/Baye … Initiative

Viele Grüße,
whb

wambacher · 2013-04-15 20:24:31

whb wrote:

[
wambacher wrote:
Aber dennoch: wat nu?
Wenn die Daten in Ordnung sind, dann werde ich mich um die Aufteilung in kleinere Pakete kümmern, so wie hier:
http://wiki.openstreetmap.org/wiki/Baye … Initiative

Die Daten sind schon in Ordnung - aber ob die besser sind als die zuletzt leider etwas unglücklich hochgeladenenen, wage ich zu bezweifeln. Hier mal ein Screenshot bei http://www.openstreetmap.org/browse/node/2167410640

rot - alte Daten, die mit obsolete_boundary=administrative getaggt aber immer noch nicht gelöscht wurden
pink - vor einigen Wochen hochgeladenen Daten
grau: "deine" Daten

Die letzten beiden Datensätze stammen ja aus dem gleichen Datenbestand der LDL und sind somit fast identisch: gleiche Nodes mit geringfügiger Verschiebung im Meter-Bereich. Welcher der beiden nun "besser" ist, mag ich nicht beurteilen. Aber "einfach" nur die violetten Ways manuell durch "deine" Ways zu ersetzen, halte ich für viel zu mühsam.

Das könnte übrigens auch eine kleine Umrechnung aller betroffenen Nodes (Formel1 -> Formel2) erledigen, wäre aber ein mechanical Edit..

tl;dr: halte ich für unnötig und mache daher wohl nicht mit. Aufräumen wäre ok aber bitte nicht fast identische Ways austauschen.

Gruss
walter

streckenkundler · 2013-04-15 20:52:38

Hallo Walter,

wambacher wrote:

pink - vor einigen Wochen hochgeladenen Daten
grau: "deine" Daten

bei beiden scheint die Abweichung zueinander annähernd im Meter- oder sogar im Submeterbereich zu liegen, im Vergleich zu anderen Dingen sehr gering. Angesichts des gleichen Versatzes der im Screenshot sichtbaren 5 Punktepaare halte ich persönlich die Abweichung für ein Ergebnis unterschiedlicher Transformationsmethoden: BETA2007 und "nicht BETA2007" Zur Beurteilung wären auch offizielle Vektordaten zum Vergleich interessant. Ist BW bereits auf ETRS und/oder AAA umgetellt? Dann würden zu mindestens kompaktible Koordinaten zum Vergleich vorliegen.

Sven

seichter · 2013-04-15 22:07:46

streckenkundler wrote:

Hallo Walter,
wambacher wrote:
pink - vor einigen Wochen hochgeladenen Daten
grau: "deine" Daten
bei beiden scheint die Abweichung zueinander annähernd im Meter- oder sogar im Submeterbereich zu liegen, im Vergleich zu anderen Dingen sehr gering. Angesichts des gleichen Versatzes der im Screenshot sichtbaren 5 Punktepaare halte ich persönlich die Abweichung für ein Ergebnis unterschiedlicher Transformationsmethoden: BETA2007 und "nicht BETA2007" Zur Beurteilung wären auch offizielle Vektordaten zum Vergleich interessant. Ist BW bereits auf ETRS und/oder AAA umgetellt? Dann würden zu mindestens kompaktible Koordinaten zum Vergleich vorliegen.
Sven

Ich habe dieselben Werkzeuge/Daten benutzt wie whb, auch beta2007. Wenn der workflow aber nicht identisch ist, können unterschiedliche Ergebnisse resultieren. Schon das Abspeichern von Zwischenergebnissen und wieder einlesen kann einen Unterschied machen. Per Mehrheitsprinzip halte ich die Daten von Bayern und whb für genauer. Alles unter einem Meter betrachte ich für die Zwecke von OSM aber als irrelevant, deshalb hat mir die kleine Abweichung an der Grenze zu Bayern kein Kopfweh bereitet.
Die LGL-Daten sind noch Gauß-Krüger, BW ist erst dabei, umzustellen. Die freigegebenen Daten sind aber sowieso vereinfacht, für die exakten Daten auf Kataster-Niveau muss weiterhin gezahlt werden.
An der Landesgrenze sind die Stützpunkte offensichtlich mit den Kollegen aus Bayern abgestimmt, im Inneren aber misstraue ich den Daten an manchen Stellen. Man kann es schon am Abstand der Stützpunkte abschätzen: Die liegen sehr oft nur wenige Meter auseinander, gelegentlich aber zig Meter. An der Stadtgrenze Reutlingen sieht man an einer Stelle, wie die Grenze auf den Meter genau zwischen zwei Häusern einer Reihenhauszeile durchgeht (stimmt laut Kataster tatsächlich), an anderer Stelle liegt sie 10 m neben einem OSM-Weg, der nach GPS-Tracks und Bing bis auf ein bis zwei Meter exakt liegt, und auf dem sie laut Kataster verlaufen sollte. An dieser Stelle war die alte Grenze genauer (und ich habe die neue Grenze dorthin verschoben).
Solche Fälle sind die Ausnahme, aber es gibt sie. Das war der Grund, weshalb ich die alten Grenzen nicht löschen wollte.

Zum weiteren Vorgehen: Im betreffenden Gebiet müssten alle Verwaltungsverbünde (level 7) umgestellt sein, momentan binde ich alle Grenzen unterhalb Gemeindeebene (level 9-11, PLZ) an die neuen Grenzen an (sind in den LGL-Daten nicht enthalten) und lösche obsolete-Relationen Zug um Zug, da deren Attribute in den neuen Relationen enthalten sein müssten. Ich bitte aber um Geduld, da ich gelegentlich auch noch Anderes zu tun habe (auf Mithilfe brauche ich wohl nicht zu hoffen). Die Außengrenzen kommen zum Schluss dran, da gibt es aber z.B in Südbaden schon wenigstens einen, der die neuen Grenzen schon Stück für Stück erweitert.

whb · 2013-04-16 00:19:28

wambacher wrote:

tl;dr:

Könntest du das bitte übersetzen?

wambacher wrote:

halte ich für unnötig und mache daher wohl nicht mit. Aufräumen wäre ok aber bitte nicht fast identische Ways austauschen.

Ich dachte eher daran, die noch fehlenden LGL-Grenzen einzuarbeiten, nicht die schon eingetragenen LGL-Grenzen nochmals zu verbessern.
Dabei könntest du helfen, denn das ist nicht unnötig.

Die Frage ist jetzt eigentlich nur, welche aufbereiteten Daten ich nehmen soll, die von seichter oder die von mir.
Würde mich dann von Nordwesten aus vorarbeiten.

Viele Grüße,
whb

wambacher · 2013-04-16 00:41:53

seichter wrote:

Ich habe dieselben Werkzeuge/Daten benutzt wie whb, auch beta2007. Wenn der workflow aber nicht identisch ist, können unterschiedliche Ergebnisse resultieren. Schon das Abspeichern von Zwischenergebnissen und wieder einlesen kann einen Unterschied machen.

Klar, dass zwischen "neu" (pink) und "ganz neu" (grau) kleinere Unterschiede bestehen; beide Datensätze sind aber erheblich besser als die alten Daten. Ich wollte - und will - eigentlich zum Ausdruck bringen, dass ein erneuter Wechsel der Daten nichts bring ausser verdammt viel zusätzliche manuelle Arbeit.

Ich bitte aber um Geduld, da ich gelegentlich auch noch Anderes zu tun habe (auf Mithilfe brauche ich wohl nicht zu hoffen).

Das hat wohl etwas mit der ziemlich planlosen Vorgehensweise zu tun. Wenn es kein - zumindest für mich erkennbares - Konzept gibt, wie soll man da mithelfen? In Bayern ist das anscheinend besser gelaufen.
Ich hab heute mal in einer kleinen Ecke angefangen, ein wenig aufzuräumen, lese aber jetzt deine Bedenken und frag mich, ob ich weiter machen soll. Zumindest im Norden ist ein Kollege auch aktiv.
Nur so zur Info: es geht um 387 obsolete Relationen mit 1158 obsoleten Ways.

Nochmals: Die Daten sind - für mich - ok, 1000x besser als der alte "Schrott" und sollten drin bleiben. danke

Gruss
walter

whb · 2013-04-16 00:56:00

seichter wrote:

Ich habe dieselben Werkzeuge/Daten benutzt wie whb, auch beta2007. Wenn der workflow aber nicht identisch ist, können unterschiedliche Ergebnisse resultieren. Schon das Abspeichern von Zwischenergebnissen und wieder einlesen kann einen Unterschied machen.

Ich habe verschiedene Kombinationen ausprobiert, die Ergebnisse unterscheiden sich kaum.
Die eingesetzten Programmversionen sind hier vermutlich auch von Bedeutung.

Viele Grüße,
whb

whb · 2013-04-16 01:04:04

wambacher wrote:

Wenn es kein - zumindest für mich erkennbares - Konzept gibt, wie soll man da mithelfen?

Ein Konzept erarbeiten?
Aber jetzt ist die Sache doch schon ziemlich weit fortgeschritten.

Viele Grüße,
whb

wambacher · 2013-04-16 01:10:18

whb wrote:

wambacher wrote:
tl;dr
Könntest du das bitte übersetzen?

jo: http://com-gf.de/wiki/TL;DR

Ich dachte eher daran, die noch fehlenden LGL-Grenzen einzuarbeiten, nicht die schon eingetragenen LGL-Grenzen nochmals zu verbessern.
Die Frage ist jetzt eigentlich nur, welche aufbereiteten Daten ich nehmen soll, die von seichter oder die von mir.
Würde mich dann von Nordwesten aus vorarbeiten.

Momang: erst bietest du neue Daten an und plötzlich weist du auf einmal selber nicht mehr, welche Daten wir überhaupt nehmen sollen? Dann hätte ich mir meine Auswertungen und Kommentare ja sparen können. Oder sind in deinem Datenpaket zusätzliche Grenzlinien vorhanden, die sauter noch nicht hochgeladen hat? Ich sehe bisher nur Dubletten (pink versus grau). Fehlende Ways sind natürlich "willkommen".

Ich würde es vorziehen mit sauters Daten weiter zu machen - auch wenn manche Kollegen eventuell nachweisen können, dass die neuen Daten 1 Meter besser sind.

Gruss
walter

whb · 2013-04-16 01:41:57

wambacher wrote:

Momang: erst bietest du neue Daten an und plötzlich weist du auf einmal selber nicht mehr, welche Daten wir überhaupt nehmen sollen?

Warum denn nicht?
Es gibt doch zwei Möglichkeiten:
1.) Man nimmt "meine" Daten, welche mutmaßlich etwas genauer sind und ist damit inkonsistent zu den Daten von seichter.
2.) Man nimmt die Daten von seichter und riskiert damit, dass die Daten u.a. inkonsistent mit zukünftigen Daten von Rheinland-Pfalz und Hessen sind.

Es ist wenig realistisch, dass die schon von seichter eingetragenen Daten geändert werden, da der mutmaßliche Vorteil den Aufwand kaum rechtfertigt.
Anders sieht es hingegen bei den bisher nicht eingearbeiteten Daten aus.

wambacher wrote:

Dann hätte ich mir meine Auswertungen und Kommentare ja sparen können.

Wenn du meinst.

wambacher wrote:

Oder sind in deinem Datenpaket zusätzliche Grenzlinien vorhanden, die sauter noch nicht hochgeladen hat? Ich sehe bisher nur Dubletten (pink versus grau). Fehlende Ways sind natürlich "willkommen".

Grob geschätzt wurde bisher etwas weniger als die Hälfte von Baden-Württemberg abgearbeitet, zumindest wenn ich dem Ergebnis der Suche nach boundary=administrative + source=LGL, www.lgl-bw.de über die Overpass-API glauben darf.
Der Norden fehlt demnach noch komplett und der Westen ebenfalls, wenn man von einigen wenigen Ausnahmen absieht.

Viele Grüße,
whb

Last edited by whb (2013-04-16 01:53:16)

seichter · 2013-04-16 10:20:44

whb wrote:

Es gibt doch zwei Möglichkeiten:
1.) Man nimmt "meine" Daten, welche mutmaßlich etwas genauer sind und ist damit inkonsistent zu den Daten von seichter.
2.) Man nimmt die Daten von seichter und riskiert damit, dass die Daten u.a. inkonsistent mit zukünftigen Daten von Rheinland-Pfalz und Hessen sind.

Inkonsistenz ist hier eher theoretischer Natur: Die Knoten zu Bayern liegen beidesmal auseinander und müssen auf jeden Fall per merge vereinigt werden (eines der beiden Grenzsegmente muss dabei natürlich entfernt/vereinigt werden). Ob man den LGL-Knoten um 60 oder 3 cm verschiebt (oder gar die der Bayern), ist da ziemlich nebensächlich. Auch an den Innengrenzen ist der Aufwand praktisch identisch, da neu hinzugekommenene Endknoten der Segmente zwar identische Koordinaten haben mögen, in der OSM-DB aber mit zwei unterschiedlichen IDs geführt würden, die man explizit vereinigen muss.

whb wrote:

Es ist wenig realistisch, dass die schon von seichter eingetragenen Daten geändert werden, da der mutmaßliche Vorteil den Aufwand kaum rechtfertigt.
Anders sieht es hingegen bei den bisher nicht eingearbeiteten Daten aus.

Der Aufwand lohnt m.E. wirklich nicht, wenn die vom LGL "vereinfachten" öffentlichen Daten um mehrere Meter neben den exakten Grenzen liegen. Damit aber kein Missverständnis aufkommt: Die LGL-Daten sind in 99 % der Fälle um Längen besser als die bisher vorhandenen Grenzen.

wambacher wrote:

Oder sind in deinem Datenpaket zusätzliche Grenzlinien vorhanden, die sauter noch nicht hochgeladen hat? Ich sehe bisher nur Dubletten (pink versus grau). Fehlende Ways sind natürlich "willkommen".

whb wrote:

Grob geschätzt wurde bisher etwas weniger als die Hälfte von Baden-Württemberg abgearbeitet, zumindest wenn ich dem Ergebnis der Suche nach boundary=administrative + source=LGL, www.lgl-bw.de über die Overpass-API glauben darf.
Der Norden fehlt demnach noch komplett und der Westen ebenfalls, wenn man von einigen wenigen Ausnahmen absieht.
Viele Grüße,
whb

Wenn ich zur Klärung beitragen darf: Ich habe den RegBez Tübingen und ein paar angrenzende Kreise, die ich kenne, bearbeitet. Das dürften mehr als ein Viertel von BW sein. Falls ich je noch weitere Grenzen importieren sollte, werde ich die Segmente aus
https://www.dropbox.com/s/lmmi7jnc9quqj … zen_BW.osm
nehmen. Ich nehme an, dass ich auch andere auf diese Daten verweisen darf.

Last edited by seichter (2013-04-16 12:32:25)

wambacher · 2013-04-16 11:06:12

ok, ich klink mich aus bis ihr euch geeinigt habt und die Kommunikation (wiki) organisiert ist.

Es ist - zumindest mir - weiterhin völlig unklar, wer denn nun welche Daten wohin schieben will und was endlich gelöscht werden kann. Und das im "Musterländle".

Gruss
walter

whb · 2013-04-16 11:09:03

seichter wrote:

Wenn ich zur Klärung beitragen darf: Ich haben den RegBez Tübingen und ein paar angrenzende Kreise, die ich kenne, bearbeitet. Das dürften mehr als ein Viertel von BW sein.

Gut, hier auch noch eine Grafik:

Von wem die Grenzen bearbeitet wurden, habe ich aber nicht genauer nachgesehen.

seichter wrote:

Ich nehme an, dass ich auch andere auf diese Daten verweisen darf.

Ja.

Viele Grüße,
whb

Announcement

#26 2013-04-04 11:03:35

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#27 2013-04-05 17:48:34

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#28 2013-04-08 16:46:16

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#29 2013-04-08 17:10:28

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#30 2013-04-08 21:59:06

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#31 2013-04-10 18:01:56

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#32 2013-04-10 21:32:57

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#33 2013-04-15 16:21:35

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#34 2013-04-15 17:14:11

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#35 2013-04-15 18:59:14

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#36 2013-04-15 20:24:31

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#37 2013-04-15 20:52:38

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#38 2013-04-15 22:07:46

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#39 2013-04-16 00:19:28

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#40 2013-04-16 00:41:53

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#41 2013-04-16 00:56:00

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#42 2013-04-16 01:04:04

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#43 2013-04-16 01:10:18

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#44 2013-04-16 01:41:57

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#45 2013-04-16 10:20:44

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#46 2013-04-16 11:06:12

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

#47 2013-04-16 11:09:03

Re: Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

Board footer