From traut at gmx.de Tue Apr 1 08:18:43 2008 From: traut at gmx.de (Martin Trautmann) Date: Tue, 01 Apr 2008 08:18:43 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <20080331231730.69B3.STEPHAN.S@gmx.net> References: <47EAC66D.50608@uni-paderborn.de> <20080331231730.69B3.STEPHAN.S@gmx.net> Message-ID: <47F1D3C3.5020103@gmx.de> Stephan S wrote: > Hallo Peter, > > Da ich keinen Fehler in deinen Überlegungen finden konnte, habe ich mal > einen aktuellen Stand eingespielt um deine Vorgehensweise durchzuspielen. > Dabei habe ich DE.sql, CH.sql und LI.sql, extra.sql importiert und auch > die von Martin zur Verfügung gestellte geodb_hierarchies (für DE als > geodb_hierarchies_orig) zum Vergleich. > >> [...] >> UPDATE geodb_hierarchies SET id_lvl9 = loc_id WHERE `level`= 9; > > Hier ergibt sich ein erster Unterschied: in der geodb_hierarchies_orig > gibt es für diesen level keinen Eintrag, bei mir aber nach dem UPDATE 11 Das kann an einem Fehler meinerseits liegen, weil ich die PLZ mit type 100800000 verpasst hatte und daher level 8 auf 100800000 und level 9 auf 100900000 habe. > >> Hiermit wird jeweils die ID in dem level gesetzt, in der der Eintrag >> selbst zu finden ist - denn die ist ja klar. >> >> ...und ab hier kriege ich Probleme... >> Meine Idee für das weitere Vorgehen: >> Nach und nach fülle ich jetzt Ebene e = 8, 7, 6, ..... über einzelne >> Queries auf. Eigentlich musst du in umgekehrter Richtung arbeiten - zumindest muss ich das mit meinem eigenen Ansatz. > liefert dann 86 Datensätze ohne Eintrag für level 4, ich füge die hier > einfach mal ein: > > loc_id;name;typ > 466;Flensburg;Stadt > 469;Kiel;Landeshauptstadt > 472;Hansestadt Lübeck;Hansestadt > Nehme ich die loc_id 472 (Lübeck) und prüfe die parent.loc_id (119) dann > ist dieses direkt Schleswig-Holstein auf level 3 und die Verknüpfung > über lvl.text_val = 4 passt nicht auf diese loc_id. Hier mal alle hierarchies mit Lübeck INSERT INTO geodb_hierarchies VALUES (20437,6,104,105,119,null,472,20437,null,null,null); /* DE */ (106047,7,104,105,119,null,472,20437,106047,null,null); /* DE */ (106048,8,104,105,119,null,472,20437,106047,106048,null); /* DE */ (106049,8,104,105,119,null,472,20437,106047,106049,null); /* DE */ (106046,8,104,105,119,null,472,20437,null,106046,null); /* DE */ (106050,8,104,105,119,null,472,20437,null,106050,null); /* DE */ (106051,8,104,105,119,null,472,20437,null,106051,null); /* DE */ (106052,8,104,105,119,null,472,20437,null,106052,null); /* DE */ (106053,8,104,105,119,null,472,20437,null,106053,null); /* DE */ (106054,8,104,105,119,null,472,20437,null,106054,null); /* DE */ (106055,8,104,105,119,null,472,20437,null,106055,null); /* DE */ (106056,8,104,105,119,null,472,20437,null,106056,null); /* DE */ (106057,8,104,105,119,null,472,20437,null,106057,null); /* DE */ (106058,8,104,105,119,null,472,20437,null,106058,null); /* DE */ (106059,8,104,105,119,null,472,20437,null,106059,null); /* DE */ (106060,8,104,105,119,null,472,20437,null,106060,null); /* DE */ (106061,8,104,105,119,null,472,20437,null,106061,null); /* DE */ (106062,8,104,105,119,null,472,20437,null,106062,null); /* DE */ (106063,8,104,105,119,null,472,20437,null,106063,null); /* DE */ (106064,8,104,105,119,null,472,20437,null,106064,null); /* DE */ level 4 muss hier leer sein, weil es in Schleswig-Holstein keine Regierungsbezirke gibt. #104: Europa #105: Deutschland #119: Schleswig-Holstein -: Regierungsbezirk #472: Lübeck (Hansestadt, Kreisebene) #20437: Lübeck (Gemeindeebene) #106047: Klein Grönau #106048: Gothmund ... > Was das genau bedeutet, ist mir noch nicht klar und es ist jetzt doch > schon spät. Wir sollten da dranbleiben ;-) Ja, unbedingt... Übrigens würde ich vorschlagen, s.o., das begin/end-Datum aus den hierarchies zu entfernen. Da diese Daten abgeleitet sind und da sich das Datum eher aus den 400-Typen ergibt, brauchen wir es hier nicht mehr. Schönen Gruß Martin From wendorff at uni-paderborn.de Tue Apr 1 09:34:52 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Tue, 01 Apr 2008 09:34:52 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <47F1D3C3.5020103@gmx.de> References: <47EAC66D.50608@uni-paderborn.de> <20080331231730.69B3.STEPHAN.S@gmx.net> <47F1D3C3.5020103@gmx.de> Message-ID: <47F1E59C.2090201@uni-paderborn.de> Martin Trautmann schrieb: > Stephan S wrote: > >> Hallo Peter, >> >> Da ich keinen Fehler in deinen Überlegungen finden konnte, habe ich mal >> einen aktuellen Stand eingespielt um deine Vorgehensweise durchzuspielen. >> Dabei habe ich DE.sql, CH.sql und LI.sql, extra.sql importiert und auch >> die von Martin zur Verfügung gestellte geodb_hierarchies (für DE als >> geodb_hierarchies_orig) zum Vergleich. >> >> >>> [...] >>> UPDATE geodb_hierarchies SET id_lvl9 = loc_id WHERE `level`= 9; >>> >> Hier ergibt sich ein erster Unterschied: in der geodb_hierarchies_orig >> gibt es für diesen level keinen Eintrag, bei mir aber nach dem UPDATE 11 >> > > Das kann an einem Fehler meinerseits liegen, weil ich die PLZ mit type > 100800000 verpasst hatte und daher level 8 auf 100800000 und level 9 auf > 100900000 habe. > > >>> Hiermit wird jeweils die ID in dem level gesetzt, in der der Eintrag >>> selbst zu finden ist - denn die ist ja klar. >>> >>> ...und ab hier kriege ich Probleme... >>> Meine Idee für das weitere Vorgehen: >>> Nach und nach fülle ich jetzt Ebene e = 8, 7, 6, ..... über einzelne >>> Queries auf. >>> > > Eigentlich musst du in umgekehrter Richtung arbeiten - zumindest muss > ich das mit meinem eigenen Ansatz. > Bei deinem Ansatz gehst Du die Teil-Von-Beziehungen runter und musst dabei die Einträge hinterher zigfach kopieren. Mein Ansatz bringt aber in der ersten Abfrage jeden Datensatz in die Tabelle, und von da an wird aufgefüllt, was fehlt. Im Gegenteil würde dein Ansatz loc_ids, die keine Vorfahren bis Level 1 haben, aussen vor lassen. > > >> liefert dann 86 Datensätze ohne Eintrag für level 4, ich füge die hier >> einfach mal ein: >> >> loc_id;name;typ >> 466;Flensburg;Stadt >> 469;Kiel;Landeshauptstadt >> 472;Hansestadt Lübeck;Hansestadt >> Nehme ich die loc_id 472 (Lübeck) und prüfe die parent.loc_id (119) dann >> ist dieses direkt Schleswig-Holstein auf level 3 und die Verknüpfung >> über lvl.text_val = 4 passt nicht auf diese loc_id. >> > > > Hier mal alle hierarchies mit Lübeck > > INSERT INTO geodb_hierarchies VALUES > (20437,6,104,105,119,null,472,20437,null,null,null); /* DE */ > (106047,7,104,105,119,null,472,20437,106047,null,null); /* DE */ > (106048,8,104,105,119,null,472,20437,106047,106048,null); /* DE */ > (106049,8,104,105,119,null,472,20437,106047,106049,null); /* DE */ > (106046,8,104,105,119,null,472,20437,null,106046,null); /* DE */ > (106050,8,104,105,119,null,472,20437,null,106050,null); /* DE */ > (106051,8,104,105,119,null,472,20437,null,106051,null); /* DE */ > (106052,8,104,105,119,null,472,20437,null,106052,null); /* DE */ > (106053,8,104,105,119,null,472,20437,null,106053,null); /* DE */ > (106054,8,104,105,119,null,472,20437,null,106054,null); /* DE */ > (106055,8,104,105,119,null,472,20437,null,106055,null); /* DE */ > (106056,8,104,105,119,null,472,20437,null,106056,null); /* DE */ > (106057,8,104,105,119,null,472,20437,null,106057,null); /* DE */ > (106058,8,104,105,119,null,472,20437,null,106058,null); /* DE */ > (106059,8,104,105,119,null,472,20437,null,106059,null); /* DE */ > (106060,8,104,105,119,null,472,20437,null,106060,null); /* DE */ > (106061,8,104,105,119,null,472,20437,null,106061,null); /* DE */ > (106062,8,104,105,119,null,472,20437,null,106062,null); /* DE */ > (106063,8,104,105,119,null,472,20437,null,106063,null); /* DE */ > (106064,8,104,105,119,null,472,20437,null,106064,null); /* DE */ > > level 4 muss hier leer sein, weil es in Schleswig-Holstein keine > Regierungsbezirke gibt. > #104: Europa > #105: Deutschland > #119: Schleswig-Holstein > -: Regierungsbezirk > #472: Lübeck (Hansestadt, Kreisebene) > #20437: Lübeck (Gemeindeebene) > #106047: Klein Grönau > #106048: Gothmund > ... > > >> Was das genau bedeutet, ist mir noch nicht klar und es ist jetzt doch >> schon spät. Wir sollten da dranbleiben ;-) >> > > Die leer gebliebenen Ebenen (wie hier die Ebene 4) sind noch nicht dabei bis dahin, das ist mir klar, aber das kommt noch. Gruß Peter > Ja, unbedingt... > > Übrigens würde ich vorschlagen, s.o., das begin/end-Datum aus den > hierarchies zu entfernen. Da diese Daten abgeleitet sind und da sich das > Datum eher aus den 400-Typen ergibt, brauchen wir es hier nicht mehr. > gerne; aber für das Script sind die egal, insofern lasse ich die erstmal drin, bis die aus deinen offiziellen Dumps auch raus sind. > Schönen Gruß > Martin > From frankimglueck at gmx.de Thu Apr 3 09:49:13 2008 From: frankimglueck at gmx.de (=?iso-8859-1?Q?Frank_Gl=FCck?=) Date: Thu, 3 Apr 2008 09:49:13 +0200 Subject: [opengeodb] Nochmal zu Prosa-Namen wie "Brandis bei Wurzen"(war: Inkonsistenzen der Download-Daten) In-Reply-To: <47EF7ECB.3050004@gmx.de> Message-ID: <20080403080323.7822030FBA4@leipzig.mushaake.org> Hallo Martin, >Frank Glück wrote: >> >> ... gibts wohl gar keine Meinungen? Oder haltet Ihr den Vorschlag einer >> Aufsplittung des Namens in "nicht-amtlicher Vorsatz", "amtlicher Name" und >> "nicht-amtlicher Zusatz" wirklich für so indiskutabel? > >Ja, ist für mich völlig indiskutabel - wenn, dann würde ich eher nur >Kurzform und vollständige Langform haben, nicht aber ein Puzzle aus >Prefix und Suffix. Kann ich Dir hierzu wenigstens noch eine definitive Zusage abringen? Ich stelle leider immer wieder fest, dass mich die nicht-amtlichen Bezeichnungen bei meinem Projekt noch fast in den Wahnsinn treiben. Ich müsste also tatsächlich erst sehr aufwändig alle Prosa-Erweiterungen durch eigene Algorithmen "abknipsen", was ja nicht wirklich sein müsste, wenn sie Dir auch in der Urform vorliegen. Danke und Grüße, Frank From traut at gmx.de Thu Apr 3 13:26:38 2008 From: traut at gmx.de (Martin Trautmann) Date: Thu, 03 Apr 2008 13:26:38 +0200 Subject: [opengeodb] Nochmal zu Prosa-Namen wie "Brandis bei Wurzen"(war: Inkonsistenzen der Download-Daten) In-Reply-To: <20080403080323.7822030FBA4@leipzig.mushaake.org> References: <20080403080323.7822030FBA4@leipzig.mushaake.org> Message-ID: <47F4BEEE.30900@gmx.de> Frank Glück wrote: > Kann ich Dir hierzu wenigstens noch eine definitive Zusage abringen? Ich > stelle leider immer wieder fest, dass mich die nicht-amtlichen Bezeichnungen > bei meinem Projekt noch fast in den Wahnsinn treiben. Ich müsste also > tatsächlich erst sehr aufwändig alle Prosa-Erweiterungen durch eigene > Algorithmen "abknipsen", was ja nicht wirklich sein müsste, wenn sie Dir > auch in der Urform vorliegen. Ich kann sie dir gerne schicken, möchte sie aber derzeit nicht in der Release drin haben - das kommt frühestens dann, sobald ich SQL-Code zum Einbauen habe, der aus Kurzformen die ASCII-Varianten errechnen kann. Sonst steckt mir zu viel Redundanz drin. In den .tab-Dateien steckt die Kurzform derzeit nicht drin - ich muss sie aus anderer Quelle ableiten. Schönen Gruß Martin From frankimglueck at gmx.de Thu Apr 3 13:52:25 2008 From: frankimglueck at gmx.de (=?iso-8859-1?Q?Frank_Gl=FCck?=) Date: Thu, 3 Apr 2008 13:52:25 +0200 Subject: [opengeodb] Nochmal zu Prosa-Namen wie "Brandis bei Wurzen"(war: Inkonsistenzen der Download-Daten) In-Reply-To: <47F4BEEE.30900@gmx.de> Message-ID: <20080403120637.DF24B166D4@leipzig.mushaake.org> Martin schrieb: >Frank Glück wrote: > >> Kann ich Dir hierzu wenigstens noch eine definitive Zusage >abringen? Ich >> stelle leider immer wieder fest, dass mich die >nicht-amtlichen Bezeichnungen >> bei meinem Projekt noch fast in den Wahnsinn treiben. Ich müsste also >> tatsächlich erst sehr aufwändig alle Prosa-Erweiterungen durch eigene >> Algorithmen "abknipsen", was ja nicht wirklich sein müsste, >wenn sie Dir >> auch in der Urform vorliegen. > >Ich kann sie dir gerne schicken, Danke, das wäre sehr nett! >möchte sie aber derzeit nicht in der >Release drin haben - das kommt frühestens dann, sobald ich >SQL-Code zum Einbauen habe, der aus Kurzformen die ASCII-Varianten >errechnen kann. >Sonst steckt mir zu viel Redundanz drin. Klar, ist verständlich, wobei ich allerdings meine, dann sollten sie auch definitiv mit dabei sein! Sonst müsste ich Dich ja mit jeder Release auch immer gleich um meine Extra-Wurst bitten. ;-) >In den .tab-Dateien steckt die Kurzform derzeit nicht drin - ich muss >sie aus anderer Quelle ableiten. Eben drum, leider ... Vielen Dank und Grüße, Frank From ralph at mail.pangea.at Thu Apr 3 14:53:20 2008 From: ralph at mail.pangea.at (Ralph Aichinger) Date: Thu, 03 Apr 2008 14:53:20 +0200 Subject: [opengeodb] =?iso-8859-1?q?Anf=E4ngerfragen_/Stadtteile_von_Linz?= =?iso-8859-1?q?=2C_=D6sterreich?= Message-ID: <1207227200.31614.16.camel@glitz> Ich hoffe, das ist die richtige Liste. Ich fange grade mit Openstreetmap an, und die Qualität von OSM in "meiner" Stadt Linz ist schon recht gut. Wo extrem viele Fehler drin sind, sind die Stadtteil- bezeichnungen, die aus Opengeodb übernommen worden sind. Die direkt eingetragenen Sachen passen viel besser. Sehr viele (vielleicht die Hälfte) der Stadtteile sind völlig falsch zugeordnet, zu ähnlich klingenden Orten ganz wo anders. So war z.B. der Stadtteil "Oed" als "Oed in den Bergen" (eine Ortschaft 30 km weiter weg in einem anderen Bezirk) eingetragen. Ich habe dieses "Oed in den Bergen" in Opengeodb ungefähr richtiggestellt. Was muß ich machen, damit das in OSM richtig zurückgeschrieben wird? Oder kann ich dieses "Oed in den Bergen" dann in OSM gleich löschen, weil es eh wieder aus der DB kommt? loc_id 68424 Andere Stadtteile die falsch sind: Wegscheid loc_id 73668 (ich hab das nach Vöcklabruck zurückübersiedelt in der DB, weiß aber nicht woher die "richtigen" Koordinaten kriegen) Neue Heimat loc_id 67486 (ebenfalls aus einem anderen Bezirk, gleichlautende Bezeichnung) Freindorf 67486 detto Dornach 70723 detto Margarethen 69840 detto Was mach ich in solchen Fällen richtigerweise? Gibt es da einen systematischen Fehler, daß ca. die Hälfte dieser Bezeichnungen falsch zugeordnet sind? Gibt es keine Möglickeit einer Plausibilitätsüberprüfung, wenn ein Ortsteil 30 Kilometer neben der "Muttergemeinde" liegt, dann ist das doch ungewöhnlich, oder nicht? TIA /ralph From neis at geoinform.fh-mainz.de Thu Apr 3 15:59:42 2008 From: neis at geoinform.fh-mainz.de (Pascal Neis) Date: Thu, 3 Apr 2008 15:59:42 +0200 (CEST) Subject: [opengeodb] Dump & Download der aktuellen DB? Message-ID: <13372929.881207231182913.OPEN-XCHANGE.WebMail.tomcat@mailhost.geoinform.fh-mainz.de> Hi List, ale erstes mal vielen Dank an alle die an diesem Projekt mitarbeiten! Ich würde gerne opengeodb verwenden, leider habe ich gesehen das der Dump auf sourcforge zum einen schon etwas länger her ist und zum anderen leider nicht in postgres bereit steht. Hier meine Frage: Könnte ein aktueller Dump bereitgestellt werden? Vielleicht auch in postgres? cheers   pascal From traut at gmx.de Thu Apr 3 19:13:22 2008 From: traut at gmx.de (Martin Trautmann) Date: Thu, 03 Apr 2008 19:13:22 +0200 Subject: [opengeodb] =?iso-8859-1?q?Anf=E4ngerfragen_/Stadtteile_von_Linz?= =?iso-8859-1?q?=2C_=D6sterreich?= In-Reply-To: <1207227200.31614.16.camel@glitz> References: <1207227200.31614.16.camel@glitz> Message-ID: <47F51032.2010702@gmx.de> Ralph Aichinger wrote: > Wo extrem viele Fehler drin sind, sind die Stadtteil- > bezeichnungen, die aus Opengeodb übernommen worden sind. > Die direkt eingetragenen Sachen passen viel besser. > > Sehr viele (vielleicht die Hälfte) der Stadtteile sind > völlig falsch zugeordnet, zu ähnlich klingenden Orten > ganz wo anders. Hallo Ralph, ja, hier erfolgte der Abgleich von NIMA-Daten zum über den Namen bestmöglich passenden Ort. http://wiki.openstreetmap.org/index.php/Potential_Datasources#GEOnet_Names_Server Wenn, dann hätte ich aber eher Fehler in umgekehrter Richtung erwartet: Zur Verfügung standen Ortslisten mit Gemeindezugehörigkeit - übermäßig viele Ortsteile hätte ich darin nicht erwartet. Daher wäre wahrscheinlicher, dass sich in den NIMA-Daten Geokoordinaten von Ortsteilen fänden, die dann Orten ausserhalb zugeordnet worden wären. In Deutschland sind wir schon sehr weit durchgekommen. In Österreich stehen wir da viel mehr am Anfang. > So war z.B. der Stadtteil "Oed" als "Oed in den Bergen" > (eine Ortschaft 30 km weiter weg in einem anderen Bezirk) > eingetragen. Ich habe dieses "Oed in den Bergen" in Opengeodb > ungefähr richtiggestellt. Was muß ich machen, damit das > in OSM richtig zurückgeschrieben wird? Der OSM-Import wurde von einem OSM-Mitglied gemacht. Ich weiss nicht, für wann die nächste Aktualisierun geplant ist. > Oder kann ich > dieses "Oed in den Bergen" dann in OSM gleich löschen, weil > es eh wieder aus der DB kommt? Siehe http://wiki.openstreetmap.org/index.php/OpenGeoDB > loc_id 68424 Ich bin jetzt auch überrascht, da die opengeodb überhaupt keine Stadtteile von Linz enthält: http://fa-technik.adfc.de/code/opengeodb.pl?parts=67383;c=AT > Andere Stadtteile die falsch sind: > > Wegscheid loc_id 73668 > (ich hab das nach Vöcklabruck zurückübersiedelt > in der DB, weiß aber nicht woher die "richtigen" > Koordinaten kriegen) Taucht in http://fa-technik.adfc.de/code/opengeodb.pl?locid=67383;c=AT;distance=5 nicht auf - Wegscheid gehört in der opengeodb auch schon zu Vöcklabrück. > > Neue Heimat loc_id 67486 > (ebenfalls aus einem anderen Bezirk, gleichlautende Bezeichnung) > > Freindorf 67486 detto > Dornach 70723 detto > Margarethen 69840 detto > > Was mach ich in solchen Fällen richtigerweise? Im Idealfall stimmt die Gemeindezugehörigkeit und die Koordinaten sind falsch. Dann sollte man die Koordinaten korrigieren - die sind grundsätzlich erst einmal nur auf Zehntelminuten genau. Wenn es an den entspechenden Koordinaten einen passenden Ort gibt, der bisher nicht erfasst ist, so sollte man die übergeordnete Hierarchie finden (z.B. die Gemeinde) und den Ort als Teil davon neu anlegen und ihm möglichst noch bessere Koordinaten zuweisen. > Gibt es da einen systematischen Fehler, daß ca. die > Hälfte dieser Bezeichnungen falsch zugeordnet sind? Für mich sieht das erstmal so aus, als wäre die Zuordnung nicht innerhalb der opengeodb falsch, sondern der Abgleich von opengeodb in Richtung OSM wäre verkehrt abgelaufen. > Gibt es keine Möglickeit einer Plausibilitätsüberprüfung, > wenn ein Ortsteil 30 Kilometer neben der "Muttergemeinde" > liegt, dann ist das doch ungewöhnlich, oder nicht? Da gibt es verschiedene Prüfmöglichkeiten - speziell z.B. wie sehr ein Gemeindeteil von den Koordinaten der Ebene darüber abweicht. Die Info selbst hilft aber nicht viel - jemand müsste diese Info auch nachprüfen. Du kannst ja exemplarisch obige Umkreissuche von Linz verwenden und prüfen, was davon falsch ist. Schönen Gruß Martin From stephan.s at gmx.net Thu Apr 3 22:47:19 2008 From: stephan.s at gmx.net (Stephan Schuster) Date: Thu, 03 Apr 2008 22:47:19 +0200 Subject: [opengeodb] Dump & Download der aktuellen DB? In-Reply-To: <13372929.881207231182913.OPEN-XCHANGE.WebMail.tomcat@mailhost.geoinform.fh-mainz.de> References: <13372929.881207231182913.OPEN-XCHANGE.WebMail.tomcat@mailhost.geoinform.fh-mainz.de> Message-ID: <20080403215918.71D4.STEPHAN.S@gmx.net> Hallo Pascal, > Ich würde gerne opengeodb verwenden, leider habe ich gesehen > das der Dump auf sourcforge zum einen schon etwas länger her ist und > zum anderen leider nicht in postgres bereit steht. > > Hier meine Frage: Könnte ein aktueller Dump bereitgestellt werden? > Vielleicht auch in postgres? Dumps auf SF werden zur Zeit nur sporadisch released aber du findest die aktuellen Daten unter http://fa-technik.adfc.de/code/opengeodb/ Im Unterverzeichnis dump liegen auch komplette Dumps, die aktuelle Doku ist unter http://opengeodb.giswiki.org/wiki/OpenGeoDB_Dokumentation verfügbar. Für Postgres muss Du wahrscheinlich die opengeodb-begin.sql anpassen (falls Du nicht einen kompletten Dump modfizieren willst), der Aufwand sollte sich in Grenzen halten. Ich denke es sollte reichen die Angaben zur Engine und Zeichensatz (TYPE=InnoDB CHARACTER SET utf8) zu entfernen. Vielleicht kannst du ja Deine Erfahrungen und die notwendigen Konvertierungen in einem eigenen Absatz oder Seite in der Doku eintragen. Das Wiki kann man nach Anmeldung bearbeiten. Schönen Gruß Stephan From wendorff at uni-paderborn.de Mon Apr 7 22:15:02 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Mon, 07 Apr 2008 22:15:02 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <47EAC66D.50608@uni-paderborn.de> References: <47EAC66D.50608@uni-paderborn.de> Message-ID: <47FA80C6.6070504@uni-paderborn.de> Hallo Liste. Nochmal zum Thema zurück (nachdem ich letzte Woche meinen Rechner neu aufsetzen musste): Datenstand: aktuell (ca 20 Uhr heute Abend), eingespielt sind die Dateien Ich habe nach dem Einspielen des folgenden (ersten) Befehls meines Scripts einen Unterschied zwischen den Dump-Hierarchies und meinen erzeugten: INSERT INTO geodb_hierarchies (loc_id, `level` , id_lvl1, valid_until, date_type_until) SELECT loc_id, text_val, 104, "3000-01-01", 300500000 FROM geodb_textdata WHERE text_type = 400200000; Die hierarchies aus dem Dump enthalten bei mir 60.640 Einträge, die erzeugte Tabelle enthält dagegen 55.080 Einträge - rund 5.000 Einträge weniger. Die Überprüfung, welche Datensätze jeweils fehlen, ergibt: In der heruntergeladenen Tabelle fehlen die 5 Datensätze mit den IDs 85722, 144599, 144600, 144602 und 144603, in der erzeugten Tabelle fehlen die 19 Datensätze mit den IDs 80061, 80062, 80063, 80067, 80074, 80091, 80092, 80393, 80583, 80585, 80587, 80589, 80590, 80591, 80592, 80594, 80623 und 128355. Betrachten wir die Datensätze im Einzelnen, beginnend mit denen, die in der heruntergeladenen Tabelle fehlen, als Referenz nehme ich diesmal der Einfachheit halber die Oberfläche unter fa-technik.adfc.de: 85722 - Altes Lager, ist Teil von -1 - also einer nicht-existenten loc_id 144599 - Mildensee, Teil von ist leer 144600 - Mosgikau, Teil von ist ebenfalls leer, für die anderen drei Einträge gilt dies analog. Zu diesen Daten sind schlichtweg also keine Informationen zu höheren Hierarchie-Ebenen vorhanden, weshalb sie beim Top-Down-Ansatz von Martins SQL-Erzeugung nicht vorkommen können. Dennoch gehören diese Datensätze in gewisser Weise in die hierarchies-Tabelle, inwiefern sie in bestimmten Anwendungen verzichtbar sind, darüber lässt sich streiten. Auf jeden Fall lässt sich dies als Hinweis auf Fehler in der Datenbank festhalten. Weiter geht es mit den Datensätzen, die mein Script nicht erzeugt, obwohl sie im Dump vorhanden sind. Bei diesen fällt auf, dass sie alle als gelöscht markiert sind. Dies deutet darauf hin, dass diese Daten eben schon im Stamm-Dump nicht vorhanden sind, im hierarchies-Dump allerdings doch noch. Wenn mir das soweit jemand verifizieren könnte, wär das ganz gut. Dies bedeutet insbesondere übrigens, dass der hierarchies-Dump entweder nicht gleich aktuell ist wie der Daten-Dump oder aber, dass der hierarchie-Dump nicht korrekt erzeugt wird. Das weitere Vorgehen folgt dann später - ich möchte vor allem erstmal sicher gehen, dass dies soweit programm-technisch korrekt ist, und eben auf den vermuteten Dump-Inkonsistenzen beruht. Gruß Peter Wendorff From traut at gmx.de Mon Apr 7 22:30:43 2008 From: traut at gmx.de (Martin Trautmann) Date: Mon, 07 Apr 2008 22:30:43 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <47FA80C6.6070504@uni-paderborn.de> References: <47EAC66D.50608@uni-paderborn.de> <47FA80C6.6070504@uni-paderborn.de> Message-ID: <47FA8473.7010007@gmx.de> Peter Wendorff wrote: > Weiter geht es mit den Datensätzen, die mein Script nicht erzeugt, > obwohl sie im Dump vorhanden sind. Bei diesen fällt auf, dass sie alle > als gelöscht markiert sind. Ah, danke - kann sein, dass ich bei der Erzeugung der Hierarchies nicht auf Löschmarkierungen achtete. > Dies bedeutet insbesondere übrigens, dass der hierarchies-Dump entweder > nicht gleich aktuell ist wie der Daten-Dump oder aber, dass der > hierarchie-Dump nicht korrekt erzeugt wird. Ich habe kurz nachgesehen - ja, ich betrachte nur id, level und of > Das weitere Vorgehen folgt dann später - ich möchte vor allem erstmal > sicher gehen, dass dies soweit programm-technisch korrekt ist, und eben > auf den vermuteten Dump-Inkonsistenzen beruht. Das sieht sehr gut aus - ich könnte nun den Fehler natürlich korrigieren, halte das bei deinem Stand aber schon fast für überflüssig. Schönen Gruß Martin From wendorff at uni-paderborn.de Mon Apr 7 22:36:25 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Mon, 07 Apr 2008 22:36:25 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <47FA8473.7010007@gmx.de> References: <47EAC66D.50608@uni-paderborn.de> <47FA80C6.6070504@uni-paderborn.de> <47FA8473.7010007@gmx.de> Message-ID: <47FA85C9.90006@uni-paderborn.de> Martin Trautmann schrieb: > Das sieht sehr gut aus - ich könnte nun den Fehler natürlich > korrigieren, halte das bei deinem Stand aber schon fast für überflüssig. Auf Dauer bitte trotzdem korrigieren ;) Ich teste weiter... Gruß Peter From wendorff at uni-paderborn.de Mon Apr 7 22:49:12 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Mon, 07 Apr 2008 22:49:12 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <47FA8473.7010007@gmx.de> References: <47EAC66D.50608@uni-paderborn.de> <47FA80C6.6070504@uni-paderborn.de> <47FA8473.7010007@gmx.de> Message-ID: <47FA88C8.9050701@uni-paderborn.de> Martin Trautmann schrieb: > Peter Wendorff wrote: > > >> Weiter geht es mit den Datensätzen, die mein Script nicht erzeugt, >> obwohl sie im Dump vorhanden sind. Bei diesen fällt auf, dass sie alle >> als gelöscht markiert sind. >> Die Gelöscht-Markierungen kann ich an den SQL-Daten aber nirgendwo erkennen, oder? Sonst würde ich die in meiner lokalen Version vorher löschen, damit ich da einfacher testen kann. Gruß Peter From traut at gmx.de Mon Apr 7 22:58:06 2008 From: traut at gmx.de (Martin Trautmann) Date: Mon, 07 Apr 2008 22:58:06 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <47FA88C8.9050701@uni-paderborn.de> References: <47EAC66D.50608@uni-paderborn.de> <47FA80C6.6070504@uni-paderborn.de> <47FA8473.7010007@gmx.de> <47FA88C8.9050701@uni-paderborn.de> Message-ID: <47FA8ADE.7010207@gmx.de> Peter Wendorff wrote: > Die Gelöscht-Markierungen kann ich an den SQL-Daten aber nirgendwo > erkennen, oder? nein - im normalen dump sind sie schlichtweg nicht vorhanden, in extra-Daten evtl. schon und der hierarchies-hack hat die Markierung schlichtweg ignoriert. > Sonst würde ich die in meiner lokalen Version vorher löschen, damit ich > da einfacher testen kann. Kannst du nicht einfach die .tab-Dateien mit (e)grep oder einer Tabellenkalkulation durchgehen und damit die IDs der markierten Einträge raussuchen? Schönen Gruß Martin From wendorff at uni-paderborn.de Tue Apr 8 00:05:04 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Tue, 08 Apr 2008 00:05:04 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <47EAC66D.50608@uni-paderborn.de> References: <47EAC66D.50608@uni-paderborn.de> Message-ID: <47FA9A90.4040008@uni-paderborn.de> Weiter im Text, nachdem der erste Teil offensichtlich gelöst ist. Stand der Dinge also: - zu jeder loc_id existiert ein Datensatz in meiner erzeugten hierarchies-Tabelle. - lvl1 ist jeweils auf -1 gesetzt (später hier NULL, aber im Moment bleibe ich noch bei der alten Tabellendefinition) - das Feld level ist gesetzt entsprechend dem entsprechenden Wert aus text_data - das zu level passende Feld id_lvl? (wobei ? eben durch den Wert von level im Bereich von [1..9] zu ersetzen ist) ist entsprechend korrekt gesetzt. Mein nächster Schritt ist, die Parents zu finden, die auf level 8 liegen und entsprechend einen Nachfahren haben, der in der locations auf level 9 sitzt. Also: /*1*/ UPDATE geodb_hierarchies, /*2*/ geodb_textdata AS part1, /*3*/ geodb_textdata AS part2 /*4*/ SET id_lvl8 = part1.text_val /*5*/ WHERE part1.text_type = 400100000 /*6*/ AND part2.text_type = 400200000 /*7*/ AND part2.text_val = 8 /*8*/ AND part2.loc_id = part1.text_val /*9*/ AND part1.text_val = geodb_hierarchies.id_lvl9 /*10*/ AND geodb_hierarchies.level = 9; (Die Zeilennummern stehen absichtlich in einem Kommentar, damit man das ganze so in ein SQL-Tool übernehmen kann) Zeilen 1 bis 3: Das Update schreibt zwar nur in geodb_hierarchies, benötigt dafür aber auch Daten aus textdata - und das in zwei verschiedenen Rollen, deshalb part1 und part2. Zeile 4: Geschrieben wird das Feld für Level 8, wohin, folgt gleich. Zeilen 5 bis 10: Die Bedingungen, was genau ich denn gerne hätte - im Einzelnen: Zeile 5: part1.text_type: Die part1-Instanz von geodb_textdata wird gefiltert auf alle "Teil-Von"-Beziehungen. Also stehen nun in part1.loc_id alle "teile" von den part1.text_val -Werten. Zeile 6: bei part2 werden nur Ebenen betrachtet, weil... Zeile 7: ...insgesamt nur Ganze (vgl. part1) auf Ebene 8 gesucht werden. (zurück zu Zeile 4: Genau das wird da dann auch geschrieben) Zeile 8: part2.loc_id = part1.text_val - die Ebene 8 muss zu eben diesem Ganzen gehören. Zeile 9: part2.loc_id = geodb_hierarchies.id_lvl9 - natürlich muss das TEIL von dem Ganzen dann auch in der hierarchies-Tabelle entsprechend in Ebene 9 stehen, denn nur dann passt das Ganze ja dazu Zeile 10: ...und damit wir das nicht zu oft umsonst machen, betrachten wir nur Einträge, bei denen das level 9 ist, denn alle anderen haben ja gar keinen Eintrag in id_lvl9 (man könnte auch nach geodb_hierarchies.id_lvl9 NOT NULL filtern, das ist aber für die Weiterverwendung später nicht sinnvoll). Wo ist jetzt mein Fehler, dass dabei kein Datensatz aktualisiert wird? Umgebaut zur SELECT-Abfrage dauert das ganze unheimlich lange, gibt aber auch noch eine leere Ergebnismenge zurück. Gruß und gute Nacht für heute. Peter Wendorff From wendorff at uni-paderborn.de Tue Apr 8 09:15:25 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Tue, 08 Apr 2008 09:15:25 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <47FA9A90.4040008@uni-paderborn.de> References: <47EAC66D.50608@uni-paderborn.de> <47FA9A90.4040008@uni-paderborn.de> Message-ID: <47FB1B8D.1060005@uni-paderborn.de> Peter Wendorff schrieb: > Weiter im Text, nachdem der erste Teil offensichtlich gelöst ist. > > Stand der Dinge also: > - zu jeder loc_id existiert ein Datensatz in meiner erzeugten > hierarchies-Tabelle. > - lvl1 ist jeweils auf -1 gesetzt (später hier NULL, aber im Moment > bleibe ich noch bei der alten Tabellendefinition) > - das Feld level ist gesetzt entsprechend dem entsprechenden Wert aus > text_data > - das zu level passende Feld id_lvl? (wobei ? eben durch den Wert von > level im Bereich von [1..9] zu ersetzen ist) ist entsprechend korrekt > gesetzt. > > Mein nächster Schritt ist, die Parents zu finden, die auf level 8 liegen > und entsprechend einen Nachfahren haben, der in der locations auf level > 9 sitzt. > Also: > [...] > Hab das nochmal neu gebastelt, und komme auf die folgende Funktion, die mir immerhin einen Datensatz (loc_id 80627) korrekt setzt (und keinen falsch - auch ein Vorteil): UPDATE geodb_hierarchies, geodb_textdata AS partOf, geodb_textdata AS isLevel SET id_lvl8 = isLevel.loc_id WHERE 1 AND partOf.loc_id = geodb_hierarchies.loc_id AND geodb_hierarchies.level = 9 AND partOf.text_type = "400100000" AND isLevel.loc_id = partOf.text_val AND isLevel.text_type = "400200000" AND isLevel.text_val = "8"; Dabei sind alle anderen Datensätze, die in meiner geodb vorhanden sind, auf fa-technik.adfc.de als gelöscht markiert, in meiner Datenbank aber eben noch vorhanden (s. Mail von gestern: mein Dump ist von gestern Abend, 20:00 Uhr) -> Martin???. Ein Problem war offensichtlich das der Typen, also: die Ganzzahlen gehören in geodb_intdata - das sollte bald geändert werden (Ebene, Teil von, Einwohnerzahl, ungef. EWZ, Genaue EWZ, Höhenangabe (?), max. Höhe, min Höhe, durchschn. Höhe, Höhe an Ref.Pkt, Höhe an angeg. Koord.) Meine Vorlesung geht jetzt los, ich bin also erstmal beschäftigt. Gruß Peter From stephan.s at gmx.net Tue Apr 8 21:06:41 2008 From: stephan.s at gmx.net (Stephan Schuster) Date: Tue, 08 Apr 2008 21:06:41 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <47FB1B8D.1060005@uni-paderborn.de> References: <47FA9A90.4040008@uni-paderborn.de> <47FB1B8D.1060005@uni-paderborn.de> Message-ID: <20080408205043.D813.STEPHAN.S@gmx.net> Hallo Peter, > > [...] > > > Hab das nochmal neu gebastelt, und komme auf die folgende Funktion, die > mir immerhin einen Datensatz (loc_id 80627) korrekt setzt (und keinen > falsch - auch ein Vorteil): > > UPDATE geodb_hierarchies, > geodb_textdata AS partOf, > geodb_textdata AS isLevel > SET id_lvl8 = isLevel.loc_id > WHERE 1 > AND partOf.loc_id = geodb_hierarchies.loc_id > AND geodb_hierarchies.level = 9 > AND partOf.text_type = "400100000" > AND isLevel.loc_id = partOf.text_val > AND isLevel.text_type = "400200000" > AND isLevel.text_val = "8"; Ich habe zwölf Datensatze mit einem Level von 9. Wenn ich die übergeordneten loc_id's abfrage: SELECT id_lvl9, text_val FROM geodb_hierarchies h LEFT JOIN geodb_textdata AS part_of ON h.loc_id = part_of.loc_id WHERE `id_lvl9` > 0 AND part_of.text_type = 400100000 erhalte ich 11 Datensätze mit übergeordneter id 80592 und einen mit 81036. Letzterer ist der Ortsteil Maichingen, die anderen haben als übergeordneten Datensatz die loc_id 80592. Diese ist in meinem Dump (ca. 2 Wochen alt) nicht vorhanden, was bei Deiner Abfrage logischerweise dann dazu führt, dass diese nur einen Datensatz (loc_id aktualisiert 80627) aktualisiert. Unter http://fa-technik.adfc.de/code/opengeodb.pl?locid=80592;c=DE erhalte ich als Ergebnis Mönchsdeggingen. Da level 9 wohl noch sehr experimentell (Straßen?) ist, wäre es vielleicht sinnvoller bei level 8 zu beginnen (?). Schönen Gruß Stephan From wendorff at uni-paderborn.de Tue Apr 8 22:36:24 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Tue, 08 Apr 2008 22:36:24 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <20080408205043.D813.STEPHAN.S@gmx.net> References: <47FA9A90.4040008@uni-paderborn.de> <47FB1B8D.1060005@uni-paderborn.de> <20080408205043.D813.STEPHAN.S@gmx.net> Message-ID: <47FBD748.3030809@uni-paderborn.de> Hallo Stephan Stephan Schuster schrieb: > Unter http://fa-technik.adfc.de/code/opengeodb.pl?locid=80592;c=DE > erhalte ich als Ergebnis Mönchsdeggingen. Wenn Du genau hinguckst, findest Du auch die eigentliche Ursache (die ich schon in der Mail von heute morgen geschrieben habe). Es liegt wohl daran, dass die Daten auf fa-technik.adfc.de aus den text-Dateien stammen: Die betroffenen Datensätze (u.A. dein Beispiel loc_id 80592) sind als gelöscht markiert - und werden als solche in den Basisdaten-Dump nicht aufgenommen. Das Script zur Erzeugung der Hierarchies, das bisher den Dump erzeugt, betrachtet aber diesen Marker nicht, weshalb im Dump der geodb_hierarchies die Datensätze eben doch noch drin sind. Mein Problem soweit ist also an dieser Stelle gelöst - die weiteren Schritte werden jetzt der nächste Schritt sein, bis die Tabelle vollständig gefüllt ist. > Da level 9 wohl noch sehr > experimentell (Straßen?) ist, wäre es vielleicht sinnvoller bei level 8 > zu beginnen (?). > > Schönen Gruß > Stephan > Ganz klar eben nein - und dafür kann ich Dir gleich zwei Gründe nennen: 1) Konzeptionell sollen die Lvl9-Datensätze irgendwann kommen, und ich möchte ja eben gerade ein Script, was später NICHT für neue DATEN angepasst werden muss. 2) Mein angenommener Fehler war eben gar keiner - das SQL-Statement funktioniert und erzeugt im Übrigen genauso korrekte Daten wie die, die im Moment als Dump zur Verfügung stehen, nur sind die Daten aus dem Dump eben durch eine fehlende Prüfung nicht konsistent mit den Basisdaten Gruß Peter From traut at gmx.de Wed Apr 9 07:03:37 2008 From: traut at gmx.de (Martin Trautmann) Date: Wed, 09 Apr 2008 07:03:37 +0200 Subject: [opengeodb] =?iso-8859-1?q?SQL-Script_f=FCr_hierarchies?= In-Reply-To: <47FBD748.3030809@uni-paderborn.de> References: <47FA9A90.4040008@uni-paderborn.de> <47FB1B8D.1060005@uni-paderborn.de> <20080408205043.D813.STEPHAN.S@gmx.net> <47FBD748.3030809@uni-paderborn.de> Message-ID: <47FC4E29.3040001@gmx.de> Peter Wendorff wrote: >> Da level 9 wohl noch sehr >> experimentell (Straßen?) ist, wäre es vielleicht sinnvoller bei level 8 >> zu beginnen (?). > Ganz klar eben nein - und dafür kann ich Dir gleich zwei Gründe nennen: > 1) Konzeptionell sollen die Lvl9-Datensätze irgendwann kommen, und ich > möchte ja eben gerade ein Script, was später NICHT für neue DATEN > angepasst werden muss. Dennoch würde ich auch empfehlen, sie aus den hierarchies ganz rauszunehmen: Wenn unsere Quelle dafür die OpenStreetMap sein wird, müssten wir die opengeodb-Daten unter eine einschränkende Lizenz stellen. Schönen Gruß Martin From geodb at daxis.de Wed Apr 9 22:01:36 2008 From: geodb at daxis.de (Daxi) Date: Wed, 09 Apr 2008 22:01:36 +0200 Subject: [opengeodb] =?iso-8859-1?q?ADFC-Admin=3A_Ort_doppelt=2C_einmal_fe?= =?iso-8859-1?q?hlerhaft=2C_wie_l=F6schen=3F?= Message-ID: <1207771296.6384.9.camel@daxi-laptop> Hallo zusammen, ich habe mir vom ADFC die aktuellen Dumps für Deutschland heruntergeladen. Bei den ersten Test-Queries habe ich die "Gemeinde Hettenshausen" als Teil von "Schweitenkirchen" mit der ID 125480 gefunden. (siehe http://fa-technik.adfc.de/code/opengeodb.pl?locid=125480;c=DE) Ich kann ich aber nicht daran entsinnen, dass unsere Gemeinde zu Schweitenkirchen gehört. Der Eintrag 18293 ist jedenfalls der richtige. (siehe http://fa-technik.adfc.de/code/opengeodb.pl?locid=18293;c=DE) Der Löschlink wurde meines Wissens ja entfernt, damit durch das Indizieren durch Google und Co keine Datensätze gelöscht werden können. Doch wie kann ich nun diesen Datensatz aus der openGeoDB entfernen? Vielen Dank bereits. Christian Daxberger From traut at gmx.de Thu Apr 10 08:53:11 2008 From: traut at gmx.de (Martin Trautmann) Date: Thu, 10 Apr 2008 08:53:11 +0200 Subject: [opengeodb] =?iso-8859-1?q?ADFC-Admin=3A_Ort_doppelt=2C_einmal_fe?= =?iso-8859-1?q?hlerhaft=2C_wie_l=F6schen=3F?= In-Reply-To: <1207771296.6384.9.camel@daxi-laptop> References: <1207771296.6384.9.camel@daxi-laptop> Message-ID: <47FDB957.7060701@gmx.de> Daxi wrote: > Hallo zusammen, > > ich habe mir vom ADFC die aktuellen Dumps für Deutschland > heruntergeladen. > Bei den ersten Test-Queries habe ich die "Gemeinde Hettenshausen" als > Teil von "Schweitenkirchen" mit der ID 125480 gefunden. > (siehe http://fa-technik.adfc.de/code/opengeodb.pl?locid=125480;c=DE) > > Ich kann ich aber nicht daran entsinnen, dass unsere Gemeinde zu > Schweitenkirchen gehört. > Der Eintrag 18293 ist jedenfalls der richtige. > (siehe http://fa-technik.adfc.de/code/opengeodb.pl?locid=18293;c=DE) Die Frage ist sehr berechtigt - wie kann es sein, dass Hettenshausen als Ortsteil von Schweitenkirchen hineinrutschte? Schweitenkirchen hat eine gemeindepolitisch recht lebhafte Geschichte: http://home.bn-paf.de/schweitenkirchen/Chronik/chronik.htm Ich würde vermuten, dass bei der Gemeindereform zwischen 1971 und 1978 ein Gemeindeteil von Hettenshausen nach Schweitenkirchen kam. Konkret handelt es sich vermutlich um die Straße oder den Hof "Harres" - fällt dir dazu etwas ein? Mit entsprechenden Fragezeichen sollte all das geprüft werden: 106216 01053090002 Gemeinde Grambek 53.5666667 10.6833333 01057087004 Gemeinde Wisch 020000000001 Gemeinde Jork 03152012004 Gemeinde Friedland 03153005003 Gemeinde Bad Harzburg 107868 03154010009 Gemeinde Wolsdorf 52.2 10.95 03251021001 Gemeinde Bahrenborstel 03251040020 Gemeinde Maasen 03254002006 Gemeinde Freden 03254021004 Gemeinde Diekholzen 03254022011 Gemeinde Söhlde 03256022007 Gemeinde Stöckse 109294 03256032515 Gemeinde Leese 52.5 9.1166667 03257031002 Gemeinde Buchholz 109441 03352003004 Gemeinde Flögeln 53.6666667 8.8166667 03353005006 Gemeinde Jesteburg 03354004007 Gemeinde Gusborn 110367 03357051004 Gemeinde Bothel 53.0666667 9.5 03403000002 Gemeinde Bad Zwischenahn 03452017002 Gemeinde Südbrookmerland 03452023004 Gemeinde Großheide 111669 03454042001 Gemeinde Lorup 52.9 7.6166667 03455020026 Gemeinde Wittmund 03457016002 Gemeinde Brinkum 03458008002 Gemeinde Bassum 03459005001 Gemeinde Bad Iburg 112603 03461007004 Gemeinde Butjadingen 53.5472222 8.335 03462019032 Gemeinde Wangerland 05166024013 Gemeinde Niederkrüchten 05354012019 Gemeinde Langerwehe 113725 05358028006 Gemeinde Hürtgenwald 50.7166667 6.3666667 05358028010 Gemeinde Nideggen 05374052019 Gemeinde Kürten 05374052022 Gemeinde Lindlar 05378004024 Gemeinde Odenthal 05570008002 Gemeinde Ennigerloh 05766044005 Gemeinde Kalletal 05770008008 Gemeinde Preußisch Oldendorf 05770028021 Gemeinde Meerbeck 05770036001 Gemeinde Bad Essen 05770036012 Gemeinde Rödinghausen 05962020005 Gemeinde Plettenberg 05962032017 Gemeinde Schalksmühle 05962052004 Gemeinde Herscheid 06434009010 Gemeinde Weilrod 06435003005 Gemeinde Linsengericht 118214 06438006001 Gemeinde Egelsbach 49.9711111 8.6702778 06531003005 Gemeinde Reiskirchen 06532023010 Gemeinde Hüttenberg 119192 06611000007 Gemeinde Fuldabrück 51.2666667 9.4833333 119195 06611000011 Gemeinde Lohfelden 51.2666667 9.5333333 06632005001 Gemeinde Bebra 06634003005 Gemeinde Edermünde 06635017001 Gemeinde Rauschenberg 120613 07135092003 Gemeinde Briedel 50.0166667 7.15 120643 07137089008 Gemeinde Welling 50.3333333 7.3166667 120673 07137501007 Gemeinde Moselkern 50.2 7.3666667 120966 07141121008 Gemeinde Patersberg 50.15 7.7333333 121204 07232307002 Gemeinde Wawern 50.1166667 6.4833333 121444 07317000024 Gemeinde Thaleischweiler-Fröschen 49.2666667 7.5833333 121445 07317000025 Gemeinde Vinningen 49.1666667 7.55 121447 07317000032 Gemeinde Donsieders 49.2666667 7.6 08117006003 Gemeinde Deggingen 82295 08118001002 Gemeinde Burgstetten 48.9333333 9.3666667 08119055005 Gemeinde Urbach 08128007011 Gemeinde Igersheim 83666 08135016003 Gemeinde Hermaringen 48.5954428 10.2606511 08136019045 Gemeinde Rainau 84166 08216007005 Gemeinde Bühlertal 48.6833333 8.1833333 08231000013 Gemeinde Neulingen 08236038008 Gemeinde Sternenfels 08236070006 Gemeinde Remchingen 84655 08237075004 Gemeinde Oberwolfach 48.3166667 8.2166667 08315109002 Gemeinde Kirchzarten 84781 08315113004 Gemeinde Hinterzarten 47.9 8.1 08317047002 Gemeinde Friesenheim 08317057014 Gemeinde Willstätt 08336104006 Gemeinde Schliengen 85634 08337125009 Gemeinde Lauchringen 47.6166667 8.3 08337126024 Gemeinde Weilheim 86321 08435034010 Gemeinde Stetten 47.6901214 9.2985535 08437100006 Gemeinde Boms 09161000902 Gemeinde Großmehring 09171123068 Gemeinde Zeilarn 09171126029 Gemeinde Reischach 09171129044 Gemeinde Neuötting 09171129078 Gemeinde Winhöring 09172116004 Gemeinde Bischofswiesen 122284 09173112008 Gemeinde Greiling 47.7666667 11.6166667 122606 09174115006 Gemeinde Karlsfeld 48.2166667 11.4666667 09175115039 Gemeinde Steinhöring 09175119007 Gemeinde Aßling 09175131002 Gemeinde Egmating 09176123012 Gemeinde Schernfeld 123119 09176139005 Gemeinde Lenting 48.8 11.4666667 09177124024 Gemeinde Wartenberg 09177131001 Gemeinde Finsing 09177139038 Gemeinde Hohenpolding 09177143007 Gemeinde Langenpreising 09178124013 Gemeinde Marzling 09178142031 Gemeinde Wang 09182119033 Gemeinde Schliersee 124445 09182125073 Gemeinde Warngau 47.8321721 11.7217255 09182133019 Gemeinde Weyarn 09183144003 Gemeinde Ampfing 09183148002 Gemeinde Aschau 09184118003 Gemeinde Vaterstetten 09184136002 Gemeinde Taufkirchen 09184139001 Gemeinde Baierbrunn 09184147001 Gemeinde Ismaning 09184149002 Gemeinde Hebertshausen 09186130003 Gemeinde Scheyern 09186151011 Gemeinde Gerolsbach 125480 09186152017 Gemeinde Hettenshausen 48.5 11.5 09187169007 Gemeinde Frasdorf 09187186019 Gemeinde Maitenbeth 09189142007 Gemeinde Babensham 09189148044 Gemeinde Teisendorf 09189162061 Gemeinde Kirchanschöring 09190139014 Gemeinde Hohenpeißenberg 09261000037 Gemeinde Tiefenbach 09273115013 Gemeinde Pfeffenhausen 09273147002 Gemeinde Attenhofen 09274114038 Gemeinde Vilsheim 09275124034 Gemeinde Haarbach 09277122036 Gemeinde Pleiskirchen 09277124118 Gemeinde Schönau 09277152064 Gemeinde Reut 09278154048 Gemeinde Perasdorf 09372116051 Gemeinde Willmering 09372135002 Gemeinde Arrach 09372153069 Gemeinde Schorndorf 09372163024 Gemeinde Treffelstein 09375199014 Gemeinde Nittendorf 09376149010 Gemeinde Bruck 09377141008 Gemeinde Leonberg 09463000001 Gemeinde Ahorn 09476180007 Gemeinde Steinbach am Wald 09476184015 Gemeinde Steinwiesen 09574123003 Gemeinde Schwarzenbruck 09574140004 Gemeinde Hartenstein 09661000003 Gemeinde Goldbach 139644 09679205003 Gemeinde Waldbrunn 49.7586111 9.8036111 09762000001 Gemeinde Germaringen 09774121003 Gemeinde Kammeltal 09776112002 Gemeinde Maierhöfen 140873 09777175001 Gemeinde Aitrang 47.8166667 10.5333333 09778136012 Gemeinde Westerheim 09780115009 Gemeinde Ofterschwang 09780146009 Gemeinde Buchenberg 11000000900003 Gemeinde Glienicke / Nordbahn 11000000900004 Gemeinde Schönfließ 14161000026 Gemeinde Niederwiesa 14171010006 Gemeinde Wiesa 14171110002 Gemeinde Venusberg 14177150003 Gemeinde Hilbersdorf 14188020002 Gemeinde Hormersdorf 16054000003 Gemeinde Sankt Kilian 16066014002 Gemeinde Kleinschmalkalden 16070017002 Gemeinde Suhl 16070049001 Gemeinde Ilmenau 16076022002 Gemeinde Neumühle > Der Löschlink wurde meines Wissens ja entfernt, damit durch das > Indizieren durch Google und Co keine Datensätze gelöscht werden können. > Doch wie kann ich nun diesen Datensatz aus der openGeoDB entfernen? Durch den Zusatz ";action=delete" http://fa-technik.adfc.de/code/opengeodb.pl?locid=125480;c=DE;action=delete Schönen Gruß Martin From wendorff at uni-paderborn.de Thu Apr 10 08:57:42 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Thu, 10 Apr 2008 08:57:42 +0200 Subject: [opengeodb] =?iso-8859-1?q?L=F6schen_bei_fa-technik=2Eadfc=2Ede?= In-Reply-To: <47FDB957.7060701@gmx.de> References: <1207771296.6384.9.camel@daxi-laptop> <47FDB957.7060701@gmx.de> Message-ID: <47FDBA66.6090901@uni-paderborn.de> Löschlink bei fa-technik.adfc.de: Martin Trautmann schrieb: > > > > Der Löschlink wurde meines Wissens ja entfernt, damit durch das > > Indizieren durch Google und Co keine Datensätze gelöscht werden können. > > Doch wie kann ich nun diesen Datensatz aus der openGeoDB entfernen? > > Durch den Zusatz ";action=delete" > http://fa-technik.adfc.de/code/opengeodb.pl?locid=125480;c=DE;action=delete > Falls sich jemand da nochmal dransetzen möchte: Es sollte helfen, das Löschen in ein Formular zu packen, da diese durch Suchmaschinen nicht verfolgt werden. Gruß Peter Wendorff From traut at gmx.de Thu Apr 10 09:19:46 2008 From: traut at gmx.de (Martin Trautmann) Date: Thu, 10 Apr 2008 09:19:46 +0200 Subject: [opengeodb] =?iso-8859-1?q?L=F6schen_bei_fa-technik=2Eadfc=2Ede?= In-Reply-To: <47FDBA66.6090901@uni-paderborn.de> References: <1207771296.6384.9.camel@daxi-laptop> <47FDB957.7060701@gmx.de> <47FDBA66.6090901@uni-paderborn.de> Message-ID: <47FDBF92.5060804@gmx.de> Peter Wendorff wrote: >> Durch den Zusatz ";action=delete" >> http://fa-technik.adfc.de/code/opengeodb.pl?locid=125480;c=DE;action=delete >> > Falls sich jemand da nochmal dransetzen möchte: > Es sollte helfen, das Löschen in ein Formular zu packen, da diese durch > Suchmaschinen nicht verfolgt werden. Ja, das wär' vielleicht das einfachste. Bisher haben wir noch nicht so viel zu löschen. Und das aktuelle Prozedere ist noch nicht ausgereift, da Löschen die Nennung von E-Mail und user erfordert, ohne gleich zu löschen - vielleicht sollte ich da auch noch entsprechende Cookies zulassen bzw. nach der Eingabe auch richtig weitermachen, statt dass der Benutzer selbst merken muss, dass er es nochmals zu versuchen hat. Schönen Gruß Martin From geodb at daxis.de Thu Apr 10 12:44:15 2008 From: geodb at daxis.de (Daxi) Date: Thu, 10 Apr 2008 12:44:15 +0200 Subject: [opengeodb] =?iso-8859-1?q?ADFC-Admin=3A_Ort_doppelt=2C_einmal_fe?= =?iso-8859-1?q?hlerhaft=2C_wie_l=F6schen=3F?= In-Reply-To: <47FDB957.7060701@gmx.de> References: <1207771296.6384.9.camel@daxi-laptop> <47FDB957.7060701@gmx.de> Message-ID: <1207824255.6393.11.camel@daxi-laptop> Also zu der Straße oder dem Hof - ich weiß selber nicht genau, was das denn genau ist - fällt mir nichts ein. Fakt ist jedoch, dass Hettenshausen zur VG Ilmmünster gehört. Daher habe ich den Eintrag jetzt mal zum Löschen markiert. Wo Harres hinzugehört weiß ich jedoch nicht. Gruß, Christian Am Donnerstag, den 10.04.2008, 08:53 +0200 schrieb Martin Trautmann: > Daxi wrote: > > Hallo zusammen, > > > > ich habe mir vom ADFC die aktuellen Dumps für Deutschland > > heruntergeladen. > > Bei den ersten Test-Queries habe ich die "Gemeinde Hettenshausen" als > > Teil von "Schweitenkirchen" mit der ID 125480 gefunden. > > (siehe http://fa-technik.adfc.de/code/opengeodb.pl?locid=125480;c=DE) > > > > Ich kann ich aber nicht daran entsinnen, dass unsere Gemeinde zu > > Schweitenkirchen gehört. > > Der Eintrag 18293 ist jedenfalls der richtige. > > (siehe http://fa-technik.adfc.de/code/opengeodb.pl?locid=18293;c=DE) > > Die Frage ist sehr berechtigt - wie kann es sein, dass Hettenshausen als > Ortsteil von Schweitenkirchen hineinrutschte? Schweitenkirchen hat eine > gemeindepolitisch recht lebhafte Geschichte: > http://home.bn-paf.de/schweitenkirchen/Chronik/chronik.htm > > Ich würde vermuten, dass bei der Gemeindereform zwischen 1971 und 1978 > ein Gemeindeteil von Hettenshausen nach Schweitenkirchen kam. Konkret > handelt es sich vermutlich um die Straße oder den Hof "Harres" - fällt > dir dazu etwas ein? > > Mit entsprechenden Fragezeichen sollte all das geprüft werden: > 106216 01053090002 Gemeinde Grambek 53.5666667 10.6833333 > 01057087004 Gemeinde Wisch > 020000000001 Gemeinde Jork > 03152012004 Gemeinde Friedland > 03153005003 Gemeinde Bad Harzburg > 107868 03154010009 Gemeinde Wolsdorf 52.2 10.95 > 03251021001 Gemeinde Bahrenborstel > 03251040020 Gemeinde Maasen > 03254002006 Gemeinde Freden > 03254021004 Gemeinde Diekholzen > 03254022011 Gemeinde Söhlde > 03256022007 Gemeinde Stöckse > 109294 03256032515 Gemeinde Leese 52.5 9.1166667 > 03257031002 Gemeinde Buchholz > 109441 03352003004 Gemeinde Flögeln 53.6666667 8.8166667 > 03353005006 Gemeinde Jesteburg > 03354004007 Gemeinde Gusborn > 110367 03357051004 Gemeinde Bothel 53.0666667 9.5 > 03403000002 Gemeinde Bad Zwischenahn > 03452017002 Gemeinde Südbrookmerland > 03452023004 Gemeinde Großheide > 111669 03454042001 Gemeinde Lorup 52.9 7.6166667 > 03455020026 Gemeinde Wittmund > 03457016002 Gemeinde Brinkum > 03458008002 Gemeinde Bassum > 03459005001 Gemeinde Bad Iburg > 112603 03461007004 Gemeinde Butjadingen 53.5472222 8.335 > 03462019032 Gemeinde Wangerland > 05166024013 Gemeinde Niederkrüchten > 05354012019 Gemeinde Langerwehe > 113725 05358028006 Gemeinde Hürtgenwald 50.7166667 6.3666667 > 05358028010 Gemeinde Nideggen > 05374052019 Gemeinde Kürten > 05374052022 Gemeinde Lindlar > 05378004024 Gemeinde Odenthal > 05570008002 Gemeinde Ennigerloh > 05766044005 Gemeinde Kalletal > 05770008008 Gemeinde Preußisch Oldendorf > 05770028021 Gemeinde Meerbeck > 05770036001 Gemeinde Bad Essen > 05770036012 Gemeinde Rödinghausen > 05962020005 Gemeinde Plettenberg > 05962032017 Gemeinde Schalksmühle > 05962052004 Gemeinde Herscheid > 06434009010 Gemeinde Weilrod > 06435003005 Gemeinde Linsengericht > 118214 06438006001 Gemeinde Egelsbach 49.9711111 8.6702778 > 06531003005 Gemeinde Reiskirchen > 06532023010 Gemeinde Hüttenberg > 119192 06611000007 Gemeinde Fuldabrück 51.2666667 9.4833333 > 119195 06611000011 Gemeinde Lohfelden 51.2666667 9.5333333 > 06632005001 Gemeinde Bebra > 06634003005 Gemeinde Edermünde > 06635017001 Gemeinde Rauschenberg > 120613 07135092003 Gemeinde Briedel 50.0166667 7.15 > 120643 07137089008 Gemeinde Welling 50.3333333 7.3166667 > 120673 07137501007 Gemeinde Moselkern 50.2 7.3666667 > 120966 07141121008 Gemeinde Patersberg 50.15 7.7333333 > 121204 07232307002 Gemeinde Wawern 50.1166667 6.4833333 > 121444 07317000024 Gemeinde Thaleischweiler-Fröschen 49.2666667 7.5833333 > 121445 07317000025 Gemeinde Vinningen 49.1666667 7.55 > 121447 07317000032 Gemeinde Donsieders 49.2666667 7.6 > 08117006003 Gemeinde Deggingen > 82295 08118001002 Gemeinde Burgstetten 48.9333333 9.3666667 > 08119055005 Gemeinde Urbach > 08128007011 Gemeinde Igersheim > 83666 08135016003 Gemeinde Hermaringen 48.5954428 10.2606511 > 08136019045 Gemeinde Rainau > 84166 08216007005 Gemeinde Bühlertal 48.6833333 8.1833333 > 08231000013 Gemeinde Neulingen > 08236038008 Gemeinde Sternenfels > 08236070006 Gemeinde Remchingen > 84655 08237075004 Gemeinde Oberwolfach 48.3166667 8.2166667 > 08315109002 Gemeinde Kirchzarten > 84781 08315113004 Gemeinde Hinterzarten 47.9 8.1 > 08317047002 Gemeinde Friesenheim > 08317057014 Gemeinde Willstätt > 08336104006 Gemeinde Schliengen > 85634 08337125009 Gemeinde Lauchringen 47.6166667 8.3 > 08337126024 Gemeinde Weilheim > 86321 08435034010 Gemeinde Stetten 47.6901214 9.2985535 > 08437100006 Gemeinde Boms > 09161000902 Gemeinde Großmehring > 09171123068 Gemeinde Zeilarn > 09171126029 Gemeinde Reischach > 09171129044 Gemeinde Neuötting > 09171129078 Gemeinde Winhöring > 09172116004 Gemeinde Bischofswiesen > 122284 09173112008 Gemeinde Greiling 47.7666667 11.6166667 > 122606 09174115006 Gemeinde Karlsfeld 48.2166667 11.4666667 > 09175115039 Gemeinde Steinhöring > 09175119007 Gemeinde Aßling > 09175131002 Gemeinde Egmating > 09176123012 Gemeinde Schernfeld > 123119 09176139005 Gemeinde Lenting 48.8 11.4666667 > 09177124024 Gemeinde Wartenberg > 09177131001 Gemeinde Finsing > 09177139038 Gemeinde Hohenpolding > 09177143007 Gemeinde Langenpreising > 09178124013 Gemeinde Marzling > 09178142031 Gemeinde Wang > 09182119033 Gemeinde Schliersee > 124445 09182125073 Gemeinde Warngau 47.8321721 11.7217255 > 09182133019 Gemeinde Weyarn > 09183144003 Gemeinde Ampfing > 09183148002 Gemeinde Aschau > 09184118003 Gemeinde Vaterstetten > 09184136002 Gemeinde Taufkirchen > 09184139001 Gemeinde Baierbrunn > 09184147001 Gemeinde Ismaning > 09184149002 Gemeinde Hebertshausen > 09186130003 Gemeinde Scheyern > 09186151011 Gemeinde Gerolsbach > 125480 09186152017 Gemeinde Hettenshausen 48.5 11.5 > 09187169007 Gemeinde Frasdorf > 09187186019 Gemeinde Maitenbeth > 09189142007 Gemeinde Babensham > 09189148044 Gemeinde Teisendorf > 09189162061 Gemeinde Kirchanschöring > 09190139014 Gemeinde Hohenpeißenberg > 09261000037 Gemeinde Tiefenbach > 09273115013 Gemeinde Pfeffenhausen > 09273147002 Gemeinde Attenhofen > 09274114038 Gemeinde Vilsheim > 09275124034 Gemeinde Haarbach > 09277122036 Gemeinde Pleiskirchen > 09277124118 Gemeinde Schönau > 09277152064 Gemeinde Reut > 09278154048 Gemeinde Perasdorf > 09372116051 Gemeinde Willmering > 09372135002 Gemeinde Arrach > 09372153069 Gemeinde Schorndorf > 09372163024 Gemeinde Treffelstein > 09375199014 Gemeinde Nittendorf > 09376149010 Gemeinde Bruck > 09377141008 Gemeinde Leonberg > 09463000001 Gemeinde Ahorn > 09476180007 Gemeinde Steinbach am Wald > 09476184015 Gemeinde Steinwiesen > 09574123003 Gemeinde Schwarzenbruck > 09574140004 Gemeinde Hartenstein > 09661000003 Gemeinde Goldbach > 139644 09679205003 Gemeinde Waldbrunn 49.7586111 9.8036111 > 09762000001 Gemeinde Germaringen > 09774121003 Gemeinde Kammeltal > 09776112002 Gemeinde Maierhöfen > 140873 09777175001 Gemeinde Aitrang 47.8166667 10.5333333 > 09778136012 Gemeinde Westerheim > 09780115009 Gemeinde Ofterschwang > 09780146009 Gemeinde Buchenberg > 11000000900003 Gemeinde Glienicke / Nordbahn > 11000000900004 Gemeinde Schönfließ > 14161000026 Gemeinde Niederwiesa > 14171010006 Gemeinde Wiesa > 14171110002 Gemeinde Venusberg > 14177150003 Gemeinde Hilbersdorf > 14188020002 Gemeinde Hormersdorf > 16054000003 Gemeinde Sankt Kilian > 16066014002 Gemeinde Kleinschmalkalden > 16070017002 Gemeinde Suhl > 16070049001 Gemeinde Ilmenau > 16076022002 Gemeinde Neumühle > > > Der Löschlink wurde meines Wissens ja entfernt, damit durch das > > Indizieren durch Google und Co keine Datensätze gelöscht werden können. > > Doch wie kann ich nun diesen Datensatz aus der openGeoDB entfernen? > > Durch den Zusatz ";action=delete" > http://fa-technik.adfc.de/code/opengeodb.pl?locid=125480;c=DE;action=delete > > Schönen Gruß > Martin From s.riedel at 4-visions.net Wed Apr 16 17:00:44 2008 From: s.riedel at 4-visions.net (Stefan Riedel @ 4 Visions GmbH) Date: Wed, 16 Apr 2008 17:00:44 +0200 Subject: [opengeodb] =?iso-8859-1?q?Verst=E4ndnisfrage_zu_lat_und_lon?= Message-ID: <000901c89fd2$b61a3ae0$224eb0a0$@riedel@4-visions.net> Hallo Liste, ich bin gerade dabei, mich ein wenig in opengeodb einzuarbeiten und stoße da doch schon recht früh an einige Probleme. Und zwar wird in der Datei: grafikOGDB.php (Version 0.3) des Paketes infoOGDB, das Picture: karte_001.jpg mit Daten gefüllt, bzw. es werden rote Punkte auf die Karte gezeichnet. Wenn ich jetzt aber die Karte austauschen möchte, beispielsweise eine der auf sourceforge zur verfügung gestellten. Passen die Konstanten, der Koordinaten der Karte nicht mehr. Nun wäre meine Frage gewesen, ob mir jemand sagen kann, wie ich die errechnen kann? Gruß Stefan -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20080416/c44a64f5/attachment.htm From list at tridemail.de Wed Apr 30 15:26:43 2008 From: list at tridemail.de (Michael Borchers) Date: Wed, 30 Apr 2008 15:26:43 +0200 Subject: [opengeodb] =?windows-1252?q?Aktuelle_text=5Fplz_MySQL_Tabelle_f?= =?windows-1252?q?=FCr_SCHWEIZ?= References: <87bqhvex5p.fsf@biokovo.herceg.de> <000901c77c04$bbd0df90$af24a8c0@SF2003.de> <000601c7facc$e79718a0$af24a8c0@SF2003.de> <86BB3FE2-CC3F-4BD5-AB54-67E923C1C531@netconstructions.de> <000e01c80048$05d612a0$af24a8c0@SF2003.de> <000801c800f0$ac202d00$af24a8c0@SF2003.de> Message-ID: <001201c8aac5$d8773770$1e00a8c0@MBPC> >>>>> Am 19.09.2007 um 16:53 schrieb Michael Borchers: >>>>> >>>>>> Hi, >>>>>> wir verwenden für unsere Zwecke die Längen- und Breitengrade aus >>>>>> der MySQL >>>>>> Tabelle text_plz, gibt es da zur Zeit eine aktuelle Version? >>>>>> Wir vermissen z.B. die PLZ 01328. >>>>>> >>>>>> Danke >>>> >>>> Hallo, >>>> es sieht wohl so aus, dass es kein Update der Datenbank geben wird. >>>> Begründung war in etwa: >>>> Bei einigen PLZ handelt es sich um "Untergebiete" oder Zahlen, die >>>> lediglich verwaltungstechnische >>>> Gründe haben, daher werden sie nicht erfasst:( Gab/Gibt es einen SQL Dump im Stil der damaligen text_plz auch für die Schweiz?!