From felix.schwarz at oss.schwarz.eu Mon Dec 3 14:36:16 2007 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Mon, 03 Dec 2007 14:36:16 +0100 Subject: [opengeodb] Welche Daten sind die aktuellsten? Message-ID: <47540650.6010203@oss.schwarz.eu> Hallo, ich möchte den Datenbestand der OpenGeoDB für eine Applikation evaluieren. Nach Durchsicht des Mailing-Listen-Archivs und etwas gegoogelt habe, scheint der "ADFC-Dump" derzeit die aktuellsten Daten zu beinhalten und auch am besten gepflegt zu werden. Leider gibt es unter http://fa-technik.adfc.de/code/opengeodb/ viele verschiedene Dateien, deren Sinn sich mir nicht direkt erschließt. Ich hätte gerne einen SQL-Dump, den ich automatisiert importieren kann. Unter http://fa-technik.adfc.de/code/opengeodb/dump/ gibt es MySQL-Dumps, allerdings ist mir nicht klar, worin sich die dumps unterscheiden - bzw. genauer: /worin/ sie sich unterscheiden, sehe ich im diff, nur /welchen/ Zweck erfüllen die Unterschiede? Vielen Dank, Felix Schwarz From felix.schwarz at oss.schwarz.eu Mon Dec 3 15:26:00 2007 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Mon, 03 Dec 2007 15:26:00 +0100 Subject: [opengeodb] Welche Daten sind die aktuellsten? In-Reply-To: <47540650.6010203@oss.schwarz.eu> References: <47540650.6010203@oss.schwarz.eu> Message-ID: <475411F8.5010709@oss.schwarz.eu> Noch ein paar ergänzende Fragen zum Datenbestand: Nachdem ich opengeodb-0251_2007-10-02.sql aus dem ADFC-Bestand importiert habe, gibt es mehrere Datensätze, die für mich keinen Sinn ergeben, z.B. loc_id 23519. mysql> select loc_id, lon, lat, valid_since, valid_until from geodb_coordinates where loc_id = 23519; +--------+------------------+------------------+-------------+-------------+ | loc_id | lon | lat | valid_since | valid_until | +--------+------------------+------------------+-------------+-------------+ | 23519 | 11.2440571428571 | 51.5083285714286 | NULL | 3000-01-01 | | 23519 | 51.4667 | 11.3 | NULL | 2005-09-30 | | 23519 | 51.5083285714286 | 11.2440571428571 | 2005-12-01 | 3000-01-01 | | 23519 | 51.5089692307692 | 11.2346230769231 | 2005-10-01 | 2005-11-30 | +--------+------------------+------------------+-------------+-------------+ Laut GeoDatenZentrum ist der erste Eintrag in etwa richtig. Warum ist der 3. dann nicht abgelaufen bzw. wie kann man algorithmisch entscheiden, dass der erste richtig ist? Ähnliches scheint bei allen IDs zu gelten, die die Abfrage select * from geodb_coordinates where date_type_since is not null; zurückliefert. Nur in opengeodb-02510_2007-10-02.sql ist der Eintrag offenbar richtig, da dort auch nur ein Datensatz für die o.g. loc_id besteht. Leider lässt sich diese Datei nicht in MySQL importieren: $ mysql --user=root opengeo < opengeodb-02510_2007-10-02.sql ERROR 1136 (21S01) at line 232: Column count doesn't match value count at row 1 Gibt es da Abhilfe bzw. mit welchem Datenbestand habt ihr gute Erfahrungen gemacht? Vielen Dank, Felix Schwarz From traut at gmx.de Mon Dec 3 20:42:26 2007 From: traut at gmx.de (Martin Trautmann) Date: Mon, 03 Dec 2007 20:42:26 +0100 Subject: [opengeodb] Welche Daten sind die aktuellsten? In-Reply-To: <47540650.6010203@oss.schwarz.eu> References: <47540650.6010203@oss.schwarz.eu> Message-ID: <47545C22.8000708@gmx.de> Felix Schwarz wrote: > Hallo, > > ich möchte den Datenbestand der OpenGeoDB für eine Applikation evaluieren. Nach Durchsicht des > Mailing-Listen-Archivs und etwas gegoogelt habe, scheint der "ADFC-Dump" derzeit die aktuellsten > Daten zu beinhalten und auch am besten gepflegt zu werden. Hallo Felix, die sourceforge-release entsprach diesen Daten. > Leider gibt es unter http://fa-technik.adfc.de/code/opengeodb/ viele verschiedene Dateien, deren > Sinn sich mir nicht direkt erschließt. Ich hätte gerne einen SQL-Dump, den ich automatisiert > importieren kann. Unter http://fa-technik.adfc.de/code/opengeodb/dump/ gibt es MySQL-Dumps, > allerdings ist mir nicht klar, worin sich die dumps unterscheiden - bzw. genauer: /worin/ sie > sich unterscheiden, sehe ich im diff, nur /welchen/ Zweck erfüllen die Unterschiede? Es waren verschiedene Versionen, die jeweils durch Fehlerrückmeldungen kurzfristig hintereinander entstanden. 025 verlinkt auf die letzte 0253, die auch der auf sourceforge entspricht. Vor kurzem erstellte ich für dich eine neue 026, Erklärung dazu separat. Schönen Gruß Martin From traut at gmx.de Mon Dec 3 20:53:36 2007 From: traut at gmx.de (Martin Trautmann) Date: Mon, 03 Dec 2007 20:53:36 +0100 Subject: [opengeodb] Welche Daten sind die aktuellsten? In-Reply-To: <475411F8.5010709@oss.schwarz.eu> References: <47540650.6010203@oss.schwarz.eu> <475411F8.5010709@oss.schwarz.eu> Message-ID: <47545EC0.7090202@gmx.de> Felix Schwarz wrote: > Noch ein paar ergänzende Fragen zum Datenbestand: > > Nachdem ich opengeodb-0251_2007-10-02.sql aus dem ADFC-Bestand importiert > habe, gibt es mehrere Datensätze, die für mich keinen Sinn ergeben, z.B. > loc_id 23519. > > mysql> select loc_id, lon, lat, valid_since, valid_until from geodb_coordinates where loc_id = 23519; > +--------+------------------+------------------+-------------+-------------+ > | loc_id | lon | lat | valid_since | valid_until | > +--------+------------------+------------------+-------------+-------------+ > | 23519 | 11.2440571428571 | 51.5083285714286 | NULL | 3000-01-01 | > | 23519 | 51.4667 | 11.3 | NULL | 2005-09-30 | > | 23519 | 51.5083285714286 | 11.2440571428571 | 2005-12-01 | 3000-01-01 | > | 23519 | 51.5089692307692 | 11.2346230769231 | 2005-10-01 | 2005-11-30 | > +--------+------------------+------------------+-------------+-------------+ > > Laut GeoDatenZentrum ist der erste Eintrag in etwa richtig. Warum ist der 3. dann > nicht abgelaufen bzw. wie kann man algorithmisch entscheiden, dass der erste richtig > ist? Der erste ist der aktuellste und richtige - er stammt aus D.tab und wurde in SQL umgewandelt. Dabei wurden valid_since mit NULL und valid until mit 3000-01-01 aufgefüllt. Die nächsten drei Zeilen stammen aus der extra.sql, wo Daten mit Datum hinterlegt sind. Dort hatte ich eigentlich die Reihenfolge schon auf das gängigere lat/lon umgestellt - nur in der Umwandlung von tab nach sql es bei der alten lon/lat belassen. Die neue Datenstruktur kommt in Zukunft also mit lat,lon, daher auch die neue 026-dump-Version. So viel also zur Vertauschung von lon und lat in deiner Tabelle. Die zweite Zeile stellt die ersten Koordinatenangaben dar: bis 2005-09-30 die vierte Zeile hat die Folgedaten: 2005-10-01 bis 2005-11-30 die dritte Zeile hat die seither gültigen Daten ab 2005-12-01. Weil diese Daten ein Beginn-Datum haben, tauchen sie doppelt auf: einmal ohne aus den D.tab-Rohdaten, einmal aus dem extra.sql Wolltest du das bereinigen, so solltest du dir entsprechend die Daten zusammenbasteln, z.B. indem du alle Daten ohne Begin-Datum wegwirfst, wenn es dafür noch weitere Daten mit gültigen begin-until gibt. Das geht zumindest, wenn die Inhalte identisch sind. Andernfalls kannst du zusätzlich die changes.sql heranziehen, um festzustellen, wann sie geändert wurden. > Gibt es da Abhilfe bzw. mit welchem Datenbestand habt ihr gute Erfahrungen gemacht? Wenn ich Rückmeldungen bekomme, dann kan ich dem teilweise Abhilfe verschaffen. Schönen Gruß Martin From froschpopo at gmx.de Tue Dec 4 15:52:47 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Tue, 04 Dec 2007 15:52:47 +0100 Subject: [opengeodb] stadtname, lon, lat, postleitzahl - nur aus deutschland Message-ID: <475569BF.8040200@gmx.de> Hallo Zusammen! ich habe mir ein SQL-Statement gebastelt, um "Stadtname, lon, lat, postleitzahl" auszugeben. Das dient dem Zweck, dass ich mir eine eigene, einfacherer Architektur erstellen möchte, die nur diejenigen Daten enthält, die ich auch wirklich benötige. Bevor ich das Problem beschreibe, hier mein Ansatz: SELECT plz.text_val AS stadt, position.lon, position.lat, FROM geodb_textdata plz, geodb_textdata ort, geodb_coordinates position WHERE position.loc_id = plz.loc_id AND ort.loc_id = plz.loc_id AND plz.text_type = 500300000 AND ort.text_type = 500100000 ORDER BY 2 Nun zum Problemchen: Wie schaffe ich es, das Ergebnis auf Orte in Deutschland zu beschränken? Ich muss dazu noch anfügen: Ich tue mich ziehmlich schwer diese Ebenen-Geschichte zu verstehen, weil sich alles in mir gegen diese undurchsichtige Architektur von geodb_hierarchies streubt. Ich hatte zwischendurch mal ansatzweise die Funktionalität halbwegs verstanden, bin dann aber 2 Minuten später so derart durcheinander gekommen, dass ich alles wieder vergessen habe und im Grunde jedesmal von Vorn beginnen muss. Es bringt deshalb nicht allzu viel mich darauf hinzuweisen, dass ich alle Ebenen durcharbeiten muss. ich weiss nämlich weder, womit ich anfangen soll, geschweige wo ich aufhören muss zu suchen Hänge schon die ganze Nacht daran und bin deshalb entsprechend Müde. In sämtlichen Foren stoße ich auf ratlosigkeit weil keiner weiss wie man geodb_hierarchies füllen muss. Andere hatten selbiges Problem und haben nach 2 Wochen aufgegeben. LG From traut at gmx.de Tue Dec 4 16:01:42 2007 From: traut at gmx.de (genabbelt) Date: Tue, 4 Dec 2007 07:01:42 -0800 (PST) Subject: [opengeodb] stadtname, lon, lat, postleitzahl - nur aus deutschland In-Reply-To: <475569BF.8040200@gmx.de> References: <475569BF.8040200@gmx.de> Message-ID: <14152222.post@talk.nabble.com> > Nun zum Problemchen: Wie schaffe ich es, das Ergebnis auf Orte in Deutschland zu beschränken? Hallo Lucas, wenn deine Probleme derart massiv sind, dann beschraenke dich am einfachsten auf http://fa-technik.adfc.de/code/opengeodb/D.sql Setze die http://fa-technik.adfc.de/code/opengeodb/opengeodb-begin.sql davor und die http://fa-technik.adfc.de/code/opengeodb/opengeodb-end.sql dahinter, dann hast du alle aktuellen Daten fuer Deutschland alleine. -- View this message in context: http://www.nabble.com/stadtname%2C-lon%2C-lat%2C-postleitzahl---nur-aus-deutschland-tf4943567.html#a14152222 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From sn at heise.de Tue Dec 4 16:23:33 2007 From: sn at heise.de (Sven Neuhaus) Date: Tue, 04 Dec 2007 16:23:33 +0100 Subject: [opengeodb] stadtname, lon, lat, postleitzahl - nur aus deutschland In-Reply-To: <475569BF.8040200@gmx.de> References: <475569BF.8040200@gmx.de> Message-ID: <475570F5.6080400@heise.de> Hallo Lucas, Lucas Mengel schrieb: > ich habe mir ein SQL-Statement gebastelt, um "Stadtname, lon, lat, > postleitzahl" auszugeben. > Das dient dem Zweck, dass ich mir eine eigene, einfacherer Architektur > erstellen möchte, die nur diejenigen Daten enthält, > die ich auch wirklich benötige. > > Bevor ich das Problem beschreibe, hier mein Ansatz: > > SELECT > plz.text_val AS stadt, > position.lon, > position.lat, > FROM > geodb_textdata plz, > geodb_textdata ort, > geodb_coordinates position > WHERE > position.loc_id = plz.loc_id AND > ort.loc_id = plz.loc_id AND > plz.text_type = 500300000 AND > ort.text_type = 500100000 > ORDER BY 2 > > > Nun zum Problemchen: Wie schaffe ich es, das Ergebnis auf Orte in > Deutschland zu beschränken? Das Statement mit hinzugefügter Beschränkung auf Deutschland sieht so aus: SELECT plz.text_val AS stadt, position.lon, position.lat FROM geodb_textdata plz, geodb_textdata ort, geodb_textdata land, geodb_coordinates position, geodb_locations lo, geodb_hierarchies hi WHERE lo.loc_type = 100200000 /* State */ AND lo.loc_id = land.loc_id AND land.text_type = 500100001 /* ISO_3166_1_ALPHA_2 */ AND land.text_val = 'DE' AND hi.id_lvl2 = lo.loc_id AND hi.loc_id = plz.loc_id AND position.loc_id = plz.loc_id AND ort.loc_id = plz.loc_id AND plz.text_type = 500300000 AND ort.text_type = 500100000 ORDER BY 2 Aber vielleicht solltest Du lieber das folgende Statement verwenden, das liefert genauere Koordinaten (dafür aber weniger Einträge): SELECT DISTINCT text_val, lon, lat FROM geodb_coordinates co, geodb_textdata tx, geodb_locations lo, geodb_hierarchies hi WHERE lo.loc_id = tx.loc_id AND lo.loc_id = co.loc_id AND lo.loc_id = hi.loc_id AND loc_type = 100800000 /* LOC_AREA_CODE */ AND text_type = 500100000 /* NAME */ Derlei Einträge existieren aber derzeit nur für Deutschland, für Österreich und die Schweiz musst Du auf die Einträge vom Typ 100700000 (POPULATED AREA) zurückgreifen, die weniger genau sind und für diese den Text des Typs 500300000 (AREA_CODE) heraussuchen: SELECT DISTINCT tx.text_val AS plz, hi.id_lvl2 AS staat, lon, lat FROM geodb_textdata tx, geodb_locations lo, geodb_coordinates co, geodb_hierarchies hi WHERE text_type = 500300000 /* AREA_CODE */ AND lo.loc_id = tx.loc_id AND lo.loc_id = hi.loc_id AND lo.loc_id = co.loc_id AND lo.loc_type = 100700000 /* POPULATED AREA */ AND id_lvl2 IN ( SELECT DISTINCT tx.loc_id FROM geodb_textdata tx, geodb_locations lo WHERE text_val in ('AT', 'CH') AND text_type = 500100001 /* ISO_3166_1_ALPHA_2 */ AND tx.loc_id = lo.loc_id AND lo.loc_type = 100200000 /* State */ Der Subselect liefert übrigens immer "106,107" als loc_id für AT und CH, das wird sich vermutlich nicht mal so eben ändern. Gruss, -Sven Neuhaus From felix.schwarz at oss.schwarz.eu Tue Dec 4 18:31:54 2007 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Tue, 04 Dec 2007 18:31:54 +0100 Subject: [opengeodb] Welche Daten sind die aktuellsten? In-Reply-To: <47545EC0.7090202@gmx.de> References: <47540650.6010203@oss.schwarz.eu> <475411F8.5010709@oss.schwarz.eu> <47545EC0.7090202@gmx.de> Message-ID: <47558F0A.7070206@oss.schwarz.eu> Martin Trautmann schrieb: > Die neue Datenstruktur kommt in Zukunft also mit lat,lon, daher auch die > neue 026-dump-Version. Vielen Dank für die schnelle Hilfe. -- Felix Schwarz Software-Entwicklung und Beratung Schwerpunkt: Sichere Datenbank-Anwendungen, Open-Source-Software-Entwicklung From froschpopo at gmx.de Wed Dec 5 01:03:49 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Wed, 05 Dec 2007 01:03:49 +0100 Subject: [opengeodb] stadtname, lon, lat, postleitzahl - nur aus deutschland In-Reply-To: <475570F5.6080400@heise.de> References: <475569BF.8040200@gmx.de> <475570F5.6080400@heise.de> Message-ID: <4755EAE5.8000303@gmx.de> Sven Neuhaus schrieb: > Hallo Lucas, > > Lucas Mengel schrieb: > >> ich habe mir ein SQL-Statement gebastelt, um "Stadtname, lon, lat, >> postleitzahl" auszugeben. >> Das dient dem Zweck, dass ich mir eine eigene, einfacherer Architektur >> erstellen möchte, die nur diejenigen Daten enthält, >> die ich auch wirklich benötige. >> >> Bevor ich das Problem beschreibe, hier mein Ansatz: >> >> SELECT >> plz.text_val AS stadt, >> position.lon, >> position.lat, >> FROM >> geodb_textdata plz, >> geodb_textdata ort, >> geodb_coordinates position >> WHERE >> position.loc_id = plz.loc_id AND >> ort.loc_id = plz.loc_id AND >> plz.text_type = 500300000 AND >> ort.text_type = 500100000 >> ORDER BY 2 >> >> >> Nun zum Problemchen: Wie schaffe ich es, das Ergebnis auf Orte in >> Deutschland zu beschränken? >> > > Das Statement mit hinzugefügter Beschränkung auf Deutschland sieht so aus: > > SELECT > plz.text_val AS stadt, > position.lon, > position.lat > FROM > geodb_textdata plz, > geodb_textdata ort, > geodb_textdata land, > geodb_coordinates position, > geodb_locations lo, > geodb_hierarchies hi > WHERE > lo.loc_type = 100200000 /* State */ > AND lo.loc_id = land.loc_id > AND land.text_type = 500100001 /* ISO_3166_1_ALPHA_2 */ > AND land.text_val = 'DE' > AND hi.id_lvl2 = lo.loc_id > AND hi.loc_id = plz.loc_id > AND position.loc_id = plz.loc_id > AND ort.loc_id = plz.loc_id > AND plz.text_type = 500300000 > AND ort.text_type = 500100000 > ORDER BY 2 > > > Aber vielleicht solltest Du lieber das folgende Statement verwenden, das > liefert genauere Koordinaten (dafür aber weniger Einträge): > > SELECT DISTINCT text_val, lon, lat > FROM geodb_coordinates co, geodb_textdata tx, > geodb_locations lo, geodb_hierarchies hi > WHERE lo.loc_id = tx.loc_id > AND lo.loc_id = co.loc_id > AND lo.loc_id = hi.loc_id > AND loc_type = 100800000 /* LOC_AREA_CODE */ > AND text_type = 500100000 /* NAME */ > > Derlei Einträge existieren aber derzeit nur für Deutschland, für Österreich > und die Schweiz musst Du auf die Einträge vom Typ 100700000 (POPULATED AREA) > zurückgreifen, die weniger genau sind und für diese den Text des Typs > 500300000 (AREA_CODE) heraussuchen: > > SELECT DISTINCT tx.text_val AS plz, hi.id_lvl2 AS staat, lon, lat > FROM geodb_textdata tx, geodb_locations lo, > geodb_coordinates co, geodb_hierarchies hi > WHERE text_type = 500300000 /* AREA_CODE */ > AND lo.loc_id = tx.loc_id > AND lo.loc_id = hi.loc_id > AND lo.loc_id = co.loc_id > AND lo.loc_type = 100700000 /* POPULATED AREA */ > AND id_lvl2 IN ( > SELECT DISTINCT tx.loc_id > FROM geodb_textdata tx, geodb_locations lo > WHERE text_val in ('AT', 'CH') > AND text_type = 500100001 /* ISO_3166_1_ALPHA_2 */ > AND tx.loc_id = lo.loc_id > AND lo.loc_type = 100200000 /* State */ > > Der Subselect liefert übrigens immer "106,107" als loc_id für AT und CH, das > wird sich vermutlich nicht mal so eben ändern. > > Gruss, > -Sven Neuhaus > Hallo Sven! Danke für die Mühe! Allerdings nutze ich die aktuellste Version der geodb und die wird ohne geodb_hierarchies ausgeliefert. Das ist ja genau der Knackpunkt. Ich weiss nicht, wie ich die füllen muss. From sn at heise.de Wed Dec 5 09:39:07 2007 From: sn at heise.de (Sven Neuhaus) Date: Wed, 05 Dec 2007 09:39:07 +0100 Subject: [opengeodb] stadtname, lon, lat, postleitzahl - nur aus deutschland In-Reply-To: <4755EAE5.8000303@gmx.de> References: <475569BF.8040200@gmx.de> <475570F5.6080400@heise.de> <4755EAE5.8000303@gmx.de> Message-ID: <475663AB.503@heise.de> Lucas Mengel schrieb: > Danke für die Mühe! Allerdings nutze ich die aktuellste Version der > geodb und die wird ohne geodb_hierarchies ausgeliefert. Das ist ja genau > der Knackpunkt. > Ich weiss nicht, wie ich die füllen muss. > Der Select benötigt die hierarchies-Tabelle gar nicht, das war nur noch ein Relikt: SELECT DISTINCT text_val, lon, lat FROM geodb_coordinates co, geodb_textdata tx, geodb_locations lo WHERE lo.loc_id = tx.loc_id AND lo.loc_id = co.loc_id AND loc_type = 100800000 /* LOC_AREA_CODE */ AND text_type = 500100000 /* NAME */ Das klappt aber halt nur eher zufällig, weil es derzeit keine solchen Einträge für andere Länder als Deutschland gibt (ich weiss nicht ob das für die aktuelle Version der OpenGeoDB noch zutrifft). Gruss, -Sven Neuhaus From froschpopo at gmx.de Fri Dec 7 12:45:13 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 12:45:13 +0100 Subject: [opengeodb] =?iso-8859-15?q?nochmal=3A_Alle_deutschen_Eintr=E4ge_?= =?iso-8859-15?q?=28mit_Code_von_Sven_Neuhaus=29?= Message-ID: <47593249.7030509@gmx.de> Hallo Liste! Habe heute mal den Code von Sven ausprobiert um mir alle deutschen Postleitzahlen ausgeben zu lassen. Erstmal vielen Dank an Sven. Hier der von mir modifizierte Code: SELECT DISTINCT text_val, lon, lat FROM geodb_coordinates co, geodb_textdata tx, geodb_locations lo WHERE lo.loc_id = tx.loc_id AND lo.loc_id = co.loc_id AND loc_type = 100800000 /* LOC_AREA_CODE */ AND text_type = 500300000 /* NAME */ Jetzt sind allerdings auch einige vierstellige Dabei. Aber auch egal ob ausländische dabei sind oder nicht; in jedem Fall sind 1396 zu wenig! Soweit ich weiss gibt es mehrere tausend Postleitzahlen in Deutschland. Liebe Grüße, Lucas From traut at gmx.de Fri Dec 7 13:29:01 2007 From: traut at gmx.de (genabbelt) Date: Fri, 7 Dec 2007 04:29:01 -0800 (PST) Subject: [opengeodb] =?utf-8?q?nochmal=3A_Alle_deutschen_Eintr=C3=A4ge_=28?= =?utf-8?q?mit_Code_von_Sven_Neuhaus=29?= In-Reply-To: <47593249.7030509@gmx.de> References: <47593249.7030509@gmx.de> Message-ID: <14211549.post@talk.nabble.com> AND loc_type = 100800000 /* LOC_AREA_CODE */ Hallo Lucas, ab der aktuellen 0.2.5 gibt es keine vollstaendigen 100800000 in der opengeodb. Falls du solche findest, dann deshalb, weil sie als Extradaten mit bekanntem Datum gefuehrt werden. Suche in den Archiven - dies wurde hier schon mehrfach erwaehnt. opengeodb ist primaer eine Orts-Datenbank. PLZ-Gebiete gehoeren dazu eigentlich nicht dazu. Wie dir aber schon erklaert wurde, findest du die dafuer tauglichen Daten am einfachsten direkt in der http://fa-technik.adfc.de/code/opengeodb/PLZ.tab Beachte, dass bei einem Ort mit zehn Postleitzahlen alle davon moeglicherweise die gleiche Koordinate haben - weil es die Koordinate des Ortes ist und nicht die seiner Postleitzahlgebiete. Ueberlege also, was dich wirklich interessiert. Eine Bitte am Rande: Zerfleddere nicht weiter die Threads hier indem du dir neue Titel ausdenkst, sondern bleibe im gleichen Thread. Leute mit vernuenftiger E-Mail-Software finden das weit uebersichtlicher. -- View this message in context: http://www.nabble.com/nochmal%3A-Alle-deutschen-Eintr%C3%A4ge-%28mit-Code-von-Sven-Neuhaus%29-tf4961642.html#a14211549 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From froschpopo at gmx.de Fri Dec 7 14:06:47 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 14:06:47 +0100 Subject: [opengeodb] =?iso-8859-1?q?nochmal=3A_Alle_deutschen_Eintr=E4ge_?= =?iso-8859-1?q?=28mit_Code_von_Sven_Neuhaus=29?= In-Reply-To: <14211549.post@talk.nabble.com> References: <47593249.7030509@gmx.de> <14211549.post@talk.nabble.com> Message-ID: <47594567.5060305@gmx.de> Aber die Tabelle ist falsch! Zu der Postleitzahl 20095 gehört nicht einfach nur Hamburg! Dazu gehört auch Hamburg-Altstadt und noch einige weitere Orte die zu dieser Postleitzahl gehören und die sind nur in der opengeoDB zu finden! genabbelt schrieb: > AND loc_type = 100800000 /* LOC_AREA_CODE */ > > Hallo Lucas, > > ab der aktuellen 0.2.5 gibt es keine vollstaendigen 100800000 in der > opengeodb. Falls du solche findest, dann deshalb, weil sie als Extradaten > mit bekanntem Datum gefuehrt werden. > > Suche in den Archiven - dies wurde hier schon mehrfach erwaehnt. opengeodb > ist primaer eine Orts-Datenbank. PLZ-Gebiete gehoeren dazu eigentlich nicht > dazu. Wie dir aber schon erklaert wurde, findest du die dafuer tauglichen > Daten am einfachsten direkt in der > http://fa-technik.adfc.de/code/opengeodb/PLZ.tab > > Beachte, dass bei einem Ort mit zehn Postleitzahlen alle davon > moeglicherweise die gleiche Koordinate haben - weil es die Koordinate des > Ortes ist und nicht die seiner Postleitzahlgebiete. Ueberlege also, was dich > wirklich interessiert. > > Eine Bitte am Rande: Zerfleddere nicht weiter die Threads hier indem du dir > neue Titel ausdenkst, sondern bleibe im gleichen Thread. Leute mit > vernuenftiger E-Mail-Software finden das weit uebersichtlicher. > From traut at gmx.de Fri Dec 7 14:39:15 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 7 Dec 2007 05:39:15 -0800 (PST) Subject: [opengeodb] =?utf-8?q?nochmal=3A_Alle_deutschen_Eintr=C3=A4ge_=28?= =?utf-8?q?mit_Code_von_Sven_Neuhaus=29?= In-Reply-To: <47594567.5060305@gmx.de> References: <47593249.7030509@gmx.de> <14211549.post@talk.nabble.com> <47594567.5060305@gmx.de> Message-ID: <14212679.post@talk.nabble.com> > Aber die Tabelle ist falsch! Nein, ist sie nicht. >Zu der Postleitzahl 20095 gehört nicht einfach nur Hamburg! Das behauptet auch niemand. Du scheinst aber zuzustimmen, dass umgekehrt, Hamburg zur PLZ 20095 gehoert? Die PLZ.tab enthaelt die Daten von PLZ-Gebieten. Ausrufezeichen. Das ist der Typ 100800000. Als Zusatzinfo zur PLZ 20095 gibt es dann einen mehr oder weniger repraesentativen Ortsnamen. Diese PLZ kann aber fuer einen speziellen Ortsteil stehen, vielleicht auch fuer mehrere. Ebenso kann sie fuer mehrere Orte gueltig sein. 100800000 nennt nicht alle davon, sondern nur genau einen. > Dazu gehört auch Hamburg-Altstadt und noch einige weitere Orte die zu > dieser Postleitzahl gehören und die sind nur in der opengeoDB zu finden! Genau deswegen schrieb ich ja: >> Beachte, dass bei einem Ort mit zehn Postleitzahlen alle davon >> moeglicherweise die gleiche Koordinate haben - weil es die Koordinate des >> Ortes ist und nicht die seiner Postleitzahlgebiete. Ueberlege also, was >> dich >> wirklich interessiert. Was also interessiert dich wirklich? PLZ-Gebiete sind deutsche Eintraege. Orte sind deutsche Eintraege. Solche Orte gibt es teils mit PLZ und teils ohne PLZ. Es gibt Orte mit "echter" und mit "reingerutschter" PLZ. Du verlangtest zuvor: < Habe heute mal den Code von Sven ausprobiert um mir alle deutschen Postleitzahlen ausgeben zu lassen. Das ist in mehrfacher Hinsicht falsch. Die PLZ.tab enthaelt am vollstaendigsten JEDE AKTUELLE DEUTSCHE Postleitzahl. Ist das verwunderlich, wenn man 100800000 will? Du scheinst aber tatsaechlich einfach jeden Ort zu wollen, zu dem es eine PLZ gibt? Dann musst du als erstes herausfinden, wie du die deutschen Orte auswaehlst. Das Thema hatten wir schon ein einem anderen Thread - und wenn du nicht weisst, wie das mit den Hierachies geht, dann nimm eben, wie erwaehnt, die D.sql Willst du dann anschliessend die Koordinaten des Ortes oder die seiner PLZ? Noch eine Bitte am Rande: Loesche Vollzitate, wenn du nicht explizit darauf eingehen magst. -- View this message in context: http://www.nabble.com/nochmal%3A-Alle-deutschen-Eintr%C3%A4ge-%28mit-Code-von-Sven-Neuhaus%29-tf4961642.html#a14212679 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From froschpopo at gmx.de Fri Dec 7 14:51:37 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 14:51:37 +0100 Subject: [opengeodb] =?iso-8859-1?q?nochmal=3A_Alle_deutschen_Eintr=E4ge_?= =?iso-8859-1?q?=28mit_Code_von_Sven_Neuhaus=29?= In-Reply-To: <14212679.post@talk.nabble.com> References: <47593249.7030509@gmx.de> <14211549.post@talk.nabble.com> <47594567.5060305@gmx.de> <14212679.post@talk.nabble.com> Message-ID: <47594FE9.2090209@gmx.de> Ich möchte soetwas machen wie bei Kwick.de angewandt wird, siehe hier: http://www.kwick.de/registrieren/ Gib dort mal die PLZ 20095 an, dann öffnet sich rechts ein Fenster, mit weiteren Auswahlmöglichkeiten: Hamburg, Hamburg/Klostertor, Hamburg/Sankt Georg, Hamburg/Hamburg-Altstadt. So will ich das haben, egal ob alle, wie du sagst, dieselben Koordinaten haben. Es geht mir um beides! Ich habe außerdem die Hoffnung, dass vielleicht irgendwann auch Koordinaten für die einzelnen Stadtteile verfügbar sind. Dann könnte ich nämlich sagen: Gut, dass ich so vorausschauend war und den Usern schon vorher ermöglicht habe, detailierte Angaben zu ihrem Wohnort zu machen. Ich wollte dich übrigens nicht vorhin so von der Seite anmachen, das kam schlecht rüber, wie ich an deiner Ausdrucksweise gelesen habe. LG, Lucas From froschpopo at gmx.de Fri Dec 7 15:41:01 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 15:41:01 +0100 Subject: [opengeodb] =?iso-8859-15?q?SELECT=3A_merkw=FCrdige_R=FCckkopplun?= =?iso-8859-15?q?g?= Message-ID: <47595B7D.9070901@gmx.de> Schaut euch mal das Ergebnis von diesem Select an: SELECT plz.text_val AS PLZ, ort.text_val AS Ort, co.lon, co.lat FROM geodb_textdata plz, geodb_textdata ort, geodb_coordinates co WHERE ( co.loc_id = plz.loc_id AND ort.loc_id = plz.loc_id AND ort.text_type = 500100000 AND plz.text_type = 500300000 ) LIMIT 60000 Merkwürdig oder? Erst wiederholt er den letzten Datensatz und dann verdreht er einmal die lon,-lat Koordinaten. Dabei will ich doch nur "PLZ, Ort, lon, lat" ausgeben :( From traut at gmx.de Fri Dec 7 16:31:31 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 7 Dec 2007 07:31:31 -0800 (PST) Subject: [opengeodb] =?utf-8?q?nochmal=3A_Alle_deutschen_Eintr=C3=A4ge_=28?= =?utf-8?q?mit_Code_von_Sven_Neuhaus=29?= In-Reply-To: <47594FE9.2090209@gmx.de> References: <47593249.7030509@gmx.de> <14211549.post@talk.nabble.com> <47594567.5060305@gmx.de> <14212679.post@talk.nabble.com> <47594FE9.2090209@gmx.de> Message-ID: <14214516.post@talk.nabble.com> > Gib dort mal die PLZ 20095 an, dann öffnet sich rechts ein Fenster, mit weiteren Auswahlmöglichkeiten: Das entspricht also: suche nach PLZ -> im Feld 500300000 nach 20095 Wenn du als Land dazu Deutschland ausgewaehlt hast, dann willst du das entsprechend auf nur deutsche Eintraege eingrenzen. > Hamburg, Hamburg/Klostertor, Hamburg/Sankt Georg, > Hamburg/Hamburg-Altstadt. Ausnahmsweise haben wir die Teile auch schon drin: http://fa-technik.adfc.de/code/opengeodb.pl?parts=17838;c=D > So will ich das haben, egal ob alle, wie du sagst, dieselben Koordinaten > haben. Dann brauchst du eben nicht die 100800000 sondern die 500300000 - und kannst dann entscheiden, ob du lieber die Koordinaten des Ortsteils verwendest oder die des zugehoerigen PLZ-Gebiets. > Ich habe außerdem die Hoffnung, dass vielleicht irgendwann auch > Koordinaten für die einzelnen Stadtteile verfügbar sind. im konkreten Fall sind sie das bereits. > Ich wollte dich übrigens nicht vorhin so von der Seite anmachen, das kam > schlecht rüber, wie ich an deiner Ausdrucksweise gelesen habe. Mein Ton wird wohl schaerfer, wenn jemand auf ungenaue Anfragen praezise Antworten einfordert. Schoenen Gruss Martin -- View this message in context: http://www.nabble.com/nochmal%3A-Alle-deutschen-Eintr%C3%A4ge-%28mit-Code-von-Sven-Neuhaus%29-tf4961642.html#a14214516 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From felix.schwarz at oss.schwarz.eu Fri Dec 7 16:58:11 2007 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Fri, 07 Dec 2007 16:58:11 +0100 Subject: [opengeodb] Fehler in PLZ.tab Message-ID: <47596D93.1080301@oss.schwarz.eu> Hallo, ich habe gerade entdeckt, dass die PLZ.tab auf dem adfc-Server nicht dem neuesten Stand entspricht. So fehlt dort z.B. die Plz 04178, während sie im Dump 026 prinzipiell enthalten ist. Daher würde ich mir gerne die Datei selbst neu erzeugen. Aber wie wird die Datei bislang generiert? Sind die Skripte öffentlich bzw. können Sie veröffentlicht werden? vielen Dank Felix Schwarz From froschpopo at gmx.de Fri Dec 7 17:13:17 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 17:13:17 +0100 Subject: [opengeodb] Fehler in PLZ.tab In-Reply-To: <47596D93.1080301@oss.schwarz.eu> References: <47596D93.1080301@oss.schwarz.eu> Message-ID: <4759711D.3060703@gmx.de> Hi Felix, Ich bin gerade auch dabei etwas ähnliches umzusetzen. Mein Ansatz: Aus allen Tabellen eine einzelne machen. SELECT ort.loc_id, plz.text_val AS PLZ, ort.text_val AS Ort, co.lon, co.lat FROM geodb_textdata ort, geodb_textdata plz, geodb_coordinates co WHERE ( co.loc_id = ort.loc_id AND ort.text_type = 500100000 AND plz.loc_id = ort.loc_id AND plz.text_type = 500300000 ) LIMIT 60000 Ist aber noch in der Entwicklungsphase. Ich würde aber gerne eure Meinungen dazu hören. Felix Schwarz schrieb: > Hallo, > > ich habe gerade entdeckt, dass die PLZ.tab auf dem adfc-Server nicht dem > neuesten Stand entspricht. So fehlt dort z.B. die Plz 04178, während sie > im Dump 026 prinzipiell enthalten ist. > > Daher würde ich mir gerne die Datei selbst neu erzeugen. Aber wie wird die > Datei bislang generiert? Sind die Skripte öffentlich bzw. können Sie > veröffentlicht werden? > > vielen Dank > Felix Schwarz > From froschpopo at gmx.de Fri Dec 7 17:30:55 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 17:30:55 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <4759711D.3060703@gmx.de> References: <47596D93.1080301@oss.schwarz.eu> <4759711D.3060703@gmx.de> Message-ID: <4759753F.6070602@gmx.de> Hallo Liste! Gibts eigentlich irgendwo eine Liste mit den Länderbezeichnungen? Also quasi ein Index, welche Kennzahl welches Land bezeichnet? From traut at gmx.de Fri Dec 7 17:35:21 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 7 Dec 2007 08:35:21 -0800 (PST) Subject: [opengeodb] Fehler in PLZ.tab In-Reply-To: <47596D93.1080301@oss.schwarz.eu> References: <47596D93.1080301@oss.schwarz.eu> Message-ID: <14215823.post@talk.nabble.com> Im Augenblick kann die PLZ.tab noch nicht bearbeitet werden. Derzeit arbeite ich daran, dass man ueberhaupt Zusatzdaten anlegen oder bearbeiten kann. Damit waere indirekt auch moeglich, durch Scripts die Daten in die PLZ.tab zu uebernehmen. Derartiges existiert bisher aber noch nicht und steht auch nicht weit oben auf der Prioritaetenliste. Von daher solltest du solche Aktualisierungen einfach ueber die Liste an mich schicken, dann werde ich sie haendisch einpflegen. Moeglicherweise werde ich auch mal einen Exportfilter einbauen, mit dem man sich die PLZ.tab zur PLZ.sql umwandeln lassen kann. Der Aufwand dafuer ist gering. Vorab moechte ich dann aber die Option anbieten, sich selbst einen aktuellen Dump erstellen lassen zu koennen. Da derzeit die Daten kaum von irgendwelchen Leuten gepflegt und aktualisiert werden (vgl. z.B. der bekannte Fehler, dass manche Laender noch nicht vom Land nach Europa verlinken), scheint die Nachfrage hier ohnehin nicht unbedingt riesig zu sein. Schoenen Gruss Martin -- View this message in context: http://www.nabble.com/Fehler-in-PLZ.tab-tf4962861.html#a14215823 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From froschpopo at gmx.de Fri Dec 7 18:28:39 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 18:28:39 +0100 Subject: [opengeodb] Falsche Koordinaten gefunden? In-Reply-To: <14215823.post@talk.nabble.com> References: <47596D93.1080301@oss.schwarz.eu> <14215823.post@talk.nabble.com> Message-ID: <475982C7.1090105@gmx.de> Hi, Schaut Euch mal die Koordinaten von folgender loc_id an: SELECT * FROM geodb_coordinates WHERE loc_id = 35887 Da stimmt doch was mit lon und lat nicht ! LG, Lucas From traut at gmx.de Fri Dec 7 18:51:46 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 07 Dec 2007 18:51:46 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= Message-ID: <20071207175146.23070@gmx.net> > Gibts eigentlich irgendwo eine Liste mit den Länderbezeichnungen? > Also quasi ein Index, welche Kennzahl welches Land bezeichnet? Definiere Kennzahl. Meinst du locids? Bisher haben wir nur sehr wenige Laender (level 2) Meinst du ISO Codes? Vergleiche http://sourceforge.net/docman/display_doc.php?docid=27436&group_id=132421 Meinst du ISO2-Codes? oder dreistellige Codes? Oder die Abkuerzungen der Laender auf den ovalen Fahrzeugaufklebern? http://www.rdate.com/country_alpha_iso.htm Womoeglich meinst du Telefonvorwahlen? -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail From traut at gmx.de Fri Dec 7 18:52:23 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 07 Dec 2007 18:52:23 +0100 Subject: [opengeodb] Falsche Koordinaten gefunden? Message-ID: <20071207175223.23070@gmx.net> > Schaut Euch mal die Koordinaten von folgender loc_id an: > > SELECT * FROM geodb_coordinates WHERE loc_id = 35887 > > Da stimmt doch was mit lon und lat nicht ! Geht das bitte etwas genauer? WAS stimmt mit lon und lat nicht? http://www.fa-technik.adfc.de/Codierung/opengeodb.pl?parts=536;c=D zeigt vergleichbare Werte fuer die anderen Gemeinden im Kreis. http://de.wikipedia.org/wiki/Falkenstein/Harz nennt http://tools.wikimedia.de/~magnus/geo/geohack.php?language=de¶ms=51_44_N_11_20_E_type:city(6187)_region:DE-ST Koordinaten Sexagesimal Dezimal Breite : 51° 44? 0? N 51.733333° Länge : 11° 20? 0? E 11.333333° Das sieht nicht so viel anders aus als lat: 51.7071428571428 lon: 11.3333285714286 -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail From froschpopo at gmx.de Fri Dec 7 18:56:30 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 18:56:30 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <20071207175146.23070@gmx.net> References: <20071207175146.23070@gmx.net> Message-ID: <4759894E.1030903@gmx.de> >>Definiere Kennzahl. SELECT * FROM geodb_textdata WHERE text_type = 400200000 GROUP BY text_val liefert mir: 124 106 60000 637 60001 35248 29237 60487 13813 From froschpopo at gmx.de Fri Dec 7 19:01:14 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 19:01:14 +0100 Subject: [opengeodb] Falsche Koordinaten gefunden? In-Reply-To: <20071207175223.23070@gmx.net> References: <20071207175223.23070@gmx.net> Message-ID: <47598A6A.5040801@gmx.de> >>Geht das bitte etwas genauer? WAS stimmt mit lon und lat nicht? Probiers doch mal selbst und gib mal ein: SELECT * FROM geodb_coordinates WHERE loc_id = 35887 Da bekomme ich folgendes heraus: lon | lat 11.33328571... 51.70714... 51.70714... 11.33328571... From traut at gmx.de Fri Dec 7 19:11:07 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 07 Dec 2007 19:11:07 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= Message-ID: <20071207181107.292870@gmx.net> Hallo Lucas, es ist mehr als ermuedend, dir zu antworten. Ist es fuer dich nicht moeglich, deine Anfrage etwas praeziser zu stellen oder genauer mit Fakten zu untermauern? > SELECT * FROM geodb_textdata WHERE text_type = 400200000 > GROUP BY text_val Du suchst also nach text_type = 400200000? Ich verwende kein SQL - du suchst also einfach nach der Ebene? Und dann? > liefert mir: > 124 > 106 > 60000 > 637 > 60001 > 35248 > 29237 > 60487 > 13813 Suche bitte auch die Zusatzinfos dazu heraus. 124: Burgenland, Ebene 3, Oesterreich 106: Oesterreich, Ebene 2 60000: Eisenstadt, Ebene 5, Deutschland 637: Antwerpen, Ebene 4, Niederlande ... Was du Kennzahl nennst, heisst in openeodb-SQL "loc_id". Solltest du in der naechsten Zeit keine Antworten mehr bekommen, dann ueberlege vielleicht erst einmal, was du wissen willst und ob du das so auch gefragt hast bzw. genuegend Vorleistung erbracht hast, um deine Frage zu unterfuettern. Gruss, Martin -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From traut at gmx.de Fri Dec 7 19:19:04 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 07 Dec 2007 19:19:04 +0100 Subject: [opengeodb] Falsche Koordinaten gefunden? Message-ID: <20071207181904.292860@gmx.net> > >>Geht das bitte etwas genauer? WAS stimmt mit lon und lat nicht? > > Probiers doch mal selbst und gib mal ein: Nein, das mache ich nicht - denn ich habe hier kein SQL. > SELECT * FROM geodb_coordinates WHERE loc_id = 35887 > > Da bekomme ich folgendes heraus: > > lon | lat > 11.33328571... 51.70714... > 51.70714... 11.33328571... Mit welcher Version arbeitest du? Die Angaben haettest du gleich machen koennen - und anstelle die Koordinaten einfach "falsch" zu nennen, haettest du auch gleich sagen koennen, dass lon und lat vertauscht wirken. ... denn dann haette ich dich gleich auf http://www.nabble.com/Welche-Daten-sind-die-aktuellsten--tf4936609.html verweisen koennen: in der 0.25-Version sind lat/lon teilweise vertauscht. Verwende daher 0.26. -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail From felix.schwarz at oss.schwarz.eu Fri Dec 7 20:27:34 2007 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Fri, 07 Dec 2007 20:27:34 +0100 Subject: [opengeodb] Fehler in PLZ.tab In-Reply-To: <14215823.post@talk.nabble.com> References: <47596D93.1080301@oss.schwarz.eu> <14215823.post@talk.nabble.com> Message-ID: <47599EA6.5030609@oss.schwarz.eu> Hallo Martin, zuerst einmal: Vielen Dank für deine scheinbar unermüdliche Arbeit an diesem Projekt. :-) Mir scheint, ohne dich müsste man OpenGeoDB als tot betrachten. Martin Trautmann schrieb: > Im Augenblick kann die PLZ.tab noch nicht bearbeitet werden. > > Derzeit arbeite ich daran, dass man ueberhaupt Zusatzdaten anlegen oder > bearbeiten kann. Damit waere indirekt auch moeglich, durch Scripts die Daten > in die PLZ.tab zu uebernehmen. Derartiges existiert bisher aber noch nicht > und steht auch nicht weit oben auf der Prioritaetenliste. Verzeih mir meine dumme Frage, aber ich habe noch nicht so richtig durchschaut, wie dieses Projekt funktioniert bzw. wie die Daten erzeugt werden. Ich nahm an, dass die PLZ.tab aus dem Hauptdatenbestand automatisch erzeugt werden. Offenbar ist das nicht so. Was fehlt genau, um diese Daten automatisch zu erzeugen? Viel freie Zeit habe ich zwar nicht, aber kleine Tasks können schon mal drin sein - an Programmierkenntnissen sollte es jedenfalls bei mir nicht scheitern. *g* > Da derzeit die Daten kaum von > irgendwelchen Leuten gepflegt und aktualisiert werden (vgl. z.B. der > bekannte Fehler, dass manche Laender noch nicht vom Land nach Europa > verlinken), scheint die Nachfrage hier ohnehin nicht unbedingt riesig zu > sein. Noch eine Frage: Wo kann bzw. soll ich denn überhaupt etwas bearbeiten? Wann sollte ich etwas bearbeiten? Welche Sicherheitsmechanismen gibt es, falls ich etwas falsch mache? Gruß, -- Felix Schwarz Software-Entwicklung und Beratung Schwerpunkt: Entwicklung auf "Open Source"-Basis www.schwarz.eu From froschpopo at gmx.de Fri Dec 7 20:38:12 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 20:38:12 +0100 Subject: [opengeodb] Fehler in PLZ.tab In-Reply-To: <47599EA6.5030609@oss.schwarz.eu> References: <47596D93.1080301@oss.schwarz.eu> <14215823.post@talk.nabble.com> <47599EA6.5030609@oss.schwarz.eu> Message-ID: <4759A124.4030805@gmx.de> Ich bin verwundert, weil riesige Seiten, selbst die größten Communities wie kwick.de scheinen diese Datenbank zu nutzen. Habe mir nämlich mal die Mühe gemacht und den Quelltext solcher Seiten durchstöbert und stoße dort immer wieder in den HTMl-Formularen auf die loc_id's von openGeoDB > Hallo Martin, > > zuerst einmal: Vielen Dank für deine scheinbar unermüdliche Arbeit an diesem > Projekt. :-) Mir scheint, ohne dich müsste man OpenGeoDB als tot betrachten. > ... From froschpopo at gmx.de Fri Dec 7 20:42:11 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 20:42:11 +0100 Subject: [opengeodb] Falsche Koordinaten gefunden? In-Reply-To: <20071207181904.292860@gmx.net> References: <20071207181904.292860@gmx.net> Message-ID: <4759A213.6000900@gmx.de> Hi, vielen Dank für den Link. Dann lösche ich einfach alle Datensätze wo: valid_until < heute das wären dann 18 Stk. From froschpopo at gmx.de Fri Dec 7 20:44:43 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 20:44:43 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <20071207181107.292870@gmx.net> References: <20071207181107.292870@gmx.net> Message-ID: <4759A2AB.8040004@gmx.de> Dann möchte ich deutlicher Fragen: Enthält NUR Ebene 5 deutsche Einträge und zwar auschließlich? From traut at gmx.de Fri Dec 7 21:16:14 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 07 Dec 2007 21:16:14 +0100 Subject: [opengeodb] Fehler in PLZ.tab In-Reply-To: <47599EA6.5030609@oss.schwarz.eu> References: <47596D93.1080301@oss.schwarz.eu> <14215823.post@talk.nabble.com> <47599EA6.5030609@oss.schwarz.eu> Message-ID: <4759AA0E.8070501@gmx.de> Felix Schwarz wrote: > Hallo Martin, > > zuerst einmal: Vielen Dank für deine scheinbar unermüdliche Arbeit an diesem > Projekt. :-) Mir scheint, ohne dich müsste man OpenGeoDB als tot betrachten. Der Anschub kam nicht von mir - es ist auch nicht sicher, ob und wie andere mal wieder tragende Rollen übernehmen. > Verzeih mir meine dumme Frage, aber ich habe noch nicht so richtig durchschaut, > wie dieses Projekt funktioniert bzw. wie die Daten erzeugt werden. Das ist auch nicht unbedingt trivial, weil einiges sich entwickelt hat und opengeodb im Prinzip sehr unterschiedliche Dinge kann. > Ich nahm an, > dass die PLZ.tab aus dem Hauptdatenbestand automatisch erzeugt werden. Die PLZ.tab entstammt tatsaechlich dem Datenbestand aus der 0.2.4, mit ein paar späteren Ergänzungen. Seit der Version hat sich aber einiges getan. Einerseits wurde die Datenstruktur etwas erweitert. Andererseits kam eine Wiki-ähnliche Versionierung dazu. Bedingt durch technische Randbedingungen meiner Implementierung läuft das ganze aber nicht auf einer echten SQL-Datenbank, sonder auf deutlich kleineren und recht effizienten Text-Dateien. opengeodb selbst, das sind primaer erst mal Rohdaten. SQL ist ein geeignetes Transportvehikel dafür. Früher gab es statt des SQL auch eine daraus abgeleitete .txt-Version, die meinen Zwecken weitgehend genügte. Meine eigene Datenhaltung arbeitet gänzlich anders (FileMaker). So entstand dann aber der aktuelle Zwischenstand, der primär aktuelle Basisdaten darstellt (D.tab usw.). Dazu gibt es versionierte Daten - also einerseits solche, die durch andere Typen über die Basisdaten hinausgehen. Andererseits aber auch solche, die z.B. mit Erstellungs- und Gültigkeitsdatum daherkommen. Solche Daten werden derzeit tatsächlich als SQL-Daten gehandhabt: extra.sql. Weder .txt noch.sql wird aber bei einer Web-Anbfrage angezeigt: dort erfolgt die Umwandlung nach .html Bei vielen opengeodb-Anwendern zeigt sich eigentlich, dass sie überwiegend keine Ortsdaten wollen, sondern eine recht einfache Applikation brauchen, um Umkreis- und Entfernungssuchen zu verwenden. Solchen Leuten reicht eigentlich der Bestand aus der PLZ.tab In der eigentlichen Struktur der opengeodb sind die PLZ-Gebiete eine Art von Fremdkörper. Für den aktuellen Entwicklungsstand sind diese also kein Teil der dumps. Je nach Wunsch und Motivation werde ich sie vielleicht wieder mit hineinnehmen. Dennoch finden sich in opengeodb derzeit solche Daten: sie sind deshalb drin, weil sie mit einem Gültigkeitsdatum markiert sind, das hinter dem Einführungsdatum der fünstelligen Postleitzahlen liegt. Deswegen stecken sie in extra.sql noch drin. > Offenbar ist das nicht so. Was fehlt genau, um diese Daten automatisch zu > erzeugen? Der Wille. > Viel freie Zeit habe ich zwar nicht, aber kleine Tasks können schon > mal drin sein - an Programmierkenntnissen sollte es jedenfalls bei mir nicht > scheitern. *g* Dann überlege vielleicht einfach, in welcher Form dir die Ausgabe besser gefallen würde bzw. was du da gerne hättest. Ich kann mir z.B. gut vorstellen, hier einen Google-Map-Frame mit einzubinden. Irgendwo gibt es eine Applikation der opengeodb- und nima-Daten, wie man auf den Satellitenbildern die aktuellen Koordinaten einblenden lassen kann - und wie man die Punkte dann einfach an die richtige Stelle verschiebt und deren Wert dann als korrigierte Koordinaten wieder in den Datenbestand aufnimmt. >> Da derzeit die Daten kaum von >> irgendwelchen Leuten gepflegt und aktualisiert werden (vgl. z.B. der >> bekannte Fehler, dass manche Laender noch nicht vom Land nach Europa >> verlinken), scheint die Nachfrage hier ohnehin nicht unbedingt riesig zu >> sein. > > Noch eine Frage: Wo kann bzw. soll ich denn überhaupt etwas bearbeiten? Wann > sollte ich etwas bearbeiten? Jeder kann jederzeit die Basisdaten auf fa-technik.adfc.de/code/opengeodb.pl bearbeiten. Wer groessere Datenbestaende einpflegen mag, der kann sich die entsprechende HTML-Syntax leicht erraten, wie man das einspielen kann. Wesentliche Hilfe wäre also, dass online oder offline die Bestände geprüft und erkannte Fehler korrigiert werden - das kann jeder, hoffentlich auch ohne Programmierkenntnisse. > Welche Sicherheitsmechanismen gibt es, falls ich > etwas falsch mache? Keine, du darfst machen, was du willst ;-) Jede Änderung wird aber mitprotokolliert und kann von jedermann rückgängig gemacht werden. Änderungen werden auch direkt beim Eintrag angezeigt. Der Mechanismus ist noch nicht perfekt, aber IMHO tauglich. Wer mir Fehler des Programms meldet, der hat bessere Chancen, dass diese behoben werden, als wer nichts macht. Schönen Gruß Martin From traut at gmx.de Fri Dec 7 21:22:46 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 07 Dec 2007 21:22:46 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <4759A2AB.8040004@gmx.de> References: <20071207181107.292870@gmx.net> <4759A2AB.8040004@gmx.de> Message-ID: <4759AB96.2010905@gmx.de> Lucas Mengel wrote: > Dann möchte ich deutlicher Fragen: > > Enthält NUR Ebene 5 deutsche Einträge und zwar auschließlich? Ebene 5 ist die Landkreis-Ebene. In Österreich war diese Zuordnung vor kurzem noch anders. Seit release 0.26 wird Ebene 5 aber für die österreicher Bezirke verwendet. In der Schweiz sind die Bezirke derzeit als Ebene 4 eingestuft. Es wäre denkbar, hier entweder die österreicher Bezirke eine Ebene nach oben zu schieben oder die Schweiser eine nach unten. Die "richtige" Zuordnung ist IMHO nicht möglich, da von Land zu Land, von Bundesland zu Bundesland unterschiedliche Strukturen der Ebenen existieren. Von daher kann ich dir nicht garantieren, dass 5 nur deutsche Kreise enthalten würde - derzeit ist dem jedenfalls nicht mehr so. Schönen Gruß Martin From froschpopo at gmx.de Fri Dec 7 22:57:28 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Fri, 07 Dec 2007 22:57:28 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <4759AB96.2010905@gmx.de> References: <20071207181107.292870@gmx.net> <4759A2AB.8040004@gmx.de> <4759AB96.2010905@gmx.de> Message-ID: <4759C1C8.3020100@gmx.de> Du hast ja immer gesagt, ich soll, wenn ich Informationen über das LAND haben will, alle Ebenen durchgehen. Habe jetzt alle probiert: Zuerst habe ich mich vergewissert, welche Ebenen es gibt: SELECT loc_id FROM geodb_textdata WHERE text_type = 4002000000 GROUP BY text_val Das Ergebnis lautet: loc_id | text_val 124 | 1 106 | 2 60000 | 3 637 | 4 60001 | 5 35248 | 6 29237 | 7 60487 | 8 13813 | 9 Es sind 9 Ebenen, wie Martin immer gesagt hat. Nun kommen ganz deutliche Fragen, wie von Martin gefordert: Frage Nr.:1. Du erwähnst immer wieder die loc_id 105. Du sagst immer, ich soll mir anhand dieser loc_id Informationen besorgen. Woher hast du diese Zahl? Nächster Schritt: Wenn ich die loc_id's aus dem obigen Abfrageergebnis nehme und nach ihnen in geodb_textdata suche, da erhalte ich Informationen zu der jeweiligen Ebene. Frage Nr.: 2. Was soll ich mit den Informationen anfangen? Die Ebenen sind alle von Grund auf verschieden! WAS meintest du in diesem Zusammenhang mit "Abklappern" ?? From traut at gmx.de Fri Dec 7 23:41:41 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 07 Dec 2007 23:41:41 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <4759C1C8.3020100@gmx.de> References: <20071207181107.292870@gmx.net> <4759A2AB.8040004@gmx.de> <4759AB96.2010905@gmx.de> <4759C1C8.3020100@gmx.de> Message-ID: <4759CC25.7050309@gmx.de> Lucas Mengel wrote: > Frage Nr.:1. Du erwähnst immer wieder die loc_id 105. Du sagst immer, > ich soll mir anhand dieser loc_id Informationen besorgen. > Woher hast du diese Zahl? Warum weisst du das nicht? Kannst du nicht herausfinden, wofür die loc_id 105 steht? Es ist Deutschland - dein Aufhänger für alle deutschen Einträge. > Nächster Schritt: Wenn ich die loc_id's aus dem obigen Abfrageergebnis > nehme und nach ihnen in geodb_textdata suche, da > erhalte ich Informationen zu der jeweiligen Ebene. > > Frage Nr.: 2. Was soll ich mit den Informationen anfangen? Die Ebenen > sind alle von Grund auf verschieden! > WAS meintest du in diesem Zusammenhang mit "Abklappern" ?? Suche nach allem, was in 400100000 ein 105 enthält und in 400200000 eine 3. Damit solltest du anfangen, deine Hierarchies zu erstellen und aufzufüllen. Schönen Gruß Martin From robert.boeck at googlemail.com Fri Dec 7 23:53:31 2007 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Fri, 07 Dec 2007 23:53:31 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <20071207181107.292870@gmx.net> References: <20071207181107.292870@gmx.net> Message-ID: Hallo Martin, Martin Trautmann wrote: > es ist mehr als ermuedend, dir zu antworten. Ist es fuer dich nicht moeglich, deine Anfrage etwas praeziser zu stellen oder genauer mit Fakten zu untermauern? > >> SELECT * FROM geodb_textdata WHERE text_type = 400200000 >> GROUP BY text_val > > Du suchst also nach text_type = 400200000? Ich verwende kein SQL - du suchst also einfach nach der Ebene? Und dann? Ehrlich gesagt - die SQL-Datenstruktur ist eine einzige Katastrophe. Von Normalisierung keine Spur. Da blickt doch kaum jemand durch. Und du wunderst dich, dass dann unpräzise Fragen kommen. Mich wundert das überhaupt nicht. Ich glaube, Lucas blickt blickt da einfach nicht so richtig durch und wird jetzt deswegen von dir blöd angemacht. cu, Robo :) From perl at rainboxx.de Sat Dec 8 00:12:52 2007 From: perl at rainboxx.de (Matthias Dietrich) Date: Sat, 08 Dec 2007 00:12:52 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: References: <20071207181107.292870@gmx.net> Message-ID: <4759D374.4080501@rainboxx.de> Hi, ich misch mich mal ganz kurz ein... > Ehrlich gesagt - die SQL-Datenstruktur ist eine einzige Katastrophe. Von > Normalisierung keine Spur. Da blickt doch kaum jemand durch. Da muss ich dir absolut Recht geben, Robert! > Und du wunderst dich, dass dann unpräzise Fragen kommen. Mich wundert das > überhaupt nicht. So wie ich das sehe, kann Martin allerdings gar nichts für diese Struktur. Die hatte er ja einfach nur übernommen. Ich hatte damit auch schon meine Schwierigkeiten, und habe es soweit durch dringen können, wie ich es bisher gebraucht habe. Dennoch möchte ich irgendwann die Daten für meine Zwecke neu ordnen, damit die Suche nicht so ewig dauert. Dabei habe ich mir auch schon überlegt, dass man gemeinsam eine komplette und sinnvolle Architektur für das ganze finden. Allerdings hatte ich dazu noch keine Zeit. Aber wenn sich ein paar finden, die da mitmachen würden, könnte man sich schonmal vorab per Liste unterhalten und mit dem Definieren beginnen. Gruß, Matthias From perl at rainboxx.de Sat Dec 8 00:20:57 2007 From: perl at rainboxx.de (Matthias Dietrich) Date: Sat, 08 Dec 2007 00:20:57 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <4759D374.4080501@rainboxx.de> References: <20071207181107.292870@gmx.net> <4759D374.4080501@rainboxx.de> Message-ID: <4759D559.2050507@rainboxx.de> Uarks! Matthias Dietrich schrieb: > [... schlechtes Deutschsprech ...] Sorry, ich bin wohl schon ein wenig müde. Ich hoffe, man kann verstehen, was ich eigentlich meine ;). Viele Grüße, Matthias From traut at gmx.de Sat Dec 8 00:24:32 2007 From: traut at gmx.de (Martin Trautmann) Date: Sat, 08 Dec 2007 00:24:32 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: References: <20071207181107.292870@gmx.net> Message-ID: <4759D630.6090401@gmx.de> Robert Böck wrote: > Ehrlich gesagt - die SQL-Datenstruktur ist eine einzige Katastrophe. Ich finde auch, dass die recht unuebersichtlich ist - deswegen verwende ich selbst sie ja auch nicht, deswegen gibt es auch IMHO sehr übersichtliche .txt-Varianten. Der Teil auf der Liste hier ist aber nur ein kleiner Teil der Geschichte (vgl. Sourceforge-Foren) - und wenn man Antworten will, dann sollte man sich auch bei den Fragen etwas Muehe geben. Wenn er SQL verwenden will, sein Problem. Vorauszusetzen, dass jeder andere weiss, was SEINE Befehle auf SEINER Version der Daten in SEINER SQL-Umgebung ergeben, erscheint mir etwas zu abgehoben. Ich kann aber auch einfach die Klappe halten und mir die Arbeit der Antworten sparen. Hilfst du ihm bitte weiter? Danke, Martin From robert.boeck at googlemail.com Sat Dec 8 00:50:09 2007 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Sat, 08 Dec 2007 00:50:09 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <4759D374.4080501@rainboxx.de> References: <20071207181107.292870@gmx.net> <4759D374.4080501@rainboxx.de> Message-ID: Hallo Matthias, Matthias Dietrich wrote: > ich misch mich mal ganz kurz ein... Gerne doch! >> Ehrlich gesagt - die SQL-Datenstruktur ist eine einzige Katastrophe. Von >> Normalisierung keine Spur. Da blickt doch kaum jemand durch. > > Da muss ich dir absolut Recht geben, Robert! Mal ein kleines Beispiel. Ich habe mir vor längerer Zeit mal eine Abfrage gestrickt, die alle Orte in Bayern ausspuckt, inklusive Geokoordinaten, KFZ-Kennzeichen und Landkreis-Zugehörigkeit: SELECT ort.loc_id as l_ort, ort.text_val as t_ort, coord.lon as lon, coord.lat as lat, kfz.text_val as t_kfz, hi.id_lvl5 as lkr_id FROM geodb_hierarchies hi, geodb_textdata land, geodb_textdata ort, geodb_textdata bundesland, geodb_textdata kfz, geodb_coordinates coord, geodb_locations loc WHERE hi.id_lvl2=land.loc_id AND land.text_val='DE' AND land.text_type=500100001 AND hi.id_lvl3=bundesland.loc_id AND bundesland.text_val='BY' AND bundesland.text_type=500100001 AND ort.loc_id=hi.loc_id AND ort.text_type=500100000 AND hi.loc_id=hi.id_lvl6 AND loc.loc_id=hi.loc_id AND loc.loc_type=100700000 AND coord.loc_id=hi.loc_id AND kfz.loc_id=hi.loc_id AND kfz.text_type=500500000 ORDER BY l_ort Um jetzt eine Liste der Landkreise in Bayern rauszubekommen, um die Orte selbigen zuordnen zu können, braucht es immerhin noch diese Abfrage: SELECT ort.loc_id as l_ort, ort.text_val as t_ort, hi.id_lvl4 as rbez_id FROM geodb_hierarchies hi, geodb_textdata land, geodb_textdata ort, geodb_textdata bundesland WHERE hi.id_lvl2=land.loc_id AND land.text_val='DE' AND land.text_type=500100001 AND hi.id_lvl3=bundesland.loc_id AND bundesland.text_val='BY' AND bundesland.text_type=500100001 AND ort.loc_id = hi.loc_id AND ort.text_type = 500100000 AND hi.loc_id=hi.id_lvl5 ORDER BY l_ort Die Abfrage, um eine Liste der Regierungsbezirke in Bayern rauszubekommen, um die Landkreise selbigen zuordnen zu können, ist nicht minder kompliziert: SELECT ort.loc_id as l_ort, ort.text_val as t_ort FROM geodb_hierarchies hi, geodb_textdata land, geodb_textdata ort, geodb_textdata bundesland WHERE hi.id_lvl2=land.loc_id AND land.text_val='DE' AND land.text_type=500100001 AND hi.id_lvl3=bundesland.loc_id AND bundesland.text_val='BY' AND bundesland.text_type=500100001 AND ort.loc_id = hi.loc_id AND ort.text_type = 500100000 AND hi.loc_id=hi.id_lvl4 ORDER BY l_ort Und da frage ich mich: Wer bitteschön soll da durchblicken? Ich habe mir das mal vor einem guten Jahr zusammengepfriemelt, und heute blicke ich da selbst auch nicht mehr durch ... >> Und du wunderst dich, dass dann unpräzise Fragen kommen. Mich wundert das >> überhaupt nicht. > > So wie ich das sehe, kann Martin allerdings gar nichts für diese > Struktur. Die hatte er ja einfach nur übernommen. Und da hast _du_ vollkommen recht. Das ist auch keine Kritik gegenüber Martin, sondern eine Feststellung. Was ich allerdings an Martin kritisiere, ist, dass er Leute schwach anmacht, die aufgrund der Tatsache, dass die Datenstruktur unübersichtlich ist, ganz offensichtlich einfach nicht richtig durchblicken. > Ich hatte damit auch > schon meine Schwierigkeiten, und habe es soweit durch dringen können, > wie ich es bisher gebraucht habe. Dennoch möchte ich irgendwann die > Daten für meine Zwecke neu ordnen, damit die Suche nicht so ewig dauert. > > Dabei habe ich mir auch schon überlegt, dass man gemeinsam eine > komplette und sinnvolle Architektur für das ganze finden. Allerdings > hatte ich dazu noch keine Zeit. Aber wenn sich ein paar finden, die da > mitmachen würden, könnte man sich schonmal vorab per Liste unterhalten > und mit dem Definieren beginnen. Dein Wort in Gottes Gehörgang. Allerdings mangelt es mir auch an Zeit ... cu, Robo :) From traut at gmx.de Sat Dec 8 01:06:10 2007 From: traut at gmx.de (Martin Trautmann) Date: Sat, 08 Dec 2007 01:06:10 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: References: <20071207181107.292870@gmx.net> <4759D374.4080501@rainboxx.de> Message-ID: <4759DFF2.8020402@gmx.de> Robert Böck wrote: > Mal ein kleines Beispiel. Ich habe mir vor längerer Zeit mal eine > Abfrage gestrickt, die alle Orte in Bayern ausspuckt, inklusive > Geokoordinaten, KFZ-Kennzeichen und Landkreis-Zugehörigkeit: Die einfache Lösung: Suche nach allen Orten, bei denen der Gemeindeschlüssel mit 09 beginnt - so mache ich das. Schönen Gruß Martin From robert.boeck at googlemail.com Sat Dec 8 01:16:57 2007 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Sat, 08 Dec 2007 01:16:57 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <4759D630.6090401@gmx.de> References: <20071207181107.292870@gmx.net> <4759D630.6090401@gmx.de> Message-ID: Hallo Martin, Martin Trautmann wrote: >> Ehrlich gesagt - die SQL-Datenstruktur ist eine einzige Katastrophe. > Ich finde auch, dass die recht unuebersichtlich ist - deswegen verwende > ich selbst sie ja auch nicht, deswegen gibt es auch IMHO sehr > übersichtliche .txt-Varianten. Natürlich, die OpenGeoDB ist Open Source, und jeder kann - im Rahmen der Lizenz - damit machen, was er will. Und wenn du dich entschieden hast, die OpenGeoDB in Form von Textdateien weiterzupflegen, ist das deine freie Entscheidung. Das Problem ist aber, dass die OpenGeoDB früher als SQL-Dump verteilt wurde, und dass es sicher viele Anwendungen gibt, die mit der SQL-Version umgehen können, nicht aber mit den Textdateien. Und das Problem ist, dass in der aktuellen SQL-Distribution Tabellen fehlen, ohne die früher gebaute SQL-Statements nicht funktionieren. Und ganz offensichtlich gibt es auch viele Leute, die die OpenGeoDB gerne in Form einer SQL-Datenbank verwenden möchten. > Der Teil auf der Liste hier ist aber nur ein kleiner Teil der Geschichte > (vgl. Sourceforge-Foren) - und wenn man Antworten will, dann sollte man > sich auch bei den Fragen etwas Muehe geben. > > Wenn er SQL verwenden will, sein Problem. Also bitte! Eine relationale Datenbank ist das Mittel der Wahl, um solche Datenbestände zu verwalten. Und damit wären wir bei SQL ... Und wenn ich eine irgendeine Abfrage machen will, muss ich im einfachsten Fall einfach nur einen SQL-Befehl in die SQL-Konsole eintippen. Bei Textdateien muss ich mir schon ein Script stricken ... > Vorauszusetzen, dass jeder > andere weiss, was SEINE Befehle auf SEINER Version der Daten in SEINER > SQL-Umgebung ergeben, erscheint mir etwas zu abgehoben. Was heißt SEINE Version? Wenn man, wovon in den meisten Fällen auszugehen ist, die Version benutzt, die zum Download angeboten wird, dann ist es eine klar definierte Version, und nicht SEINE Version ... > Ich kann aber auch einfach die Klappe halten und mir die Arbeit der > Antworten sparen. Hilfst du ihm bitte weiter? Sorry, ich kann da nicht weiterhelfen, weil ich mich mit der SQL-Katastrophe schon seit über einem Jahr nicht mehr auseinandergesetzt habe und mit den Textdateien noch nie. cu, Robo :) From robert.boeck at googlemail.com Sat Dec 8 01:23:50 2007 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Sat, 08 Dec 2007 01:23:50 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <4759DFF2.8020402@gmx.de> References: <20071207181107.292870@gmx.net> <4759D374.4080501@rainboxx.de> <4759DFF2.8020402@gmx.de> Message-ID: Hallo Martin, Martin Trautmann wrote: >> Mal ein kleines Beispiel. Ich habe mir vor längerer Zeit mal eine >> Abfrage gestrickt, die alle Orte in Bayern ausspuckt, inklusive >> Geokoordinaten, KFZ-Kennzeichen und Landkreis-Zugehörigkeit: > Die einfache Lösung: Suche nach allen Orten, bei denen der > Gemeindeschlüssel mit 09 beginnt - so mache ich das. Oha! Dazu muss man aber erst mal wissen, dass man das so machen kann. Ich wusste es bisher nicht. Woher soll man das denn wissen? Und wenn man es nicht sowieso weiß, dann wird man sich wohl kaum auf die Suche nach dieser Information machen (können). Meine Idee seinerzeit war halt, alle klar ersichtlichen Informationen aus der Datenbank so zu verknüpfen, dass das übrigbleibt, was man gerne haben möchte ... cu, Robo :) From froschpopo at gmx.de Sat Dec 8 06:48:12 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Sat, 08 Dec 2007 06:48:12 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <4759CC25.7050309@gmx.de> References: <20071207181107.292870@gmx.net> <4759A2AB.8040004@gmx.de> <4759AB96.2010905@gmx.de> <4759C1C8.3020100@gmx.de> <4759CC25.7050309@gmx.de> Message-ID: <475A301C.30509@gmx.de> >>Warum weisst du das nicht? Kannst du nicht herausfinden, wofür die loc_id 105 steht? Es ist Deutschland - dein Aufhänger für alle deutschen Hi Martin! Vorab: Ich bin für JEDE, absolut JEDE, Hilfe von dir sehr Dankbar. Mein Problem ist teilweise auch, dass ich von dir Zahlen erfahre, die für mich nicht nachvollziehbar sind, so wie 105. Ich mache mir die ganze Zeit meine Gedanken darüber, wie du zwischen zig-tausend Zahlen gerade auf 105 gekommen bist bzw. welchen Weg du gegangen bist, um diese Zahl ausfindig zu machen. Was genau 105 bedeutet weiss ich schon, seitdem du es im Forum geschrieben hast. Aber wie hast du das herausbekommen? >>Suche nach allem, was in 400100000 ein 105 enthält und in 400200000 eine 3. Damit solltest du anfangen, deine Hierarchies zu erstellen. Warum nicht gleich: "Um alle deutschen Städte/Infos zu ermitteln, brauchst du erstmal alle deutschen Bundesländer." Ok, die habe ich jetzt. Ich habe mir selbstverständlich auch die Datensätze angeschaut, die sich hinter den loc_id's der Bundesländer verbergen. 1. Die loc_id 117 steht z.B. für Nordrhein-Westfalen. 2. loc_id 14634 ist eine Stadt in Nordrhein-Westfalen, nämlich Bochum. 3. ich habe festgestellt, dass 117 und 14634 eine Gemeinsamkeit haben: 5006000000 (in 14634 die ersten beiden Stellen). Soweit bin ich nun. Was folgt weiter? LG, Lucas From froschpopo at gmx.de Sat Dec 8 07:14:56 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Sat, 08 Dec 2007 07:14:56 +0100 Subject: [opengeodb] =?iso-8859-1?q?SQL_und_andere_Grunds=E4tze?= In-Reply-To: <4759AA0E.8070501@gmx.de> References: <47596D93.1080301@oss.schwarz.eu> <14215823.post@talk.nabble.com> <47599EA6.5030609@oss.schwarz.eu> <4759AA0E.8070501@gmx.de> Message-ID: <475A3660.8060406@gmx.de> Nebenbei: Was habt ihr eigentlich gegen SQL? SQL ist die Standard-Abfrage-Sprache für Datenbanken. Das hat eigentlich nichts mit Struktur oder so zu tun. Es ist doch wurst ob man mit SQL eine einfache CSV-Datei, oder eine komplexe Datenbank wie Oracle oder mySQL abfragt. Und jetzt zur Sache: Ich habe kürzlich mal im Internet recherchiert, wer alles die openGeoDB einsetzt. Das habe ich herausgefunden, indem ich mir den Quelltext der HTML-Seiten angesehen habe. Dort tauchen selbst in den größten deutschen Communities die aus der openGeoDB bekannten loc_id's auf. Mir ist danach bewusst geworden, dass ich das Ausmaß der openGeoDB völlig unterschätzt habe. Diese Datenbank wird in zig-tausend Plattformen, überwiegend Flirt und Social-Networks (web2.0-Seiten) mit teilweise ettlichen Millionen von Mitgliedern eingesetzt. Nach Stichproben der größten deutschen Communities komme ich zu dem Fazit, dass ca. 50 Millionen deutsche Nutzer auf die openGeoDB vertrauen. In der Praxis ist die Anwendung fast immer identisch: User geben über ein Web-Interface ihre Postleitzahl an, woraufhin in einem für sie reservierten Datensatz die Koordinaten und weitere Informationen aus der openGeoDB gespeichert werden. Nun das entscheidende: Damit später eine wirklich effiziente Umkreissuche entstehen kann müssen die Koordinaten in der User-Datenbank der jeweiligen Community/Anwendung gespeichert werden. Ich glaube kaum, dass irgendeine dieser Plattformen bei jeder Suchanfrage dieses beknackte Ebenen-Modull durchläuft. Ganz im Gegenteil: Die Betreiber solcher Seiten zerlegen die openGeoDB in ihre Einzelteile und zwar solang, bis sie exakt ihrem Anspruch entspricht. Ich stelle außerdem einfach mal folgende Behauptung in den Raum: Wer in der Lage ist, komplexe Umkreissuchen und Entfernungeberechnungen umzusetzen, der ist auch in der Lage, eine eigene Architektur zu entwickeln, die sich jeweils an den örtlichen Gegebenheiten orientiert. Anders formuliert: Wer eine Community basteln kann, der hat seine eigenen Datenbankstrukturen und wenn er irgendetwas nicht braucht, dann ist das ein Fremdkörper im eigenen System. Ich bin nach wie vor der Meinung, man sollte einfach eine einzelne SQL-Tabelle ausliefern und den Rest den Leuten überlassen. Darunter sind hochbezahlte und qualifizierte Programmmierer, die dem jeweiligen Betreiber eine maßgeschneiderte Lösung in sein vorhandenes System implentieren. LG, Lucas From georg at familieverweyen.de Sat Dec 8 07:18:10 2007 From: georg at familieverweyen.de (Georg V.) Date: Sat, 8 Dec 2007 07:18:10 +0100 Subject: [opengeodb] Aufregung in der Liste Message-ID: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> Also, ich habe hier innerhalb von kürzester Zeit 34 ungelesene Mails auf der Liste. Inhaltlich gemischt mit Aufregungen über Datenfehler, Aussagen über Datenstrukturen und Diskussionen über Weiterpflege sowie schärfer werdenen Formulierungen. Was die OpenGeoDB war (und hoffentlich auch noch ist) ist eine freie(*) Datenbank über Hierarchien (politische und postalische) Strukturen mit einer zeitlichen Dimension. Angeboten wurde sie in drei Lieferformen (Postgres, MySQL und Textfiles; die Aufsplittungen zur einfachen Beladung in einem gehosteten Server nicht mitgerechnet). Hierarchien abzufragen ist -egal welches Datenmodell und Datenhaltung man wählt- komplex. Einige brauchen drei Abfragen, die anderen nutzen ein Wissen über die Struktur von Gemeindeschlüsseln (was aber vorraussetzt, das diese Daten immer gepflegt sind). Wenn sich einer die Mühe macht, das Thema für seine Zwecke voran zutreiben, ist es lobenswert, aber man muss sich auch fragen, ob die Gründe passen. Strassen (mathematisch gesehen Linien) passen nun mal schlecht zu Bundesländer und Orten (Flächen bzw. Punkte), auch wenn sie beide nur im 2 dimensionalen Raum betrachtet werden. Das Datenmodell zu ändern und dabei Informationen (nicht nur über die Zeitachse) bereitwillig wegzuwerfen, kann und darf ebenfalls zu Recht kritisiert werden. Wie jeder damit umgeht, ist seine persönliche Sache. Man kann * versuchen seine Software anzupassen, * beim alten Datenmodell verbleiben oder * konstruktive(!) Vorschläge für Verbesserung einbringen. Alternativen wie Aufbau eines Pflegetools auf MySQL-Basis entfallen, da man dann nur eine Paralleldatenhaltung erzeugen würde. Ich persönlich werde in der nächsten Zeit mal eine Idee zu Wiederherstellung der Hierarchie prüfen und sie bei bestandenen Test entsprechend kommunizieren. Des weiteren werden ich auf meine lokalen Server mit dem Thema Differenzlieferungen beschäftigen. Für die Liste würde ich mir wünschen, dass wir ebenfalls wieder zu einer sachlichen Diskussion zur möglichen Weiterentwicklung * binden wir Umriss-Informationen (s. Mail von Tobias Wendorff) * weitere geografische Länder (s. Wikipedia) * weitere politische Strukturen (z.B. die EU) und den möglichen Lösungen kommen! Und eventuell kann sich eine(r) auch um das Thema FAQ/Wiki kümmern, damit die Liste nicht zur persönlichen Fragestunde verkommt. Mit freundlichen Grüßen Georg V. (*) Bitte erspart uns die Diskussion, unter welchem Lizenzmodell die OpenGeoDB jetzt genau steht, sie ist im Archiv nachzulesen. From froschpopo at gmx.de Sat Dec 8 07:19:31 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Sat, 08 Dec 2007 07:19:31 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: References: <20071207181107.292870@gmx.net> <4759D630.6090401@gmx.de> Message-ID: <475A3773.4070609@gmx.de> >Und wenn ich eine irgendeine Abfrage machen will, muss ich im >einfachsten Fall einfach nur einen SQL-Befehl in die SQL-Konsole >eintippen. Bei Textdateien muss ich mir schon ein Script stricken ... Hi Robert ! Es gibt übrigens viele Leute die das ärgert. Deshalb gibt's coole Applikationen die Treiber zur Vermittlung von SQL und reinen Textdateien zur Verfügung stellen. Ein solches Beispiel wäre z.N. Perl-DBI, anhand dessen man auch mittels SQL auf CSV-Dateien zugreifen kann. Das funktioniert wie ein Treiber, also ein Vermittler zwischen der Sprache und dem Objekt. Liebe Grüße, Lucas From traut at gmx.de Sat Dec 8 07:26:53 2007 From: traut at gmx.de (Martin Trautmann) Date: Sat, 08 Dec 2007 07:26:53 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: References: <20071207181107.292870@gmx.net> <4759D630.6090401@gmx.de> Message-ID: <475A392D.4060501@gmx.de> Robert Böck wrote: > Das Problem ist aber, dass die OpenGeoDB früher als SQL-Dump verteilt > wurde, und dass es sicher viele Anwendungen gibt, die mit der > SQL-Version umgehen können, nicht aber mit den Textdateien. Ich verwendete von Anfang an die Textversion - als Import in eine andere, relationale Datenbank. Tatsächlich steckt in opengeodb derzeit nicht übermässig viel, was Relationen erforderte. Die Hierarchies waren vielleicht eine davon. Mit "Teil von" haben wir jetzt eine echte Verknüpfung der Daten miteinander. Ansonsten passen die Basisdaten ja offensichtlich sehr einfach in eine einzige Tabellenstruktur hinein. > Und das Problem ist, dass in der aktuellen SQL-Distribution Tabellen > fehlen, ohne die früher gebaute SQL-Statements nicht funktionieren. Dann müssen diese Tabellen eben wieder erzeugt werden - IMHO am einfachsten aus den Daten selbst heraus. > Und ganz offensichtlich gibt es auch viele Leute, die die OpenGeoDB > gerne in Form einer SQL-Datenbank verwenden möchten. Deswegen wird auch von mir ein SQL-Dump angeboten. >> Wenn er SQL verwenden will, sein Problem. > > Also bitte! Eine relationale Datenbank ist das Mittel der Wahl, um > solche Datenbestände zu verwalten. Und damit wären wir bei SQL ... Wofür verwendest du Relationen tastsächlich? In meinen Anwendungen ergeben die sich typischerweise erst mit den Daten selbst, in anderen Tabellen. Innerhalb der opengeodb verwende ich sie kaum. >> Vorauszusetzen, dass jeder >> andere weiss, was SEINE Befehle auf SEINER Version der Daten in SEINER >> SQL-Umgebung ergeben, erscheint mir etwas zu abgehoben. > > Was heißt SEINE Version? Wenn man, wovon in den meisten Fällen > auszugehen ist, die Version benutzt, die zum Download angeboten wird, > dann ist es eine klar definierte Version, und nicht SEINE Version ... Es gibt die 0.2.5 die derzeit offiziell auf sourceforge liegt - und es gibt derzeit einen 0.2.6 dump, der bisher erst auf fa-technik liegt und der elementare Fehler behebt: level in Österreich und die Vertauschung von lat/lon in den versionierten Daten. Mit welcher Datenbank er arbeitet, weiss ich nicht, interessiert mich auch nicht - möglicherweise ergeben sich je nach Datenbank unterschiedliche Syntax oder Ausgabeformate. Solange er mir das Ergebnis seiner Anfrage nicht mitteilt, weiss ich nicht, welche Probleme er mit den Ergebnissen tatsächlich hat. Sprich: ICH verwende kein SQL und ICH kann mit seinen SELECTs nichts anfangen. Schönen Gruß Martin From froschpopo at gmx.de Sat Dec 8 07:33:35 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Sat, 08 Dec 2007 07:33:35 +0100 Subject: [opengeodb] Aufregung in der Liste In-Reply-To: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> References: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> Message-ID: <475A3ABF.1020301@gmx.de> Lieber Georg, ich würde mich sehr freuen in Zukunft aktiver mitwirken zu können. Ich werde meinen Teil dazu beitragen. Ich möchte jedoch meine Kraft und Energie in Dinge investieren, die sich nicht immer weiter von mir distanzieren und die ich aufgrund dieser Tatsache vielleicht selbst bald nicht mehr verstehen werde. Für mich war opengeodb bisher eine Bibliothek die mir Daten zur Verfügung stellte. Diese Bibliothek entwickelt sich aber immer weiter zu einem Hightech-Gebilde! Übrigens: Der moderne Opa pflegt Datenbanken über Schmetterlinge, Pflangen und Städte. Wenn mein Opa an meiner Stelle wäre, würde er jetzt eine Datenbank erstellen, die Informationen über die openGeoDB enthält. Liebe Grüße, Lucas Georg V. schrieb: > Also, ich habe hier innerhalb von kürzester Zeit 34 ungelesene Mails auf der > Liste. Inhaltlich gemischt mit Aufregungen über Datenfehler, Aussagen über > Datenstrukturen und Diskussionen über Weiterpflege sowie schärfer werdenen > Formulierungen. > > Was die OpenGeoDB war (und hoffentlich auch noch ist) ist eine freie(*) > Datenbank über Hierarchien (politische und postalische) Strukturen mit einer > zeitlichen Dimension. Angeboten wurde sie in drei Lieferformen (Postgres, > MySQL und Textfiles; die Aufsplittungen zur einfachen Beladung in einem > gehosteten Server nicht mitgerechnet). > > Hierarchien abzufragen ist -egal welches Datenmodell und Datenhaltung man > wählt- komplex. Einige brauchen drei Abfragen, die anderen nutzen ein Wissen > über die Struktur von Gemeindeschlüsseln (was aber vorraussetzt, das diese > Daten immer gepflegt sind). > > Wenn sich einer die Mühe macht, das Thema für seine Zwecke voran zutreiben, > ist es lobenswert, aber man muss sich auch fragen, ob die Gründe passen. > Strassen (mathematisch gesehen Linien) passen nun mal schlecht zu > Bundesländer und Orten (Flächen bzw. Punkte), auch wenn sie beide nur im 2 > dimensionalen Raum betrachtet werden. > > Das Datenmodell zu ändern und dabei Informationen (nicht nur über die > Zeitachse) bereitwillig wegzuwerfen, kann und darf ebenfalls zu Recht > kritisiert werden. Wie jeder damit umgeht, ist seine persönliche Sache. > Man kann > * versuchen seine Software anzupassen, > * beim alten Datenmodell verbleiben oder > * konstruktive(!) Vorschläge für Verbesserung einbringen. > Alternativen wie Aufbau eines Pflegetools auf MySQL-Basis entfallen, da man > dann nur eine Paralleldatenhaltung erzeugen würde. > > Ich persönlich werde in der nächsten Zeit mal eine Idee zu Wiederherstellung > der Hierarchie prüfen und sie bei bestandenen Test entsprechend > kommunizieren. Des weiteren werden ich auf meine lokalen Server mit dem > Thema Differenzlieferungen beschäftigen. Für die Liste würde ich mir > wünschen, dass wir ebenfalls wieder zu einer sachlichen Diskussion zur > möglichen Weiterentwicklung > * binden wir Umriss-Informationen (s. Mail von Tobias Wendorff) > * weitere geografische Länder (s. Wikipedia) > * weitere politische Strukturen (z.B. die EU) > und den möglichen Lösungen kommen! > > Und eventuell kann sich eine(r) auch um das Thema FAQ/Wiki kümmern, damit > die Liste nicht zur persönlichen Fragestunde verkommt. > > Mit freundlichen Grüßen Georg V. > > > (*) Bitte erspart uns die Diskussion, unter welchem Lizenzmodell die > OpenGeoDB jetzt genau steht, sie ist im Archiv nachzulesen. > > From traut at gmx.de Sat Dec 8 07:46:26 2007 From: traut at gmx.de (Martin Trautmann) Date: Sat, 08 Dec 2007 07:46:26 +0100 Subject: [opengeodb] =?iso-8859-1?q?SQL_und_andere_Grunds=E4tze?= In-Reply-To: <475A3660.8060406@gmx.de> References: <47596D93.1080301@oss.schwarz.eu> <14215823.post@talk.nabble.com> <47599EA6.5030609@oss.schwarz.eu> <4759AA0E.8070501@gmx.de> <475A3660.8060406@gmx.de> Message-ID: <475A3DC2.5080104@gmx.de> Lucas Mengel wrote: > Nebenbei: Was habt ihr eigentlich gegen SQL? Überhaupt nichts - aber ich habe einen Web-Anbieter, der mit kein SQL anbietet und ich habe Anwendungen, für die ich kein SQL brauche. > SQL ist die Standard-Abfrage-Sprache für Datenbanken. Das hat eigentlich > nichts mit Struktur oder so zu tun. Nur weil "Standard" in der Abkürzung drinsteckt heisst das nicht, dass man es für alles brauchen würde. Meine eigene Hauptanwendung ist der Code-Generator fa-technik.adfc.de/code/ein, mit dem man sich aus zwei Millionen Strassen nach Möglichkeit jede Wohnadresse in Deutschland in den persönlichen EIN-Code zur Wertsachencodierung umwandeln lassen kann. Die Menge der Strassen ist noch recht gering - für so kleine Mengen taugen Textdateien recht gut. Schwieriger ist dort, wie man die Daten aufbereiten und zusammensetzen kann. Der Anwender soll es möglichst einfach haben, bei der Suche nach Schloßstraße, Schlossstr., Schloss-Straße, schlosstr usw. die richtige Antwort zu bekommen. > In der Praxis ist die Anwendung fast immer identisch: > User geben über ein Web-Interface ihre Postleitzahl an, woraufhin in > einem für sie reservierten Datensatz die Koordinaten und > weitere Informationen aus der openGeoDB gespeichert werden. > > Nun das entscheidende: Damit später eine wirklich effiziente > Umkreissuche entstehen kann müssen die Koordinaten in der > User-Datenbank der jeweiligen Community/Anwendung gespeichert werden. > Ich glaube kaum, dass irgendeine dieser Plattformen bei jeder > Suchanfrage dieses beknackte Ebenen-Modull durchläuft. Dieses Ebenenmodul sollte auch nur ein einziges Mal benötigt werden. Am einfachsten würden die entsprechenden Befehle direkt in den SQL-Dump eingebaut. Beim Einlesen der SQL-Daten würden die entsprechenden Tabellen dann automatisch angelegt. Wenn SQL so leistungsfähig und standardisiert ist, wie du und ich glauben, dann sollte das eine einfache Geschichte sein. In meiner eigenen Datenbank hätte ich in wenigen Minuten ein rekursives Script zusammengeschrieben, das die Hierarchien erzeugt haben könnte. Meine Anwendung arbeitet aber nur auf Teilbeständen (ich habe die Länder nach Tabellen getrennt, weil ich selbst nur Deutschland brauche), ist hier also wenig geeignet. Ich bin mir sicher, dass ich auch auf Basis der Textdateien mit perl recht einfach ein Script schreiben könnte, das die Hierarchies erzeugt - aber genau das ist eine Funktion, die nach meinem Glauben in eine relationale Datenbank selbst hineingehört. Ansonsten zum Standard von SQL: Meine Datenbank ist angeblich in der Lage, SQL-Anfragen zu beantworten. Mir ist das ziemlich egal - meine Datenbank ist zu dämlich, .sql als Import-Format zu verwenden. Auch OpenOffice scheint mit einer Datenbank daherzukommen. Das scheint aber auch nur SQL-Anfragen beantworten zu können. Wie man die .sql-Daten hineinbekommen würde, keine Ahnung. Früher pflegte Thomas auch etliche verschiedene .sql-Varianten für Postgres, MySQL usw. - bei einem echten Standard sollte das nicht nötig sein. Mein Standard sind daher die .txt-Dateien - die lassen sich mit jedem Texteditor verarbeiten, in fast jede Tabellenkalkulation importieren und taugen als Austauschformat für fast jede einfacher gestrickte Datenbank. Es gibt nur wenige Anwender, schätze ich, die tatsächlich von dem profitieren, was opengeodb so unübersichtlich zu machen scheint: Versionierung, Sprachvarianten usw. > Ganz im Gegenteil: Die Betreiber solcher Seiten zerlegen die openGeoDB > in ihre Einzelteile und zwar solang, bis sie exakt ihrem > Anspruch entspricht. Für eine schlichte Umkreissuche, was wohl die Hauptanwendunger der opengeodb zu sein scheint, kann man natürlich auch SQL hernehmen. Ich vermute, von der Performance ist meine Umkreissuche effizienter, die ich für fa-technik.adfc.de/code/anbieter einsetze > Ich bin nach wie vor der Meinung, man sollte einfach eine einzelne > SQL-Tabelle ausliefern und den Rest den Leuten überlassen. > Darunter sind hochbezahlte und qualifizierte Programmmierer, die dem > jeweiligen Betreiber eine maßgeschneiderte Lösung in sein > vorhandenes System implentieren. Da sind wir wohl der gleichen Meinung - sonst würde ich mir nicht die Mühe machen, .sql-Versionen zu erstellen. Schönen Gruß Martin From traut at gmx.de Sat Dec 8 07:58:09 2007 From: traut at gmx.de (Martin Trautmann) Date: Sat, 08 Dec 2007 07:58:09 +0100 Subject: [opengeodb] Aufregung in der Liste In-Reply-To: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> References: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> Message-ID: <475A4081.5060106@gmx.de> Georg V. wrote: > Also, ich habe hier innerhalb von kürzester Zeit 34 ungelesene Mails auf der > Liste. Inhaltlich gemischt mit Aufregungen über Datenfehler, Aussagen über > Datenstrukturen und Diskussionen über Weiterpflege sowie schärfer werdenen > Formulierungen. Ja, es ist erstaunlich, dass sich wieder mal was tut ;-) > Wenn sich einer die Mühe macht, das Thema für seine Zwecke voran zutreiben, > ist es lobenswert, aber man muss sich auch fragen, ob die Gründe passen. > Strassen (mathematisch gesehen Linien) passen nun mal schlecht zu > Bundesländer und Orten (Flächen bzw. Punkte), auch wenn sie beide nur im 2 > dimensionalen Raum betrachtet werden. Mit Strassen hast du ein schlechtes Beispiel gewählt - denn die passen sogar erstaunlich gut in das opengeodb-Modell: Fast jede Wohnanschrift gehört zu einer sehr konkret definierten Gemeinde, da legen die selbst schon erheblichen Wert darauf, weil sie so ihre Steuern bekommen. Ebenso ist die Finanzierung des Strassenbaus über Gemeinden und Kreise recht genau festgelegt - daher ist in der Gemeinde recht genau bekannt und zugeordnet, welche Strassen zur Gemeinde gehören. Für Kartographie- und Navigationsanwendungen besonders interessant sind hingegen die flächendeckenden Strukturen: Landstrassen, Kreisstrassen, Bundesstrassen, Autobahnen usw. Die sind bis auf Bundesebene zur Finanzierung untergebracht, laufen aber durch viele einzelne Gemeinden hindurch. Deren Modellierung macht die Sache schwieriger - und den Anwendern solcher Informationen ist meist egal, zu welcher politischen Struktur solche Daten gehören. Wenn opengeodb geeignet ist, über eine einzelne, repräsentative Koordinate eine ganze zweidimensionale Struktur wiederzugeben, dann umso mehr für linienhafte Strassen. Tatsächlich bietet obengeodb sogar min. vier Dimensionen (Länge, Breite, Höhe, Datum) oder mehr (z.B. die postalische Sichtweise) > Das Datenmodell zu ändern und dabei Informationen (nicht nur über die > Zeitachse) bereitwillig wegzuwerfen, kann und darf ebenfalls zu Recht > kritisiert werden. Wie jeder damit umgeht, ist seine persönliche Sache. > Man kann > * versuchen seine Software anzupassen, > * beim alten Datenmodell verbleiben oder > * konstruktive(!) Vorschläge für Verbesserung einbringen. > Alternativen wie Aufbau eines Pflegetools auf MySQL-Basis entfallen, da man > dann nur eine Paralleldatenhaltung erzeugen würde. Haben wir Daten weggeworfen? Ich glaube nein - wir haben nur eine Hilfsstruktur entfernt, die als Metadaten drin war und die eigentlich aus sich selbst heraus errechenbar sein muss. Mich selbst interessiert eher, wie ich die impliziten Probleme in den Griff bekomme - z.B. Datenduplikate mit/ohne Datum oder die noch ungelösten Sprachprobleme. In nächster Zeit kommen noch Extraprobleme hinzu: wie werde ich damit umgehen, dass Extradaten bearbeitbar werden? Im Moment möchte ich hier den INSERT-Befehlen einfach DELETE-Befehle gegenüberstellen... ... Das würde sich unter Umständen auch anbieten, um die Duplikate loszuwerden... Schönen Gruß Martin From traut at gmx.de Sat Dec 8 08:08:05 2007 From: traut at gmx.de (Martin Trautmann) Date: Sat, 08 Dec 2007 08:08:05 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: References: <20071207181107.292870@gmx.net> <4759D374.4080501@rainboxx.de> <4759DFF2.8020402@gmx.de> Message-ID: <475A42D5.6040907@gmx.de> Robert Böck wrote: > Hallo Martin, > > Martin Trautmann wrote: > >>> Mal ein kleines Beispiel. Ich habe mir vor längerer Zeit mal eine >>> Abfrage gestrickt, die alle Orte in Bayern ausspuckt, inklusive >>> Geokoordinaten, KFZ-Kennzeichen und Landkreis-Zugehörigkeit: > >> Die einfache Lösung: Suche nach allen Orten, bei denen der >> Gemeindeschlüssel mit 09 beginnt - so mache ich das. > > Oha! Dazu muss man aber erst mal wissen, dass man das so machen kann. > Ich wusste es bisher nicht. Woher soll man das denn wissen? Und wenn man > es nicht sowieso weiß, dann wird man sich wohl kaum auf die Suche nach > dieser Information machen (können). Die Gemeindeschlüssel kamen auch erst erheblich später in die opengeodb rein - zum Grossteil auf meinen intensiven Wunsch hin. Du kennst die Systematik: 01: Bundesland 012: Regierungsbezirk 01234: Region 012345: Kreis 012345678: Gemeinde Regierungsbezirke und Regionen gibt es nicht in jedem Bundesland - aber selbst Hamburg oder Berlin haben den Dreisprung Bundesland/Kreis/Gemeinde, auch wenn diese (nahezu) flächengleich sind. Tatsächlich verwende ich den AGS als Primärschlüssel und baue einen Grossteil meiner Hierarchien ausschliesslich darauf auf: Wenn ich zu einem Ort das Kfz-Kennzeichen wissen will, dann nehme ich einfach die ersten fünf Stellen des Gemeindeschlüssels und hole mir das Kennzeichen vom Kreis. Genaugenommen nehme ich hier eher das Kennzeichen der Gemeinde - denn es gibt Einzelfälle, wo die Gemeinde ihr Kennzeichen behalten hat und der Kreis ein anderes verwendet. Dort existiert also auf Gemeindeebene optional ein eigenes Kennzeichen. Andernfalls holt sich die Gemeinde das Kreiskennzeichen, das darüber wieder den Orten in der Gemeinde zur Verfügung steht. Für Österreich und Deutschland sind diese Gemeindeschlüssel extrem hilfreich. Die Schweiz verwendet hier ein anderes System, wo einfach auf jeder Ebene einzeln durchgezählt wird. Hier habe ich die Gemeindeschlüssel "verhunzt", weil mir "1234" noch nicht verrät, ob das der Schlüssel von Gemeinde oder Bezirk ist. Strenggenommen muss hier der erste Buchstabe (K, B oder G) weggeworfen werden. Bisher scheint das keinen gestört zu haben. Für andere Länder habe ich mit solcher Systematik noch nicht beschäftigt. Es gibt sie teilweise weltweit, über NUTS. Es gibt sie sicher in Frankreich, über die Departments. Für die derzeit verfügbaren Länder (NL, B usw.) ist mir aber nichts derartiges bekannt. Schönen Gruß Martin From traut at gmx.de Sat Dec 8 08:16:19 2007 From: traut at gmx.de (Martin Trautmann) Date: Sat, 08 Dec 2007 08:16:19 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <475A301C.30509@gmx.de> References: <20071207181107.292870@gmx.net> <4759A2AB.8040004@gmx.de> <4759AB96.2010905@gmx.de> <4759C1C8.3020100@gmx.de> <4759CC25.7050309@gmx.de> <475A301C.30509@gmx.de> Message-ID: <475A44C3.60000@gmx.de> Lucas Mengel wrote: > >>Warum weisst du das nicht? Kannst du nicht herausfinden, wofür die > loc_id 105 steht? Es ist Deutschland - > dein Aufhänger für alle deutschen > > Hi Martin! Vorab: Ich bin für JEDE, absolut JEDE, Hilfe von dir sehr > Dankbar. > > Mein Problem ist teilweise auch, dass ich von dir Zahlen erfahre, die > für mich nicht nachvollziehbar sind, so wie 105. 105 ist eine loc_id - und wenn du mit fa-technik.adfc.de/code/opengeodb.pl einmal herumspielst, dann kommst du über "Teil von" bzw. die Listenansicht mit "<" schnell bis ganz nach oben, wo du bei Deutschland landest und die Nummer 105 siehst. Diese Listenansicht wollte ich schon lange mal verbessern, dass man nicht zwischen Listen und Einzelseiten herumwechselt, sondern in der Listenansicht bleibt. Irgendwann mache ich das wohl auch mal... > Ich mache mir die ganze Zeit meine Gedanken darüber, wie du zwischen > zig-tausend Zahlen gerade auf 105 gekommen bist bzw. welchen > Weg du gegangen bist, um diese Zahl ausfindig zu machen. 105 ist nur ein Primärschlüssel. Eigentlich interessieren dich immer nur die Daten, die hinter dieser Zahl stecken - nämlich "Bundesrepublik Deutschland". > Was genau 105 bedeutet weiss ich schon, seitdem du es im Forum > geschrieben hast. > Aber wie hast du das herausbekommen? Indem ich weiss, dass es einen Primärschlüssel gibt - ohne den wärst du ziemlich aufgeschmissen. Das geht so weit, dass ich auch in der reinen Text-Version, ganz ohne SQL, diesen Primärschlüssel brauche und verwende. > >>Suche nach allem, was in 400100000 ein 105 enthält und in 400200000 > eine 3. Damit solltest du anfangen, deine Hierarchies zu erstellen. > > Warum nicht gleich: > "Um alle deutschen Städte/Infos zu ermitteln, brauchst du erstmal alle > deutschen Bundesländer." Weil das nicht stimmt. Du kannst auch sagen: Dieser Maulwurfshügel gehört zu Deutschland, ohne zu wissen, zu welcher Gemeinde, zu welchem Kreis, zu welchem Bundesland er gehört. Willst du aber die Hierarchies erzeugen, so solltest du dich von Ebene zu Ebene nach unten durcharbeiten. > Ok, die habe ich jetzt. > Ich habe mir selbstverständlich auch die Datensätze angeschaut, die sich > hinter den loc_id's der Bundesländer verbergen. > > 1. Die loc_id 117 steht z.B. für Nordrhein-Westfalen. > > 2. loc_id 14634 ist eine Stadt in Nordrhein-Westfalen, nämlich Bochum. > > 3. ich habe festgestellt, dass 117 und 14634 eine Gemeinsamkeit haben: > 5006000000 (in 14634 die ersten beiden Stellen). Dein Beispiel 2. ist aber kein Bundesland. > Soweit bin ich nun. > Was folgt weiter? Wenn du die Hierarchies der Bundesländer hast, dann gehst du zur Ebene 4 weiter, übernimmst die Hierarchie der zugehörigen Ebene 3, ergänzt sie - und machst dann mit Ebene 5 weiter.... From traut at gmx.de Sat Dec 8 08:28:32 2007 From: traut at gmx.de (Martin Trautmann) Date: Sat, 08 Dec 2007 08:28:32 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <475A44C3.60000@gmx.de> References: <20071207181107.292870@gmx.net> <4759A2AB.8040004@gmx.de> <4759AB96.2010905@gmx.de> <4759C1C8.3020100@gmx.de> <4759CC25.7050309@gmx.de> <475A301C.30509@gmx.de> <475A44C3.60000@gmx.de> Message-ID: <475A47A0.2050808@gmx.de> Martin Trautmann wrote: >> Soweit bin ich nun. >> Was folgt weiter? > > Wenn du die Hierarchies der Bundesländer hast, dann gehst du zur Ebene 4 > weiter, übernimmst die Hierarchie der zugehörigen Ebene 3, ergänzt sie - > und machst dann mit Ebene 5 weiter.... Lass dir das aber besser von einem SQL-Anwender erklären - ich hatte das auf der Sourceforgeliste für dich schonmal gemacht. Anscheinend bin ich nicht in der Lage, es dir zu vermitteln. http://sourceforge.net/forum/message.php?msg_id=4657816 Schönen Gruß Martin From froschpopo at gmx.de Sat Dec 8 10:01:16 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Sat, 08 Dec 2007 10:01:16 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <475A47A0.2050808@gmx.de> References: <20071207181107.292870@gmx.net> <4759A2AB.8040004@gmx.de> <4759AB96.2010905@gmx.de> <4759C1C8.3020100@gmx.de> <4759CC25.7050309@gmx.de> <475A301C.30509@gmx.de> <475A44C3.60000@gmx.de> <475A47A0.2050808@gmx.de> Message-ID: <475A5D5C.9030608@gmx.de> >Wenn du die Hierarchies der Bundesländer hast, dann gehst du zur Ebene 4 weiter, übernimmst die Hierarchie >der zugehörigen Ebene 3, ergänzt sie - und machst dann mit Ebene 5 weiter... Ich verstehe das Beispiel auf http://sourceforge.net/forum/message.php?msg_id=4657816 nicht. Dort steht Flensburg und das ist kein Bundesland. Ich weiss aber, dass Flensburg zu Schleswig-Holstein gehört. Und Schleswig-Holstein liegt in Deutschland. Ein solches Muster kann ich erkennen. Nun folgt eine sehr konkrete Frage, wie du sie am liebsten magst: Warum steht dort Flensburg? Noch konkreter: Mein Problem: Ich kann diese Ebenen nicht mit meinem Ziel in Verbindung bringen und das lautet: "Ich möchte alle Postleitzahlen von Deutschland haben" From wendorff at uni-paderborn.de Sat Dec 8 12:25:16 2007 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Sat, 08 Dec 2007 12:25:16 +0100 Subject: [opengeodb] Aufregung in der Liste In-Reply-To: <475A4081.5060106@gmx.de> References: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> <475A4081.5060106@gmx.de> Message-ID: <475A7F1C.300@uni-paderborn.de> Martin Trautmann schrieb: > Georg V. wrote: > >> Also, ich habe hier innerhalb von kürzester Zeit 34 ungelesene Mails auf der >> Liste. Inhaltlich gemischt mit Aufregungen über Datenfehler, Aussagen über >> Datenstrukturen und Diskussionen über Weiterpflege sowie schärfer werdenen >> Formulierungen. >> > > Ja, es ist erstaunlich, dass sich wieder mal was tut ;-) > > >> Wenn sich einer die Mühe macht, das Thema für seine Zwecke voran zutreiben, >> ist es lobenswert, aber man muss sich auch fragen, ob die Gründe passen. >> Strassen (mathematisch gesehen Linien) passen nun mal schlecht zu >> Bundesländer und Orten (Flächen bzw. Punkte), auch wenn sie beide nur im 2 >> dimensionalen Raum betrachtet werden. >> > > Mit Strassen hast du ein schlechtes Beispiel gewählt - denn die passen > sogar erstaunlich gut in das opengeodb-Modell: Fast jede Wohnanschrift > gehört zu einer sehr konkret definierten Gemeinde, da legen die selbst > schon erheblichen Wert darauf, weil sie so ihre Steuern bekommen. > Ebenso ist die Finanzierung des Strassenbaus über Gemeinden und Kreise > recht genau festgelegt - daher ist in der Gemeinde recht genau bekannt > und zugeordnet, welche Strassen zur Gemeinde gehören. > Wobei hier mal wieder ein Entscheidungsproblem auftauchen würde: Sollen Strassen nach Bauträger (Finanzierung des Strassenbaus) eingeordnet werden? Dann wären Bundesstrassen und Autobahnen entsprechend dem Bund zugeordnet - Europastrassen dagegen sind mal wieder ein zusätzlicher Layer, der als reiner Bezeichnungs-Layer für die Verkehrsnutzung fungiert und mit den Straßen selbst nichts zu tun hat. Baut man das ganze auf als Strassennetz ohne direkte Zuordnung, mit Knotenpunkten für Kreuzungen und einer zusätzlichen Zuordnung, welche Strasse in welchen Orten vorhanden ist. Beispiel Kreisstrasse 38 (K38) in Paderborn (Quellendaten dafür ist jetzt erstmal google maps): Die K38 führt von Paderborn Kernstadt über Dahl nach Schwaney. Die Zuordnung könnte man (je nach akuter Granularität der Opengeodb) festlegen als: K38 PB Kernstadt K38 Dahl K38 Schwaney wobei die Orte hier Ortsteile wären (die allesamt noch nicht in der opengeodb registriert sind, wenn ich das richtig sehe - vielleicht sollte ich mich als Paderborner darum in nächster Zeit mal kümmern...) Daraus ließe sich ableiten, dass die K38 auch durch alle höheren Ebenen läuft (also z.B. durch die Gemeinde Paderborn, den Kreis Paderborn etc) Die Kategorisierung der Strassen als Bundes- Land- Kreis- Gemeindestrasse etc sollte meines Erachtens dann noch ein zusätzlicher Layer sein; praktisch eine weitere Typisierung für Strassen. Dies ist aber wahrscheinlich nur für die Darstellung auf Karten relevant, da vermutlich nur sehr wenig User Verwendung für die tatsächliche Verwaltungsstruktur in dem Bereich haben dürften. > Für Kartographie- und Navigationsanwendungen besonders interessant sind > hingegen die flächendeckenden Strukturen: Landstrassen, Kreisstrassen, > Bundesstrassen, Autobahnen usw. Die sind bis auf Bundesebene zur > Finanzierung untergebracht, laufen aber durch viele einzelne Gemeinden > hindurch. Deren Modellierung macht die Sache schwieriger - und den > Anwendern solcher Informationen ist meist egal, zu welcher politischen > Struktur solche Daten gehören. > siehe oben. > Wenn opengeodb geeignet ist, über eine einzelne, repräsentative > Koordinate eine ganze zweidimensionale Struktur wiederzugeben, dann umso > mehr für linienhafte Strassen. Tatsächlich bietet obengeodb sogar min. > vier Dimensionen (Länge, Breite, Höhe, Datum) oder mehr (z.B. die > postalische Sichtweise) > ...und abgesehen vom Aufwand und dem Problem der Vollständigkeit fände ich eine entsprechende Erweiterung mehr als gut. > Mich selbst interessiert eher, wie ich die impliziten Probleme in den > Griff bekomme - z.B. Datenduplikate mit/ohne Datum oder die noch > ungelösten Sprachprobleme. > > In nächster Zeit kommen noch Extraprobleme hinzu: wie werde ich damit > umgehen, dass Extradaten bearbeitbar werden? Im Moment möchte ich hier > den INSERT-Befehlen einfach DELETE-Befehle gegenüberstellen... > ... Das würde sich unter Umständen auch anbieten, um die Duplikate > loszuwerden... > und genau das sind die Gründe, weshalb die Erweiterungsideen, deren es wahrscheinlich tausende gibt, erstmal weniger dringend sind und eben nicht sofort angepackt werden müssen. Gruß Peter From froschpopo at gmx.de Sat Dec 8 14:06:19 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Sat, 08 Dec 2007 14:06:19 +0100 Subject: [opengeodb] Schema-Vorschlag In-Reply-To: <475A7F1C.300@uni-paderborn.de> References: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> <475A4081.5060106@gmx.de> <475A7F1C.300@uni-paderborn.de> Message-ID: <475A96CB.8090108@gmx.de> Also ich muss sagen, mit der D.sql komme ich besser zurecht, weil diese hierarchies wegfallen. Was haltet ihr eigentlich von der Idee, wenn man sich diese ganzen text_type's spart und für jede "Spalten-Art" eine eigene Tabelle anlegt. Das wäre sicherlich auch performanter. Ein kleines Beispiel: SELECT orte.value AS Ort, plz.value AS PLZ FROM orte, plz Ist doch eh dasselbe wie: SELECT tx1.value AS Ort, tx2.value AS PLZ FROM geodb_textdata tx1, geodb_textdata tx2 Von der Performance wäre Ersteres vermutlich sogar noch besser, da er nur tatsächliche Orte lädt und nicht die ganzen 500x, 400x usw. LG, Lucas From opengeodb at Froehlich.Priv.at Sat Dec 8 14:10:43 2007 From: opengeodb at Froehlich.Priv.at (Stefan Froehlich) Date: Sat, 8 Dec 2007 14:10:43 +0100 Subject: [opengeodb] Schema-Vorschlag In-Reply-To: <475A96CB.8090108@gmx.de> References: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> <475A4081.5060106@gmx.de> <475A7F1C.300@uni-paderborn.de> <475A96CB.8090108@gmx.de> Message-ID: <20071208131042.GA10701@epaxios.internetserviceteam.com> On Sat, Dec 08, 2007 at 02:06:19PM +0100, Lucas Mengel wrote: > Was haltet ihr eigentlich von der Idee, wenn man sich diese ganzen > text_type's spart und für jede "Spalten-Art" eine eigene Tabelle > anlegt. Ich hielte sehr viel davon, wenn einmal grundsaetzlich Gedanken ueber eine normalisierte Darstellung gemacht wuerden. Aus dieser dann alternative Darstellungen abzuleiten, auch flache Textformate, ist sicherlich ein kleineres Problem, als die umgekehrte Richtung zu gehen. Ich bin leider nicht mehr so wirklich in den Thema drin, aber unterstuetzen wuerde ich dabei schon koennen. Servus, Stefan -- Mit der Sympathie des Verführers - Stefan: stöhnen, welch grossartiges Entzücken! http://www.sloganizer.de/ From froschpopo at gmx.de Sat Dec 8 16:23:48 2007 From: froschpopo at gmx.de (Lucas Mengel) Date: Sat, 08 Dec 2007 16:23:48 +0100 Subject: [opengeodb] Schema-Vorschlag In-Reply-To: <20071208131042.GA10701@epaxios.internetserviceteam.com> References: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> <475A4081.5060106@gmx.de> <475A7F1C.300@uni-paderborn.de> <475A96CB.8090108@gmx.de> <20071208131042.GA10701@epaxios.internetserviceteam.com> Message-ID: <475AB704.1010009@gmx.de> Hallo Stefan! Von meiner Seite aus wird es keine Anstrengungen geben, die aktuelle 0.2.5a zu publizieren, geschweige denn Empfehlungen auszusprechen. Meine Gründe: Die Datenbank verfehlt ihren Sinn, nämlich die Erfassung von geologischen und kartographischen Daten. Stattdessen entwickelt die Zusammenstellung der Daten eine Eigendynamik und die Datenbankstruktur wird immer mehr zum Mittelpunkt. Von Geologen und anderen, oft sehr kompetenten Personen, werden ja nahezu "Programmierkenntnisse" abverlangt. Was ist denn mit denjenigen, die einfach Interesse an den Daten haben und deren Horizont Excel nicht übersteigt? Viele ältere Leute interessieren sich für sowas, haben aber keine Chance an der Datenbank mitzuwirken, weil sie vor lauter SQL, Queries, Ebenen und Hierchies keinen Satz verstehen? Wie sich hier in der Liste ja auch sehr gut beobachten lässt, ist das allgemeine Interesse an der 0.2.5 Version ziemlich niedrig. Ich bin sicherlich nicht der einzige, der keine Mühen und Energie in etwas investieren möchte, was er nicht gut findet und wovon er nicht überzeugt ist. Ich vermute des Weiteren, dass die Architektur, auch wegen der scharfen Kritik, bald geändert wird. Spätestens dann, würde man sich jetzt die Mühe machen die aktuelle Version zu erklären, wäre die Arbeit für die Katz. Dann warte ich doch lieber, bis man sich auf eine bessere Lösung geeinigt hat und gebe dann Vollgas. Bis dahin bleibt mir nichts weiter übrig, Vorschläge zu erbringen. Ich bin sicherlich nicht der Einzige, der so denkt. LG, Lucas > Ich hielte sehr viel davon, wenn einmal grundsaetzlich Gedanken > ueber eine normalisierte Darstellung gemacht wuerden. Aus dieser > dann alternative Darstellungen abzuleiten, auch flache Textformate, > ist sicherlich ein kleineres Problem, als die umgekehrte Richtung zu > gehen. > From opengeodb at Froehlich.Priv.at Sat Dec 8 16:53:09 2007 From: opengeodb at Froehlich.Priv.at (Stefan Froehlich) Date: Sat, 8 Dec 2007 16:53:09 +0100 Subject: [opengeodb] Schema-Vorschlag In-Reply-To: <475AB704.1010009@gmx.de> References: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> <475A4081.5060106@gmx.de> <475A7F1C.300@uni-paderborn.de> <475A96CB.8090108@gmx.de> <20071208131042.GA10701@epaxios.internetserviceteam.com> <475AB704.1010009@gmx.de> Message-ID: <20071208155309.GB11417@epaxios.internetserviceteam.com> On Sat, Dec 08, 2007 at 04:23:48PM +0100, Lucas Mengel wrote: > Die Datenbank verfehlt ihren Sinn, nämlich die Erfassung von > geologischen und kartographischen Daten. Stattdessen entwickelt > die Zusammenstellung der Daten eine Eigendynamik und die > Datenbankstruktur wird immer mehr zum Mittelpunkt. Aus meiner Sicht zerfaellt so ein Projekt in drei Teile: a) die Datenstruktur b) die Infrastruktur c) der Datenbestand Fuer die meisten Anwender ist Punkt c) der interessanteste, gepaart mit den Teilen aus b), die fuer den eigenen Bedarf benoetigt werden. Das aendert aber nichts daran, dass langfristig auch Engagement beim Punkt a) notwendig ist, um die Komplexitaet des Projekts in ertraeglichen Grenzen zu halten. > Von Geologen und anderen, oft sehr kompetenten Personen, werden ja > nahezu "Programmierkenntnisse" abverlangt. Was ist denn mit > denjenigen, die einfach Interesse an den Daten haben und deren > Horizont Excel nicht übersteigt? Viele ältere Leute interessieren > sich für sowas, haben aber keine Chance an der Datenbank > mitzuwirken, [...] :-) Wenn wo ein _gutes_ Datenmodell existiert, dann ist es meist auch relativ einfach, neue Daten einzutragen oder die gewuenschten Ansichten daraus abzuleiten. Es kann keinesfalls notwendig sein, dass jeder sich mit SQL auskennt, aber das aendert in meinen Augen nichts an den Vorteilen einer vernuenftigen Basis. Dummerweise sind meine Kenntnisse ueber die Verknuepfungen und Abhaengigkeiten der einzelnen Daten bei diesem Thema relativ begrenzt, ansonsten kaeme ich gerne mit konkreteren Vorschlaegen. > Dann warte ich doch lieber, bis man sich auf eine bessere Lösung > geeinigt hat und gebe dann Vollgas. In den Jahren, in denen ich hier schon - meist recht still - mitlese, sind schon viele Vorschlaege gekommen und gegangen... :) Servus, Stefan -- Stefan - der Wahn zu wehen! http://www.sloganizer.de/ From perl at rainboxx.de Sat Dec 8 17:22:04 2007 From: perl at rainboxx.de (Matthias Dietrich) Date: Sat, 08 Dec 2007 17:22:04 +0100 Subject: [opengeodb] Schema-Vorschlag In-Reply-To: <20071208155309.GB11417@epaxios.internetserviceteam.com> References: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> <475A4081.5060106@gmx.de> <475A7F1C.300@uni-paderborn.de> <475A96CB.8090108@gmx.de> <20071208131042.GA10701@epaxios.internetserviceteam.com> <475AB704.1010009@gmx.de> <20071208155309.GB11417@epaxios.internetserviceteam.com> Message-ID: <475AC4AC.7020501@rainboxx.de> Hi, > Aus meiner Sicht zerfaellt so ein Projekt in drei Teile: > > a) die Datenstruktur > b) die Infrastruktur > c) der Datenbestand > > Fuer die meisten Anwender ist Punkt c) der interessanteste, gepaart > mit den Teilen aus b), die fuer den eigenen Bedarf benoetigt werden. > Das aendert aber nichts daran, dass langfristig auch Engagement beim > Punkt a) notwendig ist, um die Komplexitaet des Projekts in > ertraeglichen Grenzen zu halten. dem Stimme ich zu, möchte aber hinzufügen, dass IMHO a) immer notwendig ist. Denn selbst die Daten alleine sind recht komplex, wenn man denn alles Abbilden möchte. Man muss die Zuordnung zu einer höheren meist organisatorischen Einheit darstellen etc. Dazu wird eine Struktur benötigt, es ist ja nicht nur einfach eine Liste. >> Von Geologen und anderen, oft sehr kompetenten Personen, werden ja >> nahezu "Programmierkenntnisse" abverlangt. Was ist denn mit >> denjenigen, die einfach Interesse an den Daten haben und deren >> Horizont Excel nicht übersteigt? Viele ältere Leute interessieren >> sich für sowas, haben aber keine Chance an der Datenbank >> mitzuwirken, [...] Ich denke, dass es mit dieser Datenbank weniger um die Geologen geht. Die meisten haben einen "offiziellen" Datenbestand mit entsprechenden Lizenzen und Gebühren, Updates bei Änderungen und so weiter. Zudem gibt es für diese Bestände meist entsprechende Frontends. Hier geht es eher um die Leute, die als Hobby etwas mit diesen Daten anfangen möchte. Oder auch noch ein wenig weiter gedacht, um Leute, die mit den Daten professionel arbeiten möchten, sich aber keine kommerziellen Datenbanken erwerben können/möchten (so wie ich). Die Hobby-Leute haben oft kein Verständnis von SQL, oder können nicht viel Programmieren. Was auch immer sie dann überhaupt mit den Daten anfangen wollen, ist deren Sache. Dennoch ist SQL bzw. eine relationale Datenbank perfekt, um solche Daten zu speichern. Es können alle möglichen Beziehungen wunderbar dargestellt werden. Ein Export hin zu Excel- oder Flatfiles (Textdateien) ist dann nicht mehr viel Arbeit. Klar, das wollen die "Geologen" oder Hobbytüftler etc. nicht selbst machen. Aber irgendjemand muss oder sollte es machen, damit die entsprechenden Personen die Daten sehr einfach verwenden können. > Wenn wo ein _gutes_ Datenmodell existiert, dann ist es meist auch > relativ einfach, neue Daten einzutragen oder die gewuenschten > Ansichten daraus abzuleiten. Es kann keinesfalls notwendig sein, > dass jeder sich mit SQL auskennt, aber das aendert in meinen Augen > nichts an den Vorteilen einer vernuenftigen Basis. Jup! > Dummerweise sind meine Kenntnisse ueber die Verknuepfungen und > Abhaengigkeiten der einzelnen Daten bei diesem Thema relativ > begrenzt, ansonsten kaeme ich gerne mit konkreteren Vorschlaegen. > In den Jahren, in denen ich hier schon - meist recht still - > mitlese, sind schon viele Vorschlaege gekommen und gegangen... :) Das Wissen kannst du dir ja aneignen ;). Ich finde es gut, dass sich Martin daran gemacht hat und die Daten weiter pflegt. Er mag das mit dem Ziel machen, die Daten für seine Zwecke zu haben und manchmal ein paar andere Dinge als unwichtiger einzustufen. Trotzdem hat *er* etwas gemacht, und *wir* nichts. Aber zu richtigen OpenSource-/Community-Projekten gehören mehrere Personen, damit auch garantiert werden kann, dass wiederum andere Personen mit den Daten etwas anfangen können. Und zwar *ohne* sie jedesmal für die eigenen Zwecke neu zu organisieren. Wie gesagt, würde ich mich anbieten, mitzuhelfen und mitzudenken. Zeitlich kann es ab und zu knapp werden, aber da wird sich schon eine Lösung finden. Viele Grüße, Matthias From robert.boeck at googlemail.com Sat Dec 8 17:24:11 2007 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Sat, 08 Dec 2007 17:24:11 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <475A392D.4060501@gmx.de> References: <20071207181107.292870@gmx.net> <4759D630.6090401@gmx.de> <475A392D.4060501@gmx.de> Message-ID: Hallo Martin, Martin Trautmann wrote: >>> Wenn er SQL verwenden will, sein Problem. >> >> Also bitte! Eine relationale Datenbank ist das Mittel der Wahl, um >> solche Datenbestände zu verwalten. Und damit wären wir bei SQL ... > Wofür verwendest du Relationen tastsächlich? In meinen Anwendungen > ergeben die sich typischerweise erst mit den Daten selbst, in anderen > Tabellen. Innerhalb der opengeodb verwende ich sie kaum. Nun ja, aus den Relationen ergibt sich z. B., dass Bayern zu Deutschland gehört, Schwaben zu Bayern, Ostallgäu zu Schwaben und Schwangau zum Ostallgäu. cu, Robo :) From robert.boeck at googlemail.com Sat Dec 8 17:28:31 2007 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Sat, 08 Dec 2007 17:28:31 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <475A42D5.6040907@gmx.de> References: <20071207181107.292870@gmx.net> <4759D374.4080501@rainboxx.de> <4759DFF2.8020402@gmx.de> <475A42D5.6040907@gmx.de> Message-ID: Hallo Martin, Martin Trautmann wrote: [Alle Orte in Bayern] >>> Die einfache Lösung: Suche nach allen Orten, bei denen der >>> Gemeindeschlüssel mit 09 beginnt - so mache ich das. >> >> Oha! Dazu muss man aber erst mal wissen, dass man das so machen kann. >> Ich wusste es bisher nicht. Woher soll man das denn wissen? Und wenn man >> es nicht sowieso weiß, dann wird man sich wohl kaum auf die Suche nach >> dieser Information machen (können). > > Die Gemeindeschlüssel kamen auch erst erheblich später in die opengeodb > rein - zum Grossteil auf meinen intensiven Wunsch hin. > > Du kennst die Systematik: > > 01: Bundesland > 012: Regierungsbezirk > 01234: Region > 012345: Kreis > 012345678: Gemeinde Nein, kenne ich nicht. Bzw. kannte ich nicht - bis jetzt. [...] > Für Österreich und Deutschland sind diese Gemeindeschlüssel extrem > hilfreich. [...] > Die Schweiz verwendet hier ein anderes System, wo einfach auf jeder > Ebene einzeln durchgezählt wird. Hier habe ich die Gemeindeschlüssel > "verhunzt", weil mir "1234" noch nicht verrät, ob das der Schlüssel von > Gemeinde oder Bezirk ist. Strenggenommen muss hier der erste Buchstabe > (K, B oder G) weggeworfen werden. Bisher scheint das keinen gestört zu > haben. Wenn das System der Gemeindeschlüssel nicht in jedem gleich ist, kann man Abfragen darüber nicht universell verwenden. Die Relationen aus der Datenbank aber schon. cu, Robo :) From traut at gmx.de Sat Dec 8 21:46:30 2007 From: traut at gmx.de (Martin Trautmann) Date: Sat, 08 Dec 2007 21:46:30 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <475A5D5C.9030608@gmx.de> References: <20071207181107.292870@gmx.net> <4759A2AB.8040004@gmx.de> <4759AB96.2010905@gmx.de> <4759C1C8.3020100@gmx.de> <4759CC25.7050309@gmx.de> <475A301C.30509@gmx.de> <475A44C3.60000@gmx.de> <475A47A0.2050808@gmx.de> <475A5D5C.9030608@gmx.de> Message-ID: <475B02A6.90909@gmx.de> Lucas Mengel wrote: > >Wenn du die Hierarchies der Bundesländer hast, dann gehst du zur Ebene > 4 weiter, übernimmst die Hierarchie > >der zugehörigen Ebene 3, ergänzt sie - und machst dann mit Ebene 5 > weiter... > > Ich verstehe das Beispiel auf > http://sourceforge.net/forum/message.php?msg_id=4657816 nicht. > Dort steht Flensburg und das ist kein Bundesland. Dort wird auch nicht behauptet, Flensburg wäre ein Bundesland. Hierarchie: Deutschland > Schleswig-Holstein > Flensburg loc_id: 105 > 119 > 466 Ebenen: 2 > 3 > 5 Flensburg ist also die loc_id 466, liegt auf Ebene 5 und ist Teil von 119. Deutschland auf Ebene 2 hat also die Hierarchie Europa, Deutschland Schleswig-Holsten auf Ebene 3 ist Teil von Deutschland und hat die Hierarchie Europa, Deutschland, Schleswig-Holstein Flensburg ist Teil von Schleswig-Holstein und hat daher die Hierarchie Europa, Deutschland, Schleswig-Holstein, Flensburg > Nun folgt eine sehr konkrete Frage, wie du sie am liebsten magst: > Warum steht dort Flensburg? Weil Flensburg einfach das erste Beispiel ist - ein willkürliches Beispiel über mehrere Ebenen hinweg > Noch konkreter: > Mein Problem: Ich kann diese Ebenen nicht mit meinem Ziel in Verbindung > bringen und das lautet: > "Ich möchte alle Postleitzahlen von Deutschland haben" Dein Ziel läuft raus auf "von Deutschland". In der Flensburger Zeile der Hierarchien steht drin: Europa, Deutschland, Schleswig-Holstein, Flensburg Nachdem du die Hierarchien aufgebaut hast, kannst du also deine Suche direkt eingrenzen auf all das, was zu Deutschland gehört. Bis dahin weisst du nur, dass Flensburg zu Schleswig-Holstein gehört, aber noch nicht, dass damit Flensburg auch zu Deutschland gehört. In SQL-Syntax lautet der Hierarchieeintrag von Flensburg, NACHDEM du ihn erstellt hast: geodb_hierarchies (466,5,104,105,119,NULL,466,NULL,NULL,NULL,NULL, NULL,NULL, '3000-01-01',300500000); From list at lab.at Sat Dec 8 22:23:05 2007 From: list at lab.at (Andreas Labres) Date: Sat, 08 Dec 2007 22:23:05 +0100 Subject: [opengeodb] Schema-Vorschlag In-Reply-To: <475AC4AC.7020501@rainboxx.de> References: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> <475A4081.5060106@gmx.de> <475A7F1C.300@uni-paderborn.de> <475A96CB.8090108@gmx.de> <20071208131042.GA10701@epaxios.internetserviceteam.com> <475AB704.1010009@gmx.de> <20071208155309.GB11417@epaxios.internetserviceteam.com> <475AC4AC.7020501@rainboxx.de> Message-ID: <475B0B39.30402@al.lab.at> Nur zwei Anmerkungen von meiner Seite: Die opengeodb Struktur soll möglichst universell sein, sprich es sollen alle denkbaren Aspekte/Daten drin abbildbar sein. Wenn es für gewisse Anwendungsbereiche den Vorschlag einer anderen Strukturierung gibt, so möge man bitte Zeit&Energie darin verwenden, die Schritte/Scripte zu dokumentieren, wie man aus dem Datenbestand jene Struktur destilieren kann. Die Welt ist nicht universal-relational darstellbar. Z.B. (in AT): Ortsnetze (Vorwahlbereiche) vs Gemeinde- (etc.) Gebiete vs PLZ-Gebiete. Da gibt es alle denkbaren Überschneidungen und erst einer einzelnen Adresse ist zu einem Zeitpunkt eine PLZ oder eine Ortsvorwahl eindeutig zugeordnet. Trotzdem machen für viele Zwecke (Umkreissuchen oder sowas) vereinfachte Modelle Sinn. Drum beschreibe man, wie man die für den jeweiligen Zweck notwendigen Daten am besten herausdestlilieren kann. /al From georg at familieverweyen.de Sun Dec 9 06:20:26 2007 From: georg at familieverweyen.de (Georg V.) Date: Sun, 9 Dec 2007 06:20:26 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <475B02A6.90909@gmx.de> Message-ID: <004601c83a23$3550c010$0c01a8c0@verweyen12> >Martin Trautmann antworte: >Lucas Mengel wrote: >> >Wenn du die Hierarchies der Bundesländer hast, dann gehst du zur >> Ebene >> 4 weiter, übernimmst die Hierarchie >> >der zugehörigen Ebene 3, ergänzt sie - und machst dann mit Ebene 5 >> weiter... >> >> Ich verstehe das Beispiel auf >> http://sourceforge.net/forum/message.php?msg_id=4657816 nicht. >> Dort steht Flensburg und das ist kein Bundesland. > >Dort wird auch nicht behauptet, Flensburg wäre ein Bundesland. > >Hierarchie: Deutschland > Schleswig-Holstein > Flensburg >loc_id: 105 > 119 > 466 >Ebenen: 2 > 3 > 5 > >Flensburg ist also die loc_id 466, liegt auf Ebene 5 und ist Teil von 119. > >Deutschland auf Ebene 2 hat also die Hierarchie > Europa, Deutschland >Schleswig-Holsten auf Ebene 3 ist Teil von Deutschland und hat die Hierarchie > Europa, Deutschland, Schleswig-Holstein Flensburg ist Teil von Schleswig-Holstein und hat daher die Hierarchie > Europa, Deutschland, Schleswig-Holstein, Flensburg Hallo Martin, Und das genau ist derzeit einer der größten Fehler: Der Ebene wird (sogar länderspezifisch) einer Bedeutung zu geordnet, dabei gibt es doch die Ebenen-Bedeutung in der geodb_locations. Wenn man generell ein Hierarchie aufbauen will, muss man nicht vorher die Hierarchiestufen festlegen, sondern könnte auch erstmal sagen: In der Welt liegt der Ortsteil Thomasberg. Welt +- Thomasberg Wenn man dann durch andere Quellen feststellt, das Thomasberg ein Ortsteil von Königswinter und Königswinter in Deutschland liegt, kann man das einfügen Welt +- Deutschland +- Königswinter +- Thomasberg Das mag sich jetzt komisch anhören, aber stell Dir vor Du hättest Koordinaten von New York (Big Apple) und würdest Sie ohne Kenntnisse der politischen Struktur in die Hierarchie einsortieren wollen. Welt +- Amerika |+- United State of America | +- New York | +- Europa +- Deutschland +- Nordrhein-Westfalen +- Köln +- Rhein-Sieg-Kreis +- Königswinter +- Thomasberg Mit freundlichen Grüßen Georg V. P.S.: Ich muss meine Formulierung noch leicht von Datenbank nach Datenhaltung modifizieren, da wir eigentlich Daten sammeln und die Form (Datenbank MySQL und Textdateien) nur ein Mittel zum Zweck ist. * Die OpenGeoDB ist eine freie Datenhaltung über Hierarchien (politische und postalische) Strukturen mit einer zeitlichen Dimension. Welche Hilfsmittel wir anbieten, damit Lucas seine PLZ-Zahlen hat, ist davon unabhängig und nur ein kleines Randgebiet. Es kann durchaus auch ein kostenpflichtiges Angebot sein. From traut at gmx.de Sun Dec 9 08:16:12 2007 From: traut at gmx.de (Martin Trautmann) Date: Sun, 09 Dec 2007 08:16:12 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <004601c83a23$3550c010$0c01a8c0@verweyen12> References: <004601c83a23$3550c010$0c01a8c0@verweyen12> Message-ID: <475B963C.8020707@gmx.de> Georg V. wrote: > Und das genau ist derzeit einer der größten Fehler: Der Ebene wird (sogar > länderspezifisch) einer Bedeutung zu geordnet, dabei gibt es doch die > Ebenen-Bedeutung in der geodb_locations. Hallo Georg, wo in den Locations steht die Ebenen-Bedeutung drin? Wie würdest du Deutschland / Baden-Württemberg / Südbaden / Breisgau / Gundelfingen / Heuweiler einordnen, im Vergleich zu Europa / Vatikan / Petersdom? Es gibt vergleichbare politische Strukturebenen. In Deutschland ist das die Gemeindebene unter der Kreisebene unter dem Bundesland. Du würdest aber beispielsweise in Sachsen-Anhalt nach Wegfall der bisherigen Regierungsbezirke alles eine Ebene nach oben schieben. Gerade wegen der Vergleichbarkeit der politischen Gliederungen will in in der opengeodb die Information haben, auf welcher politischen Ebene sich der einzelne Eintrag befindet. Schönen Gruß Martin From opengeodb at Froehlich.Priv.at Sun Dec 9 08:24:06 2007 From: opengeodb at Froehlich.Priv.at (Stefan Froehlich) Date: Sun, 9 Dec 2007 08:24:06 +0100 Subject: [opengeodb] Schema-Vorschlag In-Reply-To: <475B0B39.30402@al.lab.at> References: <006201c83962$1b8f8d30$0c01a8c0@verweyen12> <475A4081.5060106@gmx.de> <475A7F1C.300@uni-paderborn.de> <475A96CB.8090108@gmx.de> <20071208131042.GA10701@epaxios.internetserviceteam.com> <475AB704.1010009@gmx.de> <20071208155309.GB11417@epaxios.internetserviceteam.com> <475AC4AC.7020501@rainboxx.de> <475B0B39.30402@al.lab.at> Message-ID: <20071209072406.GA30071@epaxios.internetserviceteam.com> On Sat, Dec 08, 2007 at 10:23:05PM +0100, Andreas Labres wrote: > Die opengeodb Struktur soll möglichst universell sein, sprich es > sollen alle denkbaren Aspekte/Daten drin abbildbar sein. Ja - und das ist auch sicherlich erst einmal die groesste Schwierigkeit. Es beginnt ja schon damit, dass laenderweise, aber auch innerhalb der Laender (PLZ vs. rechtliche Strukrut) verschiedene Organisationsmodelle verwendet werden. > Trotzdem machen für viele Zwecke (Umkreissuchen oder sowas) > vereinfachte Modelle Sinn. > Drum beschreibe man, wie man die für den jeweiligen Zweck > notwendigen Daten am besten herausdestlilieren kann. Auch das ist jedenfalls _vor_ einer groesseren Aenderung zu tun. Allerdings wuerde ich das waehrend der Entstehung einer Datenstruktur nur im Auge behalten, im Detail erst hinterher entwickeln. Mit einer brauchbaren Struktur _muss_ es einen Weg geben, die vereinfachten Sichten zu erhalten, sonst ist die Struktur nicht brauchbar... Servus, Stefan -- Die letzte Steigerungsform von "super"! Stefan, wenn alles mißlingt! http://www.sloganizer.de/ From georg at familieverweyen.de Sun Dec 9 08:57:41 2007 From: georg at familieverweyen.de (Georg V.) Date: Sun, 9 Dec 2007 08:57:41 +0100 Subject: [opengeodb] =?iso-8859-1?q?Liste_der_L=E4nder?= In-Reply-To: <475B963C.8020707@gmx.de> Message-ID: <004f01c83a39$2cbe6040$0c01a8c0@verweyen12> Hallo Martin, Der meinsame Knoten-/Ursprungs- Punkt ist die Welt: Also Welt +- Deutschland |+- Baden-Württemberg | +- Südbaden | +- Breisgau | +- Gundelfingen | +- Heuweiler +- Europa +- Vatikan +- Petersdom Dann würde einer darauf kommen, das Deutschland auch in Europa liegt (und die Ebenen oberhalb von Gundelfingen "Freiburg" und "Landkreis Breisgau-Hochschwarzwald" lauten), damit ergibt sich: Welt +- Europa +- Deutschland |+- Baden-Württemberg | +- Freiburg | +- Landkreis Breisgau-Hochschwarzwald | +- Gundelfingen | +- Heuweiler +- Vatikan +- Petersdom Dadurch, das man den Objekten feste ID's (loc_id) erteilt, kann man dann auch so Besonderheiten wie im Wikipedia-Artikel über PLZ Abschnitt Ausnahmen abbilden: --- Zitatanfang --- Obwohl die fünfstelligen Postleitzahlen allein für das deutsche Bundesgebiet entwickelt wurden, mussten auch Ausnahmen berücksichtigt werden. Das österreichische Kleinwalsertal im Bundesland Vorarlberg und die Gemeinde Jungholz in Tirol verfügen als Zollausschlussgebiete Österreichs bzw. Zollanschlussgebiete Deutschlands sowohl über deutsche als auch über österreichische Postleitzahlen. ... Eine weitere Ausnahme mit zwei Postleitzahlen bildet die Gemeinde Büsingen, eine deutsche Exklave im Schweizer Kanton Schaffhausen. Hier gibt es außerdem auch zwei verschiedene Telefonvorwahlen (in Klammern). --- Zitatende --- Mit freundlichen Grüßen Georg V. P.S.: Dies m.E. die beste Datenstruktur, die man für hierarchische Datenstrukturen verwenden kann. P.S.2: Die Zeichnungen kann man besten "verstehen", wenn man einen Zeichensatz mit fester Berite (wie Courier) zur Anzeige nimmt. -----Ursprüngliche Nachricht----- Martin Trautmann schrieb >Georg V. wrote: > >> Und das genau ist derzeit einer der größten Fehler: Der Ebene wird >> (sogar >> länderspezifisch) einer Bedeutung zu geordnet, dabei gibt es doch die >> Ebenen-Bedeutung in der geodb_locations. > >Hallo Georg, > >wo in den Locations steht die Ebenen-Bedeutung drin? > >Wie würdest du Deutschland / Baden-Württemberg / Südbaden / Breisgau / Gundelfingen / Heuweiler einordnen, >im Vergleich zu Europa / Vatikan / Petersdom? From opengeodb at Froehlich.Priv.at Sun Dec 9 09:11:16 2007 From: opengeodb at Froehlich.Priv.at (Stefan Froehlich) Date: Sun, 9 Dec 2007 09:11:16 +0100 Subject: [opengeodb] Schema-Vorschlag In-Reply-To: <475AC4AC.7020501@rainboxx.de> References: Message-ID: <20071209081116.GA30529@epaxios.internetserviceteam.com> On Sat, Dec 08, 2007 at 05:22:04PM +0100, Matthias Dietrich wrote: > > Dummerweise sind meine Kenntnisse ueber die Verknuepfungen und > > Abhaengigkeiten der einzelnen Daten bei diesem Thema relativ > > begrenzt, ansonsten kaeme ich gerne mit konkreteren Vorschlaegen. > Das Wissen kannst du dir ja aneignen ;). Ich wollte nicht unbedingt zum Universalexperten werden :-) > Trotzdem hat *er* etwas gemacht, und *wir* nichts. > Aber zu richtigen OpenSource-/Community-Projekten gehören mehrere > Personen, damit auch garantiert werden kann, dass wiederum andere > Personen mit den Daten etwas anfangen können. Und zwar *ohne* sie > jedesmal für die eigenen Zwecke neu zu organisieren. Ja. Ersteres ist richtig und letzteres waere praktisch. > Wie gesagt, würde ich mich anbieten, mitzuhelfen und mitzudenken. Was das Mitdenken betrifft: die Aufteilung in textdata, intdata, floatdata, locations und coordinates finde ich sehr ungluecklich, weil ueber den Datentyp definiert anstatt ueber den Inhalt. Eigene Tabellen fuer einzelne Objekte erschienen mir sinnvoller. Aber bereits da beginnen die Schwierigkeiten, weil das nicht auf allen Ebenen machbar sein wird. Nehmen wir einmal Dinge, die Klartexte enthalten: Erdteile und Staaten in jeweils eigene Strukturen zu verlagern waere IMHO ein Gewinn, Ortschaften jedweder Groesse v