From winkelmann at blue-metallic.de Mon Mar 3 13:15:04 2008 From: winkelmann at blue-metallic.de (Jan-Simon Winkelmann) Date: Mon, 03 Mar 2008 13:15:04 +0100 Subject: [opengeodb] Problematik beim Einzeichnen von Punkten auf einer Karte Message-ID: Hallo Liste, ich arbeite gerade daran bestimmte Koordinaten auf einer Deutschlandkarte einzuzeichnen. Mit der DE-CH-AT-Karte von http://www.giswiki.org/index.php/Point-Mapping_Extension#Samples funktioniert das auch alles ganz wunderbar, nur mit der DE-Karte nicht weil anscheinend die Werte im World-File nicht stimmen. Da ich aber sowieso anderes Kartenmaterial nutzen muss das besser an eines meiner Website-Designs angepasst ist stellt sich f=FCr mich die Frage wie ich die ben=F6tigten Werte selbst berechnen kann. Sinnvolle Informationen dazu hab ich leider nirgends gefunden. Hat da jemand eine Quelle? mit freundlichen Gr=FC=DFen aus Herford Jan-Simon Winkelmann From weber.ralf at wonderer.de Mon Mar 3 16:04:13 2008 From: weber.ralf at wonderer.de (weber.ralf at wonderer.de) Date: Mon, 03 Mar 2008 16:04:13 +0100 Subject: [opengeodb] Problematik beim Einzeichnen von Punkten auf einer Karte In-Reply-To: References: Message-ID: <47CC136D.5010901@wonderer.de> Hallo Jan-Simon, > ich arbeite gerade daran bestimmte Koordinaten auf einer Deutschlandkarte > einzuzeichnen. > Hat da jemand eine > Quelle? Ich habe da bei Wikipedia angefangen. http://de.wikipedia.org/wiki/Entfernungsberechnung Über die Suche nach "Orthodrome" findest du noch weitere Seiten dazu. Im Prinzip habe ich versucht die Wölbung der Erdkugel auf ein 2D-Netz zu projezieren. Dies ist aber nicht ohne Genauigkeitsverluste möglich. Du benötigst dazu von der Karte von den Rändern die Längen-/Breitengrade. Dann kannst du auf dem 2D-Netz den Punkt berechnen, indem du über die Orthdrome die Entfernung berechnest vom Rand der Karte zu der Stadt. Diese muss dann noch auf den Maßstab heruntergerechnet werden. Bei Bedarf kann ich dir auch ein Stück Quellcode (PHP) schicken. Grüße aus Sachsen, Ralf... From traut at gmx.de Tue Mar 4 08:22:49 2008 From: traut at gmx.de (Martin Trautmann) Date: Tue, 04 Mar 2008 08:22:49 +0100 Subject: [opengeodb] Problematik beim Einzeichnen von Punkten auf einer Karte In-Reply-To: References: Message-ID: <47CCF8C9.6020806@gmx.de> Jan-Simon Winkelmann wrote: > Da ich aber sowieso anderes Kartenmaterial nutzen muss das besser an > eines meiner Website-Designs angepasst ist stellt sich f=FCr mich die > Frage wie ich die ben=F6tigten Werte selbst berechnen kann. Sinnvolle > Informationen dazu hab ich leider nirgends gefunden. Hat da jemand eine > Quelle? Am einfachsten kannst du vorgehen, wenn du deine Kartengrundlage selbst erstellst - so weisst du, dass unter der Annahme korrekter Grenzverlaufs-Koordinaten auch die von dir hinzugefügten Punkte nach genau der gleichen Projektion erfolgen und dass die (rechteckigen) Bildgrenzen auf exakt von dir vorgegebenen Koordinaten erfolgen. Beispielsweise habe ich http://fa-technik.adfc.de/code/Codier-Anbieter.png auf diese Art erstellt: hier wurden Einzelpunkte des Grenzverlaufs als Hintergrundkarte erstellt. Leider liegen mir keine entsprechenden Grenzen der Bundesländer vor. Diese Karte habe ich händisch nachbearbeitet, um die Grenzpixel lückenlos zu schliessen und Artefakte mit zu dicken Konturen zu korrigieren. Das ganze wurde als reine ASCII-Grafik aus einer Datenbank heraus erstellt (fixed width font, 2 pixel font size), weil dort keine besseren Methoden existieren. Leistungsfähiger ist das Zeichnen der Grenzen als echte Polygone - damit lässt sich auch dynamisch hineinzoomen. Sieh dir beispielsweise openstreetmap.org an, um einen Eindruck von aktuelleren Möglichkeiten zu bekommen. Für deine Zwecke solltest du herumexperimentieren, ob du für das vorliegende Kartenmaterial die Randkoordinaten genauer bestimmen kannst - eigentlich gehören die unmittelbar in die zugehörige Doku. Letzendlich ausschlaggebend ist das Projektionsverfahren - wenn die Karte hier anders arbeitet als du mit deinem Ansatz, dann kann das nur sehr grob zusammenpassen. Schönen Gruß Martin From amuelle1 at gmx.de Tue Mar 4 10:58:13 2008 From: amuelle1 at gmx.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Tue, 4 Mar 2008 10:58:13 +0100 Subject: [opengeodb] =?iso-8859-1?q?Konzept_so_noch_ze_itgem=E4=DF_=3F?= In-Reply-To: <20080228135922.M1513@agisb.com> References: <20080228135922.M1513@agisb.com> Message-ID: <085001c87dde$44710b50$b6c80ac0@nbandreas> Hallo zusammen, das Problem was hier angesprochen wird ist meiner Ansicht nach folgendes: Für die Erfassung und Aufbewahrung der Daten gibt es andere Anforderungen an die Datenstruktur als für die Verwendung der Daten. Diesen sachverhalt findet man fast immer wenn es um die Erarbeitung und Nutzbarmachung von Daten geht. Ein kleines Beispiel für die Daten hier: Klar ist es sinnvoll historische Daten im Erfassungssystem zu haben - vielleicht braucht die ja jemand mal. Aber für eine aktuelle Umkreissuche, Größenbewertung von Orten etc. brauche ich nur die Daten von heute - nicht wie es vor 2 Jahre war. D.h. hier brauche ich nur die aktuellen Daten und keine Historier die mir meine Datenbank nur aufbläht und verkompliziert. Vielen hier reicht z.B. eine Tabelle sagen wir mit: - Ort - Ortsteil - Land - Bundesland - PLZ - Vorwahl - Koordinaten für den häufigsten Anwendungsfall einer Umkreissuche o.ä. Da dürfen dann auch redundanzen drin sein weil wir reden hier von einer einzigen Tabelle die man in sein System einbindet und gut ist. Nun kommt erschwerend hinzu das viele Datennutzer nicht mit den Erfassungsdaten umgehen können und daraus ihre Daten so extrahieren können wie sie sie brauchen. Als Entwickler der Daten und Manager der Erfassungsstruktur ist einem das oft nicht klar das andere da vor einem unüberschauberen für sie nicht beherrschbaren Problem stehen. Wenn man sich die Liste man ansieht kommen viele Fragen und Probleme genau aus dem Bereich. Ich würde daher Vorschlagen das man Anwendungsfälle definiert und für diese Anwendungsfälle parallel zu den Rohdaten im Erfassungsformat spezilisierte Datenbestände anbietet um die Anwendungsfälle damit zu bedienen. Diese Formate sollten dann möglichst dauerhaft konstant bleiben das man hier automatisierte Werkzeuge verwenden kann. Änderungen sollte man so gestalten das für eine Übergangszeit altes und neues Format parallel verfügbar ist. Über das Datenformat würde ich mir weniger Gedanken machen denn die Datenbankwelt ist so bunt das man kein für alle passendes einheitliches Format finden wird. Ich plädire bei soetwas immer für UTF-8 kodierte CSV (aber richtiges CSV mit Escaping etc.) oder Tab-Limited-Text. In beiden Fällen muss man sich noch über die Kodierung von Zeilenumbrüchen in Strings einigen - ich verwende da hauptsächlich eine Textumschreibung wie "\r\n". Auf keinen Fall würde ich XML nehmen da hier der Overhead und der Verarbeitungsaufwand in keinem Verhältnis zum Nutzen steht - nicht für solche Daten. Auch würde ich keine MySQL Dump nehmen - denn ein Oracle Benutzer kann damit nichts anfangen. Diesem erst zu erklären er muss sich irgendwo MySQL installieren, das dort einspielen und dann irgendwie von da in sein Oracle bekommen führt eher dazu das der Benutzer die finger davon lässt oder es genau einmal macht und danach mit veralteten Daten lebt. Das ganze was ich hier schreibe sind langjährige Erfahrungen aus der Praxis mit Daten im Automobil-Bereich. Wenn man das alles sauber aufbaut, dokumentiert und kommuniziert gibt es keinen Ärger mehr. Gruß, Andreas -- +--------------------------------------------------+ | Nur zwei Dinge sind unendlich: | | Das Weltall und die menschliche Dummheit. | | Beim Weltall bin ich mir aber nicht ganz sicher. | | | | ~Albert Einstein~ | +--------------------------------------------------+ From froschpopo at gmx.de Sat Mar 15 20:32:29 2008 From: froschpopo at gmx.de (Lucas Mengel) Date: Sat, 15 Mar 2008 20:32:29 +0100 Subject: [opengeodb] text_type In-Reply-To: <47DA2B36.3050101@gmx.de> References: <518806081@web.de> <47B1ED45.1090804@wonderer.de> <47DA2B36.3050101@gmx.de> Message-ID: <47DC244D.7070804@gmx.de> Gibts eigentlich irgendwo eine Übersicht über die ganzen text_type's? ich hab irgendwie kein Bock mehr zu erraten was 500******* usw. bedeutet. From froschpopo at gmx.de Sun Mar 16 10:20:51 2008 From: froschpopo at gmx.de (Lucas Mengel) Date: Sun, 16 Mar 2008 10:20:51 +0100 Subject: [opengeodb] Berlin Kreuzberg In-Reply-To: <47DC244D.7070804@gmx.de> References: <518806081@web.de> <47B1ED45.1090804@wonderer.de> <47DA2B36.3050101@gmx.de> <47DC244D.7070804@gmx.de> Message-ID: <47DCE673.4020804@gmx.de> Uch korrigiere: große Webseiten wie Kwick.de etc. scheinen doch nicht die opengeodb zu nutzen. Eine Abfrage im Anmeldeformular auf http://www.kwick.de ergibt bei der Postleitzahl 10969 die Ergebnisse "Berlin" und "Berlin Kreuzberg". Kreuzberg ist in der opengeodb jedoch überhaupt nicht eingetragen. Hat jemand eine Ahnung, welche Datenbank die nutzen könnten? Gruß, Luke From froschpopo at gmx.de Sun Mar 16 13:23:38 2008 From: froschpopo at gmx.de (Lucas Mengel) Date: Sun, 16 Mar 2008 13:23:38 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <1113821737.20080316124440@gmx.de> References: <518806081@web.de> <47B1ED45.1090804@wonderer.de> <47DA2B36.3050101@gmx.de> <47DC244D.7070804@gmx.de> <47DCE673.4020804@gmx.de> <1113821737.20080316124440@gmx.de> Message-ID: <47DD114A.4050705@gmx.de> Ich hab mir jetzt ein Statement gebastelt, welches nach Eingabe einer Postleitzahl die zu dieser Postleitzahl gehördenden Koordinaten und Stadtnamen ausgibt: SELECT a.text_type, a.text_val, a.loc_id, c.lon, c.lat FROM geodb_textdata a, geodb_textdata b, geodb_coordinates c WHERE a.text_locale = 'de' AND a.text_type = 500100000 AND b.loc_id = a.loc_id AND b.text_type = 500300000 AND b.text_val = 8000 AND c.loc_id = b.loc_id die 8000 ist die PLZ von Zürich. Das Ergebnis ist auch korrekt, aber leider unerwünscht, weil ich eigentlich nur deutsche Ergebnisse haben will! Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf Deutschland? Gruß, Luke From froschpopo at gmx.de Sun Mar 16 15:07:15 2008 From: froschpopo at gmx.de (Lucas Mengel) Date: Sun, 16 Mar 2008 15:07:15 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: References: <518806081@web.de> <47B1ED45.1090804@wonderer.de> <47DA2B36.3050101@gmx.de> <47DC244D.7070804@gmx.de> <47DCE673.4020804@gmx.de> <1113821737.20080316124440@gmx.de> <47DD114A.4050705@gmx.de> Message-ID: <47DD2993.9010302@gmx.de> Dann bekomme ich, insofern es die geodb irgendwann mal vorsieht, auch französische. Aber mal eine andere Frage: Schweiz, Liechtenstein und Österreich haben ja vierstellige Postleitzahlen. Wie könnte ich diese dann deinem Vorschlag nach voneinander unterscheiden? Gruß, Lucas From robert.boeck at googlemail.com Sun Mar 16 18:35:54 2008 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Sun, 16 Mar 2008 18:35:54 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47DD114A.4050705@gmx.de> References: <518806081@web.de> <47B1ED45.1090804@wonderer.de> <47DA2B36.3050101@gmx.de> <47DC244D.7070804@gmx.de> <47DCE673.4020804@gmx.de> <1113821737.20080316124440@gmx.de> <47DD114A.4050705@gmx.de> Message-ID: Hi Lucas, Lucas Mengel wrote: > Ich hab mir jetzt ein Statement gebastelt, welches nach > Eingabe einer Postleitzahl die zu dieser Postleitzahl > gehördenden Koordinaten und Stadtnamen ausgibt: > > SELECT > a.text_type, > a.text_val, > a.loc_id, > c.lon, > c.lat > FROM > geodb_textdata a, > geodb_textdata b, > geodb_coordinates c > WHERE > a.text_locale = 'de' AND > a.text_type = 500100000 AND > b.loc_id = a.loc_id AND > b.text_type = 500300000 AND > b.text_val = 8000 AND > c.loc_id = b.loc_id > > > die 8000 ist die PLZ von Zürich. Das Ergebnis ist auch > korrekt, aber leider unerwünscht, weil ich eigentlich nur > deutsche Ergebnisse haben will! > Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf > Deutschland? Hmmm, gute Frage. :-) Ich habe mir vor längerer Zeit mal eine Abfrage geschnitzt, die alle Postleitzahlen von Bayern ausspuckt: SELECT plz.loc_id as l_plz, plz.text_val as t_plz FROM geodb_hierarchies hi, geodb_textdata land, geodb_textdata bundesland, geodb_textdata plz 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 hi.loc_id=hi.id_lvl6 AND plz.loc_id=hi.loc_id AND plz.text_type=500300000 ORDER BY l_plz, t_plz Du müsstest sehen, was du davon verwerten kannst. Ich stecke da momentan auch nicht richtig drin, hatte schon seinerzeit meine Schwierigkeiten, da durchzublicken, weil die SQL-Datenstruktur ein einziger Saustall ist, von Normalisierung keine Spur. Möglicherweise hilft es, in deinem SQL-Statement WHERE a.text_locale = 'de' AND a.text_type = 500100000 AND durch WHERE a.text_val='DE' AND a.text_type=500100001 AND zu ersetzen. BTW, was hieltest du davon, statt den Aliasen a, b, c "sprechende" Aliase zu verwenden? Dann würde man bei deinem SQL-Statement eher durchblicken ... cu, Robo :) From traut at gmx.de Sun Mar 16 20:03:32 2008 From: traut at gmx.de (Martin Trautmann) Date: Sun, 16 Mar 2008 20:03:32 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47DD114A.4050705@gmx.de> References: <518806081@web.de> <47B1ED45.1090804@wonderer.de> <47DA2B36.3050101@gmx.de> <47DC244D.7070804@gmx.de> <47DCE673.4020804@gmx.de> <1113821737.20080316124440@gmx.de> <47DD114A.4050705@gmx.de> Message-ID: <47DD6F04.1010806@gmx.de> Lucas Mengel wrote: > > die 8000 ist die PLZ von Zürich. Das Ergebnis ist auch > korrekt, aber leider unerwünscht, weil ich eigentlich nur > deutsche Ergebnisse haben will! > Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf > Deutschland? Du solltest eben Merkmale verwenden, die gezielt auf Deutschland abheben: - verwende nur den deutschen Datenbestand (D.sql) - verwende die hierarchies - die stehen separat zur Verfügung http://fa-technik.adfc.de/code/opengeodb/dump/Dhier.sql - erzeuge dir die hierachies oder andere Markierungen selbst ueber die "Teil-von"-Beziehungen Drei verschiedene Ansaetze, die alle zum Erfolg fuehren koennen und alle auf der Information aufbauen, dass ein Eintrag zu Deutschland gehoert. Die Frage wurde hier aber schon mehrfach gestellt - eine Suche in den Archiven mag helfen. Schoenen Gruss Martin From amuelle1 at gmx.de Sun Mar 16 20:15:54 2008 From: amuelle1 at gmx.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Sun, 16 Mar 2008 20:15:54 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten Message-ID: <06a601c8879a$286c5200$1400a8c0@nbandreas> Hallo zusammen, nachdem ich mir gerade die aktuelle Datenstruktur genau angesehen habe kann ich jeden der mit den Daten massive Probleme hat sehr gut verstehen. Ich würde daher vorschlagen ein Teilprojekt zu starten das parallel zum erscheinen der Original-DB passende Daten zur Verfügung stellt um die Verwendung der Daten zu vereinfachen. So ist es z.B. im Moment nicht mehr möglich mit nur einer SQL Abfrage zuverlässig eine Liste aller deutschen Ort mit PLZ und Koordinaten zu bekommen. Erst ein algorithmisches durchhangeln durch in der Text-Tabelle (!!!TEXT!!!) verküpften Hierachiebenen führt hier zum Erfolg. Die angebotenenen "Dhier.sql" Dateien oder was auch immer erscheinen nicht mit der Hauptdatenbank und stellen somit keine korrekte alternative dar. Ich weiss nicht wer das noch blicken soll. Die Dokumentationen stimmen nicht mehr, wichtige Daten werden einfach mal weggelassen und in der Text-Tabelle verhackstückt - lustig wenn ich dann überall casten muss um einen Join bauen zu können usw. Wenn die "Teil von" etc. Logik wenigstens eine Bit-Map wäre das man von einem Ort auch direkt auf das Land schließen könnte ... Vielleicht schließen sich ja ein paar betroffene zusammen und finden hier gemeinsam eine Lösung - so jedenfalls sind die Daten unbrauchbar da kaum zu beherrschen. Gruß, Andreas From traut at gmx.de Sun Mar 16 20:35:01 2008 From: traut at gmx.de (Martin Trautmann) Date: Sun, 16 Mar 2008 20:35:01 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <06a601c8879a$286c5200$1400a8c0@nbandreas> References: <06a601c8879a$286c5200$1400a8c0@nbandreas> Message-ID: <47DD7665.9020203@gmx.de> Andreas Müller wrote: > Hallo zusammen, > > nachdem ich mir gerade die aktuelle Datenstruktur genau angesehen habe kann > ich jeden der mit den Daten massive Probleme hat sehr gut verstehen. > Ich würde daher vorschlagen ein Teilprojekt zu starten das parallel zum > erscheinen der Original-DB passende Daten zur Verfügung stellt um die > Verwendung der Daten zu vereinfachen. Ich würde viel eher empfehlen, passende Scripts zur Verfügung zu stellen, wie man aus einem allgemeinen und universellen Bestand die Dinge rausfiltern kann, die man selbst braucht. Es ist IMHO unmöglich, die Daten in jeder erdenklichen und nötigen Form anzubieten. Einer braucht nur die Gemeinden, einer nur die Vorwahlen, viele nur die PLZ-Gebiete usw. > So ist es z.B. im Moment nicht mehr möglich mit nur einer SQL Abfrage > zuverlässig eine Liste aller deutschen Ort mit PLZ und Koordinaten zu > bekommen. Erstens ist das falsch, zweitens ist das IMHO nciht nötig. > Erst ein algorithmisches durchhangeln durch in der Text-Tabelle > (!!!TEXT!!!) verküpften Hierachiebenen führt hier zum Erfolg. Die > angebotenenen "Dhier.sql" Dateien oder was auch immer erscheinen nicht mit > der Hauptdatenbank und stellen somit keine korrekte alternative dar. Dhier ist aber genau das, was du verlangst: redundante Ergänzungsdaten, weil entweder SQL oder die SQL-Fähigkeiten zu beschränkt sind, um diese Daten selbst abzuleiten. > Ich weiss nicht wer das noch blicken soll. Ich auch nicht - ich verwende daraus nur jene Daten, die mich interessieren. > Die Dokumentationen stimmen nicht > mehr, weil niemand sie korrigiert. Es ist einfacher, darüber zu klagen, als sie zu verbessern. > wichtige Daten werden einfach mal weggelassen und in der Text-Tabelle > verhackstückt - lustig wenn ich dann überall casten muss um einen Join bauen > zu können usw. Wenn die "Teil von" etc. Logik wenigstens eine Bit-Map wäre > das man von einem Ort auch direkt auf das Land schließen könnte ... Dir wäre das Land wichtig - anderen vielleicht nur das Bundesland. > Vielleicht schließen sich ja ein paar betroffene zusammen und finden hier > gemeinsam eine Lösung - so jedenfalls sind die Daten unbrauchbar da kaum zu > beherrschen. Meine Motivation ist hier beschränkt, meine Zeit noch viel mehr. Beispielsweise hat sich seit Monaten niemand gefunden, mal eine brauchbare README-Datei zu schreiben. Ich würde mich viel lieber auf die Teile konzentrieren, die mir niemand abnehmen kann. Schönen Gruß Martin From amuelle1 at gmx.de Sun Mar 16 21:17:44 2008 From: amuelle1 at gmx.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Sun, 16 Mar 2008 21:17:44 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <47DD7665.9020203@gmx.de> References: <06a601c8879a$286c5200$1400a8c0@nbandreas> <47DD7665.9020203@gmx.de> Message-ID: <075d01c887a2$cb6ba3e0$1400a8c0@nbandreas> Hallo Martin, > Ich würde viel eher empfehlen, passende Scripts zur Verfügung zu > stellen, wie man aus einem allgemeinen und universellen Bestand die > Dinge rausfiltern kann, die man selbst braucht. Es ist IMHO > unmöglich, > die Daten in jeder erdenklichen und nötigen Form anzubieten. Einer > braucht nur die Gemeinden, einer nur die Vorwahlen, viele nur die > PLZ-Gebiete usw. Script? Auf welcher Basis denn? PHP? Hat jeder PHP? Win32 Binaries? Hat jeder Windows? Es ist nicht notwendig die Daten in ALLEN nötigen Formaten aufzubereiten. Es gibt Standard-Anwendungebiete die man definieren und versorgen muss. Wem das nicht reich kann immer noch die Originaldaten nehmen. Aber ich würde behaupten das man 80% erschlagen kann. > > So ist es z.B. im Moment nicht mehr möglich mit nur einer > SQL Abfrage > > zuverlässig eine Liste aller deutschen Ort mit PLZ und > Koordinaten zu > > bekommen. > > Erstens ist das falsch, zweitens ist das IMHO nciht nötig. So wo ist das denn falsch? Ich muss mich durch eine Hierachie quälen bei der nicht festgelegt ist das jedes Element die gleichen Ebenen durchläuft. Daher ist es nicht möglich mit einer SQL Abfrage eine Liste "Land,Ort,Ortsteil,PLZ,Koordinaten" abzufragen. Den allgemeinen Gegenbeweis OHNE eine potentiell nicht datensyncrone, weil nicht dazu veröffentlichte "geodb_hierarchies" Tabelle. > > Erst ein algorithmisches durchhangeln durch in der Text-Tabelle > > (!!!TEXT!!!) verküpften Hierachiebenen führt hier zum Erfolg. Die > > angebotenenen "Dhier.sql" Dateien oder was auch immer > erscheinen nicht mit > > der Hauptdatenbank und stellen somit keine korrekte alternative dar. > > Dhier ist aber genau das, was du verlangst: redundante > Ergänzungsdaten, > weil entweder SQL oder die SQL-Fähigkeiten zu beschränkt > sind, um diese > Daten selbst abzuleiten. Na das ist ja toll nur kann man im Moment keine Daten herunterladen die definiv zusammenpassen. Sonst müssten die Daten zusammen mit den Originaldaten veröffentlicht werden. Es kann nicht sein das ich auf SF.net mit die Originaldaten besorge und dann irgendwo im Netz eine hoffenlich passende andere Landesspezifische Verknüpfungsdatei herunterlade. Wirklich "redundat" sind die Daten nicht wirklich da sie sich nicht via SQL wiederherstellen lassen - zumindest in der heutigen Form nicht. Genausowenig wenn man Datentypen wild mischt - oder was hat eine loc_id in der Text-Tabelle zu suchen? > > > Die Dokumentationen stimmen nicht > > mehr, > > weil niemand sie korrigiert. Es ist einfacher, darüber zu klagen, als > sie zu verbessern. Verbessern wird sowas nur jemand der sich für die Datenstrukur Entwicklung verantwortlich sieht. Derjenige der die Datenstruktur ändert hat auch die Doku anzupassend. > > wichtige Daten werden einfach mal weggelassen und in der > Text-Tabelle > > verhackstückt - lustig wenn ich dann überall casten muss um > einen Join bauen > > zu können usw. Wenn die "Teil von" etc. Logik wenigstens > eine Bit-Map wäre > > das man von einem Ort auch direkt auf das Land schließen könnte ... > > Dir wäre das Land wichtig - anderen vielleicht nur das Bundesland. An und dann gibts halt ne Spalte mehr mit Bundesland. Wir reden hier nicht von redundanzfreien Erfassungsdaten sondern von praktisch verarbeitbaren Daten in einer (Web-)Anwendung. Und vor allem von Daten die ein nicht opengeodb Profi lesen, verstehen und verarbeiten kann. Wir reden von wenigen MB Daten, von SQL Servern mit der Möglichkeit von Indizes etc. > > Vielleicht schließen sich ja ein paar betroffene zusammen > und finden hier > > gemeinsam eine Lösung - so jedenfalls sind die Daten > unbrauchbar da kaum zu > > beherrschen. > > Meine Motivation ist hier beschränkt, meine Zeit noch viel mehr. > Beispielsweise hat sich seit Monaten niemand gefunden, mal eine > brauchbare README-Datei zu schreiben. Ich würde mich viel > lieber auf die > Teile konzentrieren, die mir niemand abnehmen kann. Nun falls die README das Datenmodell beschreibe soll dann siehe oben. Ich befürchte das die Hürde durch das Konstrukt durchzublicken so groß ist das sich da niemand rantraut. Nochmal: Ich finde die Struktur für eine Erfassungsdatenbank ja nichtmal dumm. Abgesehen von ein paar kleinen Inkonsequenzen verstehe ich den Aufbau nur zu gut. Nur verstehe ich alle die damit nicht klarkommen um mit den Daten zu arbeiten - und das kann man hier auf der Liste eindrucksvoll verfolgen. Gruß, Andreas From traut at gmx.de Sun Mar 16 21:49:46 2008 From: traut at gmx.de (Martin Trautmann) Date: Sun, 16 Mar 2008 21:49:46 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <075d01c887a2$cb6ba3e0$1400a8c0@nbandreas> References: <06a601c8879a$286c5200$1400a8c0@nbandreas> <47DD7665.9020203@gmx.de> <075d01c887a2$cb6ba3e0$1400a8c0@nbandreas> Message-ID: <47DD87EA.9070808@gmx.de> Andreas Müller wrote: > Hallo Martin, > >> Ich würde viel eher empfehlen, passende Scripts zur Verfügung zu >> stellen, wie man aus einem allgemeinen und universellen Bestand die >> Dinge rausfiltern kann, die man selbst braucht. Es ist IMHO >> unmöglich, >> die Daten in jeder erdenklichen und nötigen Form anzubieten. Einer >> braucht nur die Gemeinden, einer nur die Vorwahlen, viele nur die >> PLZ-Gebiete usw. > > Script? Auf welcher Basis denn? PHP? Hat jeder PHP? Win32 Binaries? Hat > jeder Windows? Mir ist schnuppe, wie du z.B. ein SQL-Makro definierst oder welches andere Hilfsmittel du verwenden willst - dein Problem. Mein Werkzeug ist Perl, um für dich SQL daraus abzuleiten. >> Erstens ist das falsch, zweitens ist das IMHO nciht nötig. > > So wo ist das denn falsch? Ich muss mich durch eine Hierachie quälen bei der > nicht festgelegt ist das jedes Element die gleichen Ebenen durchläuft. Genau dafür kannst du die hierarchies verwenden. > Den allgemeinen Gegenbeweis > OHNE eine potentiell nicht datensyncrone, weil nicht dazu veröffentlichte > "geodb_hierarchies" Tabelle. Es gab hier mal laute Proteste, warum die hierarchies wer wären. Also setze ich mich hin, leitete diese redundanten hierachies ab, stellte sie bereit - und bekam null Rückmeldung, ob damit das Problem nun gelöst wäre. Ebensowenig hat sich keiner der SQL-Experten genäussert, wo denn nun das Problem sei, das innerhalb on SQL zu machen. Meckern ist leichter... > Na das ist ja toll nur kann man im Moment keine Daten herunterladen die > definiv zusammenpassen. Sonst müssten die Daten zusammen mit den > Originaldaten veröffentlicht werden. Es kann nicht sein das ich auf SF.net > mit die Originaldaten besorge und dann irgendwo im Netz eine hoffenlich > passende andere Landesspezifische Verknüpfungsdatei herunterlade. Richtig, das kann nicht sein. Das wäre auch ziemlicher Schmarrn, Sachen zusammenzupacken, die nicht zusammenpassen. > Wirklich "redundat" sind die Daten nicht wirklich da sie sich nicht via SQL > wiederherstellen lassen - zumindest in der heutigen Form nicht. Ach, du glaubst, ich hätte irgendwo noch kleine Geheimdaten, weil ich es schaffe, ohne SQL für SQL genau jene Daten abzuleiten, wo sich niemand bereit fand, dafür eine Lösung komplett innerhalb von SQL vorzunehmen? Den entsprechenden Lösungsweg hatte ich wiederholt geschildert. Wenn SQL als angeblich so überlegenes Hilfsmittel nicht in der Lage ist, damit die nötigen Operationen vorzunehmen, dann würde ich doch erhebliche Zweifel an der Tauglichkeit dieses Werkzeugs haben. > Genausowenig > wenn man Datentypen wild mischt - oder was hat eine loc_id in der > Text-Tabelle zu suchen? Du pickst dir gerne raus, wann du die reine Lehre willst und wann du pragmatische Vereinfachungen suchst. Dann erkläre mir bitte, was nach reiner Lehre wohin gehören muss, dann bin ich vielleicht bereit, das für dich auch so zu modellieren. Ich habe aber keine Lust, mir auch noch selbst die Stöckchen zu suchen, über die du mich springen lassen willst. > Verbessern wird sowas nur jemand der sich für die Datenstrukur Entwicklung > verantwortlich sieht. Derjenige der die Datenstruktur ändert hat auch die > Doku anzupassend. Diese Datenstruktur ist nicht plötzlich so festgelegt worden, sondern hat sich so entwicklet, weil immer wieder irgend jemand hier und da nochwas dazu wollte. Ich warte noch immmer auf deinen grossen Wurf, wie es besser zu machen wäre... > An und dann gibts halt ne Spalte mehr mit Bundesland. und noch eine fuer den Regierungsbezirk und noch eine fuer den Kreis und noch eine fuer die Gemeinde - sprich, du willst irgendwann doch einfach nur die hierarchies? > Wir reden hier nicht > von redundanzfreien Erfassungsdaten sondern von praktisch verarbeitbaren > Daten in einer (Web-)Anwendung. Nein, davon reden wir nicht. Ich rede von opengeodb, von offenen Geodaten. Mir geht's primär um die Daten, um die Inhalte. SQL ist nur ein Vehikel. Daraus kann sich jeder ableiten, was er braucht. Wer eine fertige Web-Anwendung will, der möge sich diese irgendwo besorgen. Vielleicht könnte opengeodb auch dies bieten - aber nicht von mir. Wer das haben will, soll sich eine fertige Web-Anwendung kaufen. > Und vor allem von Daten die ein nicht > opengeodb Profi lesen, verstehen und verarbeiten kann. Ich behaupte mal, fuer den Nicht-Profi gibt es nichts einfacheres und verstaendlicheres als die .tab-Dateien. Die kann er nämlich direkt mit Excel aufmachen... > Nun falls die README das Datenmodell beschreibe soll dann siehe oben. Ich > befürchte das die Hürde durch das Konstrukt durchzublicken so groß ist das > sich da niemand rantraut. Dafür gibt's eine mailing list, wo man fragen kann. Gruss, Martin From amuelle1 at gmx.de Sun Mar 16 22:25:51 2008 From: amuelle1 at gmx.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Sun, 16 Mar 2008 22:25:51 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <47DD87EA.9070808@gmx.de> References: <06a601c8879a$286c5200$1400a8c0@nbandreas> <47DD7665.9020203@gmx.de><075d01c887a2$cb6ba3e0$1400a8c0@nbandreas> <47DD87EA.9070808@gmx.de> Message-ID: <080b01c887ac$4ff4b120$1400a8c0@nbandreas> Hallo Martin, > Mir ist schnuppe, wie du z.B. ein SQL-Makro definierst oder welches > andere Hilfsmittel du verwenden willst - dein Problem. Mein > Werkzeug ist > Perl, um für dich SQL daraus abzuleiten. wenn du Tools für jeden Vorschlängst ist es nur verständlich das diese Frage kommt oder? > Genau dafür kannst du die hierarchies verwenden. Die es aber nicht mehr konsistent zu den Daten gibt! > Es gab hier mal laute Proteste, warum die hierarchies wer wären. Also > setze ich mich hin, leitete diese redundanten hierachies ab, > stellte sie > bereit - und bekam null Rückmeldung, ob damit das Problem nun gelöst > wäre. Ebensowenig hat sich keiner der SQL-Experten > genäussert, wo denn > nun das Problem sei, das innerhalb on SQL zu machen. Meckern > ist leichter... Nun es ist immer die Frage wie man ein Problem löst. So ist es aber keine Lösung da du feste Feldzuordnungen für die Hierarchieebenen wegoptimiert hast. Wäre jede Spalte der alten Tabelle via Type abfragbar wäre das anders - dann hätte man aber wieder redundante Daten. > Richtig, das kann nicht sein. Das wäre auch ziemlicher > Schmarrn, Sachen > zusammenzupacken, die nicht zusammenpassen. Du willst mir jetzt aber nicht erklären das die "geodb_hierarchies" nicht zu den anderen Tabellen gehört? Jede neue loc_id hat hier einer Änderung zur Folge - daher gehören die Daten dazu und wenn es als separater aber gleich versionierer Dump ist. Aber der heutig unversionierte download ist murks. Versioniere es einfach mit und veröffentliche es parallel und schon ist diesbezüglich alles in Butter. > Ach, du glaubst, ich hätte irgendwo noch kleine Geheimdaten, > weil ich es > schaffe, ohne SQL für SQL genau jene Daten abzuleiten, wo > sich niemand > bereit fand, dafür eine Lösung komplett innerhalb von SQL > vorzunehmen? > Den entsprechenden Lösungsweg hatte ich wiederholt > geschildert. Wenn SQL > als angeblich so überlegenes Hilfsmittel nicht in der Lage ist, damit > die nötigen Operationen vorzunehmen, dann würde ich doch erhebliche > Zweifel an der Tauglichkeit dieses Werkzeugs haben. Nö das denke ich nicht - so ein quatsch. Nur halte ich es für falsch ein Datenstruktur durch eine andere Datenstruktur abzulösen wenn erste nich mit einfachen Mitteln wiederhergestellt werden kann. Jetzt muss man mit großem Aufwand diese Daten wiederstellen. Vielleicht ist dir ja das Problem noch nich klar: Seit der Änderung ist nicht mehr klar wieviel KONSTANTE Ebenen ich absteigen muss um z.B. Land oder Bundesland abzufragen. Das ist nun variabel und nicht mehr mit vertretbaren Aufwand (ohne massive UNIONS und Abfrage aller Möglichkeiten) machbar. Früher konnte ich geziehlt auf eine Spalte zugreifen und hatte meine ID's. > Du pickst dir gerne raus, wann du die reine Lehre willst und wann du > pragmatische Vereinfachungen suchst. Dann erkläre mir bitte, was nach > reiner Lehre wohin gehören muss, dann bin ich vielleicht > bereit, das für > dich auch so zu modellieren. Ich habe aber keine Lust, mir auch noch > selbst die Stöckchen zu suchen, über die du mich springen > lassen willst. Ich picke mir hier garnix raus sondern stelle nur fest das ich heute für JOINS eine loc_id (int) mit einer text_val (varchar) Spalte verwenden muss was nicht alle Datenbanksysteme so einfach mitmachen. Muss ich dann auf Cast-Funktionen zurückgreifen bleibt er Optimizer meist auf der Strecke. Ich sage ja blos das gibts eine Tabelle "geodb_intdata". Wenn wir schon datentypspezifische Tabellen haben dann sollen Integer Werte auch zu Integerwerten. > Diese Datenstruktur ist nicht plötzlich so festgelegt worden, sondern > hat sich so entwicklet, weil immer wieder irgend jemand hier und da > nochwas dazu wollte. Ich warte noch immmer auf deinen grossen > Wurf, wie > es besser zu machen wäre... Ich hoffe du hast den Schluss der letzten Mail gelesen oder mein Posting vom 04.03.2008. Dann sollte dir das klar sein. > und noch eine fuer den Regierungsbezirk und noch eine fuer > den Kreis und > noch eine fuer die Gemeinde - sprich, du willst irgendwann > doch einfach > nur die hierarchies? Du solltest mal das lesen was ich geschriebe habe. Der Einwand mit den Bundesland kam von dir und es war nur ein Beispiel von mir was ich versuchte abzufragen. > Nein, davon reden wir nicht. Ich rede von opengeodb, von offenen > Geodaten. Mir geht's primär um die Daten, um die Inhalte. SQL ist nur > ein Vehikel. Daraus kann sich jeder ableiten, was er braucht. Mit "wir reden hier" bezog ich mich auf das Thema dieses Treads und nicht über den opengeodb als solche. Nochmal: Die Strukur der opengeodb ist für mich abgesehen von den Datentypschwächen und der verloren gegangenen direkten Hierarchieadressierung so perfekt für das was man mit opengeodb erreich will. > Wer eine fertige Web-Anwendung will, der möge sich diese irgendwo > besorgen. Vielleicht könnte opengeodb auch dies bieten - aber > nicht von > mir. Wer das haben will, soll sich eine fertige Web-Anwendung kaufen. Es hat ja keiner von dir verlangt die Daten anders bereitzustellen. Du wirs aber zugeben müssen das die Hauptprobleme hier dadurch entstehen das es extreme Verständnisprobleme und technische Unfähigkeiten der Anwender der Daten gibt. Nur das führt eben nicht dazu das diese sich zu helfen lernen - nein die werfen das Handtuch und kaufen sich eben irgendwo anders Daten die so aufbereitet sind wie sie sie in etwa brauchen. In deren Augen ist opengeodb dann "scheisse" und ein "saustall" weil es für sie nahezu unmöglich ist mit den Daten direkt sinnvoll zu arbeiten. Nur wenn das so weitergeht ist bald niemand mehr da der die Daten verwendet - und für wen macht man sich dann die Arbeit. Nur wenn die Daten auch (parallel!) in von den einfachen Anwendern leicht verwendbarer Form zur Verfügung gestellt werden (und ich sage NICHT das du das machen sollst - du sollst mal schön dich um die Daten kümmern wie heute) werden die Daten auch von einer bereiten Masse akzeptiert und verwendet! > Ich behaupte mal, fuer den Nicht-Profi gibt es nichts einfacheres und > verstaendlicheres als die .tab-Dateien. Die kann er nämlich > direkt mit > Excel aufmachen... Dafür gilt das gleiche wie oben? Gibts ja offiziell nicht parallel versioniert zum download. Woher soll man wissen was man da nun hat. Der Release-Inhalt und das Release-Management gilt es meiner Meinung nach genauso geradlinig zu bringen wie die Lernkurve für Standard-Anwendnungen abzuflachen. Für ersteres sehe ich dich in der Verantwortung - für letzteres definiv Leute hier auf der Liste die gemeinsam Standards definieren und diese aus den Daten füllen und bereitstellen. Gruß, Andreas From traut at gmx.de Sun Mar 16 22:45:54 2008 From: traut at gmx.de (Martin Trautmann) Date: Sun, 16 Mar 2008 22:45:54 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <080b01c887ac$4ff4b120$1400a8c0@nbandreas> References: <06a601c8879a$286c5200$1400a8c0@nbandreas> <47DD7665.9020203@gmx.de><075d01c887a2$cb6ba3e0$1400a8c0@nbandreas> <47DD87EA.9070808@gmx.de> <080b01c887ac$4ff4b120$1400a8c0@nbandreas> Message-ID: <47DD9512.1060106@gmx.de> Andreas Müller wrote: >> Genau dafür kannst du die hierarchies verwenden. > > Die es aber nicht mehr konsistent zu den Daten gibt! Warum nicht? In dem Moment, wo ich einen neuen Dump anstosse, kann ich dazu die Hierarchies passend erzeugen. Warum aber sollte ich das tun, wenn ich keine Rückmeldung bekomme, ob sie was taugen oder nicht. > Nun es ist immer die Frage wie man ein Problem löst. So ist es aber keine > Lösung da du feste Feldzuordnungen für die Hierarchieebenen wegoptimiert > hast. Die haben bisher funktioniert, wo wir nur bis zur Gemeinde-Ebene heruntergingen - und selbst da hatten wir nicht sauber getrennt zwischen Ort und Gemeinde. Wenn wir heute Daten ergänzen wollen, so kommen wir hinunter auf Ortsteil-Ebenen, wo die starren Hierarchien zunehmend nutzlos werden, wo aber deren Verwaltung einen enormen organisatorischen Pflegeaufwand bedeuten. >> Richtig, das kann nicht sein. Das wäre auch ziemlicher >> Schmarrn, Sachen >> zusammenzupacken, die nicht zusammenpassen. > > Du willst mir jetzt aber nicht erklären das die "geodb_hierarchies" nicht zu > den anderen Tabellen gehört? Die hierarchies werden zu einem bestimmten Zeitpunkt erzeugt und passen dann zu den Daten von diesem Zeitpunkt. Wenn du völlig unterschiedliche Releases zusammenwirfst, so wird das noch immer zu grossen Teilen passen - an den aktualisierten Ecken aber klemmen. > Nö das denke ich nicht - so ein quatsch. Nur halte ich es für falsch ein > Datenstruktur durch eine andere Datenstruktur abzulösen wenn erste nich mit > einfachen Mitteln wiederhergestellt werden kann. Jetzt muss man mit großem > Aufwand diese Daten wiederstellen. Ich denke, ich habe den Gegenbeweis angetreten, dass ich mit eigentlich ungeeigneteren Werkzeugen und wenig Aufwand diese Daten offensichtlich herstellen kann. Im Gegenteil wäre aber ein immenser Pflegeaufwand damit verbunden, die hierarchies mit zu korrigieren und zu versionieren. Den tue zumindest ich mir nicht an. Du kannst ja mal exemplarisch selbst versuchen, die Kreisreform in Sachsen-Anhalt über die hierachies nachzuziehen - das sollte für dich ja eine einfache Fingerübung sein... > Vielleicht ist dir ja das Problem noch nich klar: Seit der Änderung ist > nicht mehr klar wieviel KONSTANTE Ebenen ich absteigen muss um z.B. Land > oder Bundesland abzufragen. Dann erkläre es mir doch einfach. Wie viele konstante Ebenen brauchst du, um von Deutschland nach Berlin-Kreuzberg zu kommen? Und wie viele brauchst du bis München-Schwabing? Und wie viele bis zur Uferpromenade von Lausanne? > Ich picke mir hier garnix raus sondern stelle nur fest das ich heute für > JOINS eine loc_id (int) mit einer text_val (varchar) Spalte verwenden muss > was nicht alle Datenbanksysteme so einfach mitmachen. Auch das halte ich zumindest aus meiner Sicht für falsch. Es kann sein, dass du auch auf diesem Weg zum Ziel kommen kannst. Warum aber kannst du dir nicht die passenden Hilfsstrukturen hinzufügen, die dir das Leben leichter machen? > Ich hoffe du hast den Schluss der letzten Mail gelesen oder mein Posting vom > 04.03.2008. Dann sollte dir das klar sein. Mach's doch einfach mal. Wir haben jahrelang um den grossen Wurf herumgeredet, wie man die Bearbeitung der Daten am besten online zur Korrektur anbieten könnte. Aber keiner hat's gemacht. Sobald du etwas bessers anbieten kannst, ist es sicherlich sinnvoll, auf dein Angebot zu wechseln. > Es hat ja keiner von dir verlangt die Daten anders bereitzustellen. Du wirs > aber zugeben müssen das die Hauptprobleme hier dadurch entstehen das es > extreme Verständnisprobleme und technische Unfähigkeiten der Anwender der > Daten gibt. Genau deswegen sage ich ja: wenn du jemanden helfen willst, dann wäre eine Möglichkeit, dass du eben jene Dokumentation anfertigst, die ihm helfen kann. >> Ich behaupte mal, fuer den Nicht-Profi gibt es nichts einfacheres und >> verstaendlicheres als die .tab-Dateien. Die kann er nämlich >> direkt mit >> Excel aufmachen... > > Dafür gilt das gleiche wie oben? Gibts ja offiziell nicht parallel > versioniert zum download. Woher soll man wissen was man da nun hat. Sie sind tagaktuell, jederzeit verfügbar und sie werden begleitet von einem Protokoll der Änderungen, die jederzeit von jedermann korrigert werden können. Eine weitere Versionierung der Daten wäre ebenfalls einfach nur redundant. Sollte ich für jeden Benutzereintrag eine neue Version anlegen? Das würde ohnehin voraussetzen, dass Benutzer die Daten korrigieren würden... Gruss, Martin From amuelle1 at gmx.de Sun Mar 16 23:04:17 2008 From: amuelle1 at gmx.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Sun, 16 Mar 2008 23:04:17 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <47DD9512.1060106@gmx.de> References: <06a601c8879a$286c5200$1400a8c0@nbandreas> <47DD7665.9020203@gmx.de><075d01c887a2$cb6ba3e0$1400a8c0@nbandreas> <47DD87EA.9070808@gmx.de><080b01c887ac$4ff4b120$1400a8c0@nbandreas> <47DD9512.1060106@gmx.de> Message-ID: <006801c887b1$ae2412e0$1400a8c0@nbandreas> Hallo Martin, gut dem bleibt nichts hinzuzufügen wenn du dir nicht einmal die Arbeit machst zu lesen was ich geschieben habe. Gruß, Andreas -- +--------------------------------------------------+ | Nur zwei Dinge sind unendlich: | | Das Weltall und die menschliche Dummheit. | | Beim Weltall bin ich mir aber nicht ganz sicher. | | | | ~Albert Einstein~ | +--------------------------------------------------+ From andi at saerdnaer.de Sun Mar 16 23:26:04 2008 From: andi at saerdnaer.de (Andreas Hubel) Date: Sun, 16 Mar 2008 23:26:04 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <006801c887b1$ae2412e0$1400a8c0@nbandreas> References: <06a601c8879a$286c5200$1400a8c0@nbandreas> <47DD7665.9020203@gmx.de><075d01c887a2$cb6ba3e0$1400a8c0@nbandreas> <47DD87EA.9070808@gmx.de><080b01c887ac$4ff4b120$1400a8c0@nbandreas> <47DD9512.1060106@gmx.de> <006801c887b1$ae2412e0$1400a8c0@nbandreas> Message-ID: <44D31B0C-D969-4D86-A405-5B5606D97C4F@saerdnaer.de> Mach einfach was du vorhast und versuche möglichst viele Leute zu finden, die dir helfen falls, du welche brauchst. MfG Andi -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : PGP.sig Dateityp : application/pgp-signature Dateigröße : 186 bytes Beschreibung: This is a digitally signed message part URL : http://lists.phpbar.de/pipermail/opengeodb/attachments/20080316/bf073b81/attachment.pgp From stephan.s at gmx.net Mon Mar 17 00:23:36 2008 From: stephan.s at gmx.net (Stephan Schuster) Date: Mon, 17 Mar 2008 00:23:36 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <006801c887b1$ae2412e0$1400a8c0@nbandreas> References: <47DD9512.1060106@gmx.de> <006801c887b1$ae2412e0$1400a8c0@nbandreas> Message-ID: <20080317001518.92F4.STEPHAN.S@gmx.net> Hallo Andreas, > gut dem bleibt nichts hinzuzufügen wenn du dir nicht einmal die Arbeit > machst zu lesen was ich geschieben habe. man sollte das was man von anderen fordert auch selbst leisten. Du hast Dich hier in ziemlich rüdem Ton darüber beschwert, die Daten wären nicht zu durchblicken und "unbrauchbar" und hast Dir nicht die Mühe gemacht, auf Martins Argumente zu antworten. Dir stehen hier vor allem dank Martins Engagement eine Menge Informationen zur Verfügung die woanders jede Menge Geld kosten, und ohne ihn wären die Daten auf dem Stand von ca. 2005. Und Du beschwerst Dich, dass Dir das Format nicht taugt. Dann nimm einfach die (frei verfügbaren) Daten und bau Dir Deine Lösung zusammen und erwarte nicht, dass andere das für Dich machen! Und wenn Du was Gutes tun willst, stell Deine Lösung auch anderen zur Verfügung. Gruß Stephan From robert.boeck at googlemail.com Mon Mar 17 02:16:26 2008 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Mon, 17 Mar 2008 02:16:26 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: References: <518806081@web.de> <47B1ED45.1090804@wonderer.de> <47DA2B36.3050101@gmx.de> <47DC244D.7070804@gmx.de> <47DCE673.4020804@gmx.de> <1113821737.20080316124440@gmx.de> <47DD114A.4050705@gmx.de> Message-ID: Hallo Thomas, Thomas Preymesser wrote: > >> Jetzt meine Frage: Wie beschränke ich die Suchergebnisse auf > >> Deutschland? > > > ganz pragmatische Lösung: > > indem du nur PLZen zwischen '00000' und '99999' abfragst? > > > Sorry, aber wenn ich so einen Krampf lese, dann springt mir das Messer > in der Hosentasche auf! > > Die Lösung, die du da vorschlägst, hat nichts mit programmieren zu tun, > das ist Gefrickel aus der alleruntersten Schublade! > > > welchen Teil von "pragmatisch" hast du nicht verstanden? Du verwechselst "pragmatisch" mit "Gefrickel". > Lucas hat gefragt, wie er es verhindern kann, daß er nicht-Deutschland > Orte erhält, wenn er eine PLZ abfragt, die in Deutschland überhaupt > nicht existiert. Ich habe daraufhin geantwortet, daß er nur PLZen > abfragen soll, die in Deutschland möglich sind. > Daß das keine Abfrage auf ein beliebiges Land ist, ist mir völlig klar - > aber das war ja auch nicht die ursprüngliche Frage. Und genau das ist dein Problem. Nimm mal deine Scheuklappen ab und sieh über den Tellerrand deines begrenzten Horizontes hinaus. Mit dem Muster, mit dem du Postleitzahlen erkennen willst, die nur in Deutschland möglich sind, erkennst du auch Postleitzahlen, die in anderen Ländern möglich sind. Wenn man das von dir vorgeschlagene Gefrickel verwendet, gibt es spätestens dann einen ganz gewaltigen Knall, wenn die Opengeodb auf weitere Länder erweitert sind, die Postleitzahlen haben, die genauso aussehen, wie die in Deutschland. cu, Robo :) From froschpopo at gmx.de Mon Mar 17 02:16:50 2008 From: froschpopo at gmx.de (Lucas Mengel) Date: Mon, 17 Mar 2008 02:16:50 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <06a601c8879a$286c5200$1400a8c0@nbandreas> References: <06a601c8879a$286c5200$1400a8c0@nbandreas> Message-ID: <47DDC682.2070304@gmx.de> Hi Andreas! Solche Vorschläge haben wir hier schon öfters mal gelesen. Tatsache ist, dass der Datenbestand nicht einfach in einer einzigen Tabelle veröffentlicht werden kann. Es wäre ja auch blödsinnig, würde man in jedem Datensatz den Stadtname, Gemeinde etc. neu aufführen. Es muss schon ein sehr gutes Relationenmodel geben, aber das ist bei näherem hinsehen tatsächlich nicht einfacht. Andreas Müller schrieb: > Hallo zusammen, > > nachdem ich mir gerade die aktuelle Datenstruktur genau angesehen habe kann > ich jeden der mit den Daten massive Probleme hat sehr gut verstehen. > Ich würde daher vorschlagen ein Teilprojekt zu starten das parallel zum > erscheinen der Original-DB passende Daten zur Verfügung stellt um die > Verwendung der Daten zu vereinfachen. > > So ist es z.B. im Moment nicht mehr möglich mit nur einer SQL Abfrage > zuverlässig eine Liste aller deutschen Ort mit PLZ und Koordinaten zu > bekommen. Erst ein algorithmisches durchhangeln durch in der Text-Tabelle > (!!!TEXT!!!) verküpften Hierachiebenen führt hier zum Erfolg. Die > angebotenenen "Dhier.sql" Dateien oder was auch immer erscheinen nicht mit > der Hauptdatenbank und stellen somit keine korrekte alternative dar. > > Ich weiss nicht wer das noch blicken soll. Die Dokumentationen stimmen nicht > mehr, wichtige Daten werden einfach mal weggelassen und in der Text-Tabelle > verhackstückt - lustig wenn ich dann überall casten muss um einen Join bauen > zu können usw. Wenn die "Teil von" etc. Logik wenigstens eine Bit-Map wäre > das man von einem Ort auch direkt auf das Land schließen könnte ... > > Vielleicht schließen sich ja ein paar betroffene zusammen und finden hier > gemeinsam eine Lösung - so jedenfalls sind die Daten unbrauchbar da kaum zu > beherrschen. > > Gruß, > Andreas > > From froschpopo at gmx.de Mon Mar 17 02:20:18 2008 From: froschpopo at gmx.de (Lucas Mengel) Date: Mon, 17 Mar 2008 02:20:18 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <47DD7665.9020203@gmx.de> References: <06a601c8879a$286c5200$1400a8c0@nbandreas> <47DD7665.9020203@gmx.de> Message-ID: <47DDC752.4050901@gmx.de> Hi Martin! Ich glaube hier verbirgt sich mehr Potenzial als wir vermuten. Aber sicherlich werden sich einige Kreativköpfe denken: Warum die Arbeit machen, wenn sich das Datenbankmodell aufgrund dieser Protestwelle sowieso bald ändert? Ich meine, seien wir mal ehrlich: Im Grunde suchen wir doch alle nur nach einer besseren Lösung, oder nicht? Gruß, Lucas Martin Trautmann schrieb: > Meine Motivation ist hier beschränkt, meine Zeit noch viel mehr. > Beispielsweise hat sich seit Monaten niemand gefunden, mal eine > brauchbare README-Datei zu schreiben. Ich würde mich viel lieber auf die > Teile konzentrieren, die mir niemand abnehmen kann. From froschpopo at gmx.de Mon Mar 17 02:35:23 2008 From: froschpopo at gmx.de (Lucas Mengel) Date: Mon, 17 Mar 2008 02:35:23 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <20080316200715.CBDE.STEPHAN.S@gmx.net> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> Message-ID: <47DDCADB.8050800@gmx.de> Ich habe hier schon mehrfach dafür plädiert, dass opengeodb sich mehr seinem Ursprung widmet, nämlich die Sammlung und publizierung geotypischer Informationen, und die Verwendungsarchitektur dem Nutzer überlässt! Wir dürfen ja auch nie vergessen, dass besonders ältere Menschen großes Interesse an solchen Datenbanken haben! Das moderne Großvaterhobby ist es, im Internet Datenbanken über Modelleisenbahn, Bäume, Edelsteine und Geodaten zu pflegen. Man darf auch niemals vergessen, dass gerade solche Menschen sehr wichtig sind, denn sie haben Zeit und Interesse. Der aktuelle Stand ist jedoch der, dass die opengeodb primär durch ein dominantes Datenbankmodell auffällt das dem einzelnen Nutzer förmlich eine Verwendungsstruktur aufdränkt. Hier sind kompetente Leute anwesend, die sowieso die Datenbank ihren eigenen Bedürfnissen anpassen werden. Es kann doch nicht angehen, dass eine riesige Flirtcommunity sich komplett neu ausrichten muss, nur weil die opengeodb den Machern eigene Vorstellungen aufzwingt! Gruß, Lucas Stephan S schrieb: > Hallo, > >> Du müsstest sehen, was du davon verwerten kannst. Ich stecke da momentan >> auch nicht richtig drin, hatte schon seinerzeit meine Schwierigkeiten, >> da durchzublicken, weil die SQL-Datenstruktur ein einziger Saustall ist, >> von Normalisierung keine Spur. > > Du hast hier schon mehrfach behauptet, bei der gegenwärtigen Datenbank-Struktur > wäre von Normalisierung keine Spur, mich würde dazu mal interessieren, gegen > welche Normalform Deiner Meinung nach verstoßen wird? > > Ich habe im Gegensatz dazu den Eindruck, dass vielen Nutzern hier die > Normalisierung zu weit geht. Martin hat schon mehrfach dargelegt, dass > eine vereinfachte (und somit denormalisierte) Struktur nicht in der Lage > ist, alle möglichen Abhängigkeiten aufzunehmen, und auch ein Blick ins > Mailinglisten-Archiv erhellt vielleicht den einen oder anderen Aspekt, > warum die Daten so organisiert sind, wie sie sind. > > Für die meisten Nutzer ist die Opengeodb sicherlich hauptsächlich für > die Implementierung einer Umkreissuche auf PLZ-Basis interessant und für > diesen Zweck ist es sicherlich sinnvoll, sich die dafür relevanten > Informationen aus der Datenbank zu extrahieren. Ich denke für diejenigen > sollte es kein Problem darstellen, sich ein Skript zu erstellen, das die > jetzigen Datenbank in eine ihm genehme Struktur überführt. > > Aber auch hier gilt: Machen statt Meckern. Wer dem Projekt helfen will, > sollte so etwas implementieren und der Allgemeinheit zur Verfügung > stellen, und nicht erwarten, dass alles für die eigenen Bedürfnisse > bereit steht. Die Behauptung, die Datenbankstruktur wäre ein "Saustall" > ohne Belege dafür oder eine Alternative zu präsentieren, finde ich > ehrlich gesagt etwas unverfroren, zumal ich den Eindruck habe, Du hast > sie lediglich nicht verstanden. Die jetzige Struktur bietet die maximale > Flexibilität aus der sich jeder die Daten, die er benötigt extrahieren > kann, und das sollte meiner Meinung nach auch so bleiben! > > Und wer tatsächlich meint, er hätte einen besseren Entwurf für die > Datenbank-Struktur der alle Anforderungen erfüllt: Einfach hier > veröffentlichen und zur Diskussion stellen. > > Gruß > Stephan > From robert.boeck at googlemail.com Mon Mar 17 02:54:05 2008 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Mon, 17 Mar 2008 02:54:05 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <20080316200715.CBDE.STEPHAN.S@gmx.net> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> Message-ID: Stephan S wrote: >> Du müsstest sehen, was du davon verwerten kannst. Ich stecke da momentan >> auch nicht richtig drin, hatte schon seinerzeit meine Schwierigkeiten, >> da durchzublicken, weil die SQL-Datenstruktur ein einziger Saustall ist, >> von Normalisierung keine Spur. > Du hast hier schon mehrfach behauptet, bei der gegenwärtigen Datenbank-Struktur > wäre von Normalisierung keine Spur, mich würde dazu mal interessieren, gegen > welche Normalform Deiner Meinung nach verstoßen wird? geodb_textdata ist nicht atomar. Andere Tabellen auch nicht. > Für die meisten Nutzer ist die Opengeodb sicherlich hauptsächlich für > die Implementierung einer Umkreissuche auf PLZ-Basis interessant und für > diesen Zweck ist es sicherlich sinnvoll, sich die dafür relevanten > Informationen aus der Datenbank zu extrahieren. Ich denke für diejenigen > sollte es kein Problem darstellen, sich ein Skript zu erstellen, das die > jetzigen Datenbank in eine ihm genehme Struktur überführt. Und genau so ein Script habe ich mir mal gebaut. > Aber auch hier gilt: Machen statt Meckern. Wer dem Projekt helfen will, > sollte so etwas implementieren und der Allgemeinheit zur Verfügung > stellen, und nicht erwarten, dass alles für die eigenen Bedürfnisse > bereit steht. Mein Script extrahiert nur einen Teilbereich der Daten, und die Datenstruktur hierfür ist genau auf diesen Teilbereich zugeschnitten und nicht für die Opengeodb als Ganzes tauglich. > Die Behauptung, die Datenbankstruktur wäre ein "Saustall" > ohne Belege dafür oder eine Alternative zu präsentieren, finde ich > ehrlich gesagt etwas unverfroren, Du willst allen Ernstes behaupten, Kritik wäre nur zulässig, wenn man gleichzeitig eine Alternative für das kritisierte Objekt anbietet? > zumal ich den Eindruck habe, Du hast sie lediglich nicht verstanden. Zugegebenermaßen habe ich einige Zeit gebraucht, um die Datenbankstruktur zu verstehen. Ich habe jedoch den Eindruck, dass derjenige, der die Datenbankstruktur entworfen hat, noch nicht mal wusste, dass so etwas wie Normalisierung überhaupt existiert. > Die jetzige Struktur bietet die maximale > Flexibilität aus der sich jeder die Daten, die er benötigt extrahieren > kann, und das sollte meiner Meinung nach auch so bleiben! Flexibility through obscurity? > Und wer tatsächlich meint, er hätte einen besseren Entwurf für die > Datenbank-Struktur der alle Anforderungen erfüllt: Einfach hier > veröffentlichen und zur Diskussion stellen. Nö, habe ich nicht, und das habe ich auch nie behauptet. Trotzdem nehme ich mir das Recht heraus, Kritik zu üben. cu, Robo :) From traut at gmx.de Mon Mar 17 07:01:49 2008 From: traut at gmx.de (Martin Trautmann) Date: Mon, 17 Mar 2008 07:01:49 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <47DDC752.4050901@gmx.de> References: <06a601c8879a$286c5200$1400a8c0@nbandreas> <47DD7665.9020203@gmx.de> <47DDC752.4050901@gmx.de> Message-ID: <47DE094D.20906@gmx.de> Lucas Mengel wrote: > Hi Martin! > Ich glaube hier verbirgt sich mehr Potenzial als wir vermuten. > Aber sicherlich werden sich einige Kreativköpfe denken: > Warum die Arbeit machen, wenn sich das Datenbankmodell > aufgrund dieser Protestwelle sowieso bald ändert? Hallo Lucas, Wenn jemand einen guten Vorschlag hat, wie ein besseres Modell aussehen kann, so ist das nach meiner Einschätzung recht leicht umsetzbar. Ich erwarte aber keine massiven Änderungen - und mir scheint, die Grundtypen mit ihren Schlüsselnummern werden die gleiche bleiben. Das Datenbankmodell ist für mich nur ein Vehikel. Mir geht's um die Inhalte, die ich selbst in zwei gänzlich anderen Datenstrukturen nutze (eben .tab und ansonsten .fp7). Wenn ich eine schlüssige Erklärungen bekomme, was falsch ist und besser sein soll, so halte ich das für durchaus diskussionswürdig und erstrebenswert. Dafür brauche ich aber weit konkretere Angaben als nur einfache Ablehnung. Erzähl einem Blinden von der Sonne und mir von SQL... > Ich meine, seien wir mal ehrlich: Im Grunde suchen wir doch > alle nur nach einer besseren Lösung, oder nicht? Aber sicher doch - bis dahin halte ich die bisherige aber für durchaus tauglich und anwendbar. Ich finde aber vor allem, dass die grundlegende Dokumentation fehlt, was ueberhaupt drin ist und was das bedeutet. Vermutlich läuft es auch hier darauf hinaus, sowas selbst machen zu muessen... Schoenen Gruss Martin From traut at gmx.de Mon Mar 17 08:05:44 2008 From: traut at gmx.de (Martin Trautmann) Date: Mon, 17 Mar 2008 08:05:44 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> Message-ID: <47DE1848.2070307@gmx.de> Robert Böck wrote: > Stephan S wrote: > >>> Du müsstest sehen, was du davon verwerten kannst. Ich stecke da momentan >>> auch nicht richtig drin, hatte schon seinerzeit meine Schwierigkeiten, >>> da durchzublicken, weil die SQL-Datenstruktur ein einziger Saustall ist, >>> von Normalisierung keine Spur. > >> Du hast hier schon mehrfach behauptet, bei der gegenwärtigen Datenbank-Struktur >> wäre von Normalisierung keine Spur, mich würde dazu mal interessieren, gegen >> welche Normalform Deiner Meinung nach verstoßen wird? > > geodb_textdata ist nicht atomar. Andere Tabellen auch nicht. Was würde eine Normalisierung für praktische Vorteile mit sich bringen? Wofür braucht man sie, was hilft sie? Und wie sähe sie als konkretes Beispiel aus? Schönen Gruß Martin From robert.boeck at googlemail.com Mon Mar 17 17:50:18 2008 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Mon, 17 Mar 2008 17:50:18 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47DE1848.2070307@gmx.de> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> Message-ID: Martin Trautmann wrote: > Robert Böck wrote: >> Stephan S wrote: >> >>> Du hast hier schon mehrfach behauptet, bei der gegenwärtigen Datenbank-Struktur >>> wäre von Normalisierung keine Spur, mich würde dazu mal interessieren, gegen >>> welche Normalform Deiner Meinung nach verstoßen wird? >> >> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht. > > Was würde eine Normalisierung für praktische Vorteile mit sich bringen? > Wofür braucht man sie, was hilft sie? Kann man sehr schön bei Wikipedia nachlesen: http://de.wikipedia.org/wiki/Normalisierung_(Datenbank) Die Vorteile speziell für die Opengeodb wären, dass die SQL-Statements, um Daten abzufragen, bei weitem nicht so komplex wären, wie sie jetzt sind (momentan muss man u. a. ganz exzessiv mit Selbstbezügen arbeiten, um der Datenbank bestimmte Datensätze zu entlocken). Ich bin mir ziemlich sicher, dass man die Performance auch deutlich verbessern würde. Und die Datenmenge könnte wahrscheinlich ebenfalls reduziert werden. > Und wie sähe sie als konkretes Beispiel aus? Nehmen wir mal die bereits erwähnte geodb_textdata: create table geodb_textdata ( loc_id integer not null references geodb_locations, text_val varchar(255) not null, text_type integer not null, text_locale varchar(5), is_native_lang smallint(1), is_default_name smallint(1), valid_since date, date_type_since integer, valid_until date not null, date_type_until integer not null, ) TYPE=InnoDB CHARACTER SET utf8; Die check-Constraints habe ich mal weggelassen, damit es übersichtlicher ist. Es geht schon mal damit los, dass die Tabelle keinen primary key hat. loc_id ist ein foreign key. Dann ist da alles mögliche drin, was gar nicht zusammengehört (also Postleitzahlen, Ortsnamen in verschiedenen Schreibweisen, Bundesländer, Regiertungsbezirke, etc.) Die Tabelle enthält Daten (text_val) und Metadaten (text_type) gleichermaßen. Alles wild durcheinander wie Kraut und Rüben. Und nun zu einem konkreten Beispiel. Ich greife mal die Postleitzahlen heraus: create table geodb_plz ( id integer not null primary key, plz varchar(255) not null ); Das nenne ich atomar. Für andere Daten muss das entsprechend gemacht werden. Und dann braucht man eben Tabellen, die die Relationen herstellen, z. B. zwischen einer PLZ und einem Ort, oder zwischen einer PLZ und einer Koordinate, etc. Selbstverständlich erfordert das einiges an Gehirnschmalz und Zeit, eine entsprechende Datenstruktur zu definieren. cu, Robo :) From wendorff at uni-paderborn.de Mon Mar 17 18:42:45 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Mon, 17 Mar 2008 18:42:45 +0100 Subject: [opengeodb] Teilprojekt verwendbare Daten In-Reply-To: <080b01c887ac$4ff4b120$1400a8c0@nbandreas> References: <06a601c8879a$286c5200$1400a8c0@nbandreas> <47DD7665.9020203@gmx.de><075d01c887a2$cb6ba3e0$1400a8c0@nbandreas> <47DD87EA.9070808@gmx.de> <080b01c887ac$4ff4b120$1400a8c0@nbandreas> Message-ID: <47DEAD95.8000505@uni-paderborn.de> Hallo Andreas, Hallo Liste. Andreas Müller schrieb: >> Wer eine fertige Web-Anwendung will, der möge sich diese irgendwo >> besorgen. Vielleicht könnte opengeodb auch dies bieten - aber >> nicht von >> mir. Wer das haben will, soll sich eine fertige Web-Anwendung kaufen. >> > Es hat ja keiner von dir verlangt die Daten anders bereitzustellen. Du wirs > aber zugeben müssen das die Hauptprobleme hier dadurch entstehen das es > extreme Verständnisprobleme und technische Unfähigkeiten der Anwender der > Daten gibt. Hier ist das meiner Meinung nach eigentliche Missverständnis. Die OpenGeoDB ist eben KEINE Web- oder sonstige -Anwendung, sondern eine Sammlung von Daten. Ein Anwender der OpenGeoDB muss sich eben mit der Struktur der Daten beschäftigen, da führt kein Weg daran vorbei. Da diese Anwender dann aber eben auch im Normalfall Programmierer sind, kann man ihnen an einigen Stellen dies meiner Meinung nach auch zumuten. Technisches Unverständnis wird in der Mailingliste oft behoben oder vermindert, wer dazu zu blöd ist, soll sich fragen, ob er als Programmierer taugt - oder ob er/sie/es eben doch lieber bei irgendeinem Anbieter eine fertige Lösung kauft - die ja übrigens zudem auf der opengeodb basieren darf, da die Lizenz entsprechend frei ist, wenn ich mich grade nicht irre. > Nur das führt eben nicht dazu das diese sich zu helfen lernen - > nein die werfen das Handtuch und kaufen sich eben irgendwo anders Daten die > so aufbereitet sind wie sie sie in etwa brauchen. Klar - Geld hilft immer bei mangelnder Bildung und mangelndem Einsatz - man kann damit etwas dagegen tun oder die Auswirkung eliminieren, indem man einkaufen geht - irgendeinen Grund muss die Shopping-Manie der 12 bis 17-jährigen (keine harte Grenze, nagelt mich darauf nicht fest!) Mädchen in Deutschland ja haben. > In deren Augen ist > opengeodb dann "scheisse" und ein "saustall" weil es für sie nahezu > unmöglich ist mit den Daten direkt sinnvoll zu arbeiten. Nur wenn das so > weitergeht ist bald niemand mehr da der die Daten verwendet - und für wen > macht man sich dann die Arbeit. Nur wenn die Daten auch (parallel!) in von > den einfachen Anwendern leicht verwendbarer Form zur Verfügung gestellt > werden (und ich sage NICHT das du das machen sollst - du sollst mal schön > dich um die Daten kümmern wie heute) werden die Daten auch von einer > bereiten Masse akzeptiert und verwendet! > Das sollten parallele Projekte wie zum Beispiel die GeoClass erledigen, das hat nur am Rande mit der OpenGeoDB und definitiv nichts mehr mit Martin zu tun (es sei denn, es tritt der unwahrscheinliche Fall ein, dass der sich da einklinken will). An dieser Stelle kann man dann auch überlegen, welche Formate dazu sinnvoll sind, dann gehört zu der entsprechenden Schnittstelle (ob Klasse, "einfaches" Export-Script oder was auch immer) auch eine entsprechende Schnittstelle für die Daten, so dass man eben entweder die releases von Martin direkt verwenden kann sie sich über Import-Scripte importieren lassen. Gruß Peter Wendorff From wendorff at uni-paderborn.de Mon Mar 17 18:56:55 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Mon, 17 Mar 2008 18:56:55 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47DDCADB.8050800@gmx.de> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DDCADB.8050800@gmx.de> Message-ID: <47DEB0E7.1010401@uni-paderborn.de> Hallo Lucas. Lucas Mengel schrieb: > Es kann doch nicht angehen, dass eine riesige Flirtcommunity > sich komplett neu ausrichten muss, nur weil die opengeodb > den Machern eigene Vorstellungen aufzwingt! > An soweit ich weiß KEINER Stelle verspricht die Opengeodb irgendeine Anwendungsmöglichkeit direkt aus den bereitgestellten Daten heraus. Wenn sich hier jemand dazu zwingen lässt, sein Angebot wegen der opengeodb neu auszurichten, der sollte sich überlegen, ob er nicht als Hobby lieber Briefmarken sammeln bzw. beruflich ins Sekretariat wechseln will (Achtung: das heißt nicht, dass Programmierer im Sekretariat gut aufgehoben sind, wenn ich mir Kommilitonen von mir und andere so angucke!). Die OpenGeoDB birgt unheimlich viele Daten und veröffentlicht diese zur Zeit in einer Struktur, die für wenige Zwecke optimiert ist, zu denen eben nicht PLZ-Abfragen oder ähnliches gehören. Es ist und bleibt Aufgabe des Programmierers einer Anwendung, sich zu überlegen, was für Daten er braucht, wie er sie organisiert und woher er sie bekommt. Wenn dies eben einen Portierungsaufwand bedeutet, dann ist das eben so. An Martins Stelle würde ich (und ja, ich selbst verwende auch SQL) bei zu viel Beschwerden auch überlegen, wieder bei reinen tab-Formaten zu bleiben. Wer damit nichts anfangen kann, sollte die Finger davon lassen. Gruß Peter Wendorff From traut at gmx.de Mon Mar 17 19:35:39 2008 From: traut at gmx.de (Martin Trautmann) Date: Mon, 17 Mar 2008 19:35:39 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> Message-ID: <47DEB9FB.2040600@gmx.de> Robert Böck wrote: > Martin Trautmann wrote: >> Robert Böck wrote: >>> Stephan S wrote: >>> >>>> Du hast hier schon mehrfach behauptet, bei der gegenwärtigen Datenbank-Struktur >>>> wäre von Normalisierung keine Spur, mich würde dazu mal interessieren, gegen >>>> welche Normalform Deiner Meinung nach verstoßen wird? >>> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht. >> Was würde eine Normalisierung für praktische Vorteile mit sich bringen? >> Wofür braucht man sie, was hilft sie? > > Kann man sehr schön bei Wikipedia nachlesen: > > http://de.wikipedia.org/wiki/Normalisierung_(Datenbank) Aha - und welche Normalform willst du? > Die Vorteile speziell für die Opengeodb wären, dass die SQL-Statements, > um Daten abzufragen, bei weitem nicht so komplex wären, wie sie jetzt > sind (momentan muss man u. a. ganz exzessiv mit Selbstbezügen arbeiten, > um der Datenbank bestimmte Datensätze zu entlocken). fuer bestimmte ja - aber gerade normalisiert ergeben sich moeglicherweise mehr Bezuege als wenn man alles in eine einzige Tabelle reinpfropft. > Ich bin mir > ziemlich sicher, dass man die Performance auch deutlich verbessern > würde. Und die Datenmenge könnte wahrscheinlich ebenfalls reduziert werden. Ich bin mir sicher, dass man Performance dann verbessern kann, wenn man rauswirft, was man nicht braucht und Hilfstabellen dafuer anlegt, was man haeufig braucht. Das eine verringert die Datenmenge, das andere vergroessert sie. >> Und wie sähe sie als konkretes Beispiel aus? > > Nehmen wir mal die bereits erwähnte geodb_textdata: > > create table geodb_textdata ( > loc_id integer not null references geodb_locations, > text_val varchar(255) not null, > text_type integer not null, > text_locale varchar(5), > is_native_lang smallint(1), > is_default_name smallint(1), > valid_since date, > date_type_since integer, > valid_until date not null, > date_type_until integer not null, > ) TYPE=InnoDB CHARACTER SET utf8; > Es geht schon mal damit los, dass die Tabelle keinen primary key hat. > loc_id ist ein foreign key. Wie kommst du darauf, die loc_id waere kein primary key? Sie wird also solcher verwendet. > Dann ist da alles mögliche drin, was gar nicht zusammengehört (also > Postleitzahlen, Ortsnamen in verschiedenen Schreibweisen, Bundesländer, > Regiertungsbezirke, etc.) Das gehoert nicht zusammen, glaubst du? Seltsam. > Die Tabelle enthält Daten (text_val) und > Metadaten (text_type) gleichermaßen. Alles wild durcheinander wie Kraut > und Rüben. Das hat mit Normalisierung aber wohl nichts mehr zu tun? > Und nun zu einem konkreten Beispiel. Ich greife mal die Postleitzahlen > heraus: > > create table geodb_plz ( > id integer not null primary key, > plz varchar(255) not null > ); > > Das nenne ich atomar. Und was ist deine id? Woher weiss nun ein Ort, welche PLZ zu ihm gehoert? Woher weiss die PLZ, seit wann sie gueltig ist? Woher weiss die PLZ, ob das nun zu einem einzigen Ort gehoert, zu welchen seiner Ortsteile, zu welchen anderen Orten, zu welchem PLZ-Gebiet, zu welchen Koordinaten? Was soll dieses einsame Atom, so ganz allein ohne Molekülverbindungen? Langweilt es sich dann nicht? > > Für andere Daten muss das entsprechend gemacht werden. Und dann braucht > man eben Tabellen, die die Relationen herstellen, z. B. zwischen einer > PLZ und einem Ort, oder zwischen einer PLZ und einer Koordinate, etc. Ah, du willst die Atome über Tabellen verbinden, statt die Atome gleich in der Tabelle drin zu haben - und das spart Platz, ist verständlicher und erhöht die Geschwindigkeit? > Selbstverständlich erfordert das einiges an Gehirnschmalz und Zeit, eine > entsprechende Datenstruktur zu definieren. Im Moment sehe ich nur eine Verkomplizierung, weil weitere Tabellen zur Verknüpfung erforderlich sind. Wer das zur Performance-Optimierung braucht, der sollte diese IMHO selbst anlegen - denn für mich sieht das nach redundanten Daten aus. Schönen Gruß Martin From robert.boeck at googlemail.com Tue Mar 18 02:33:44 2008 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Tue, 18 Mar 2008 02:33:44 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47DEB9FB.2040600@gmx.de> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> <47DEB9FB.2040600@gmx.de> Message-ID: Martin Trautmann wrote:r >>> Was würde eine Normalisierung für praktische Vorteile mit sich bringen? >>> Wofür braucht man sie, was hilft sie? >> >> Kann man sehr schön bei Wikipedia nachlesen: >> >> http://de.wikipedia.org/wiki/Normalisierung_(Datenbank) > > Aha - und welche Normalform willst du? Da möchte ich mich jetzt nicht festlegen. >> Die Vorteile speziell für die Opengeodb wären, dass die SQL-Statements, >> um Daten abzufragen, bei weitem nicht so komplex wären, wie sie jetzt >> sind (momentan muss man u. a. ganz exzessiv mit Selbstbezügen arbeiten, >> um der Datenbank bestimmte Datensätze zu entlocken). > > fuer bestimmte ja - aber gerade normalisiert ergeben sich > moeglicherweise mehr Bezuege als wenn man alles in eine einzige Tabelle > reinpfropft. In der Praxis werden sich für Abfragen weniger Bezüge ergeben, eben weil nicht alles in eine Tabelle reingestopft ist und somit schon die Bezüge für die Datenart (text_type) wegfallen. >> Ich bin mir >> ziemlich sicher, dass man die Performance auch deutlich verbessern >> würde. Und die Datenmenge könnte wahrscheinlich ebenfalls reduziert werden. > > Ich bin mir sicher, dass man Performance dann verbessern kann, wenn man > rauswirft, was man nicht braucht und Hilfstabellen dafuer anlegt, was > man haeufig braucht. > > Das eine verringert die Datenmenge, das andere vergroessert sie. Wenn man das, was jetzt in geodb_textdata drinsteckt, auseinanderklamüsert, dann reduziert es einerseits die Datenmenge, weil text_type wegfallen kann, andererseits vereinfacht es die Abfragen, weil ich keinen text_type dafür herziehen muss, nur um festzulegen, welche Art von Daten (PLZ, Ort, etc.) ich haben will. >>> Und wie sähe sie als konkretes Beispiel aus? >> >> Nehmen wir mal die bereits erwähnte geodb_textdata: >> >> create table geodb_textdata ( >> loc_id integer not null references geodb_locations, >> text_val varchar(255) not null, >> text_type integer not null, >> text_locale varchar(5), >> is_native_lang smallint(1), >> is_default_name smallint(1), >> valid_since date, >> date_type_since integer, >> valid_until date not null, >> date_type_until integer not null, >> ) TYPE=InnoDB CHARACTER SET utf8; > > >> Es geht schon mal damit los, dass die Tabelle keinen primary key hat. >> loc_id ist ein foreign key. > > Wie kommst du darauf, die loc_id waere kein primary key? Sie wird also > solcher verwendet. Weil die loc_id in der Tabelle geodb_locations der Primärschlüssel ist. Wenn ich nun geodb_locations.loc_id mit geodb_textdata.loc_id verknüpfe, folgt daraus, dass geodb_textdata.loc_id ein Fremdschlüssel ist. >> Dann ist da alles mögliche drin, was gar nicht zusammengehört (also >> Postleitzahlen, Ortsnamen in verschiedenen Schreibweisen, Bundesländer, >> Regiertungsbezirke, etc.) > > Das gehoert nicht zusammen, glaubst du? Seltsam. Genauso wie Äpfel, Birnen und Tomaten nicht zusammengehören. Die gehören auch in getrennte Kisten. >> Die Tabelle enthält Daten (text_val) und >> Metadaten (text_type) gleichermaßen. Alles wild durcheinander wie Kraut >> und Rüben. > > Das hat mit Normalisierung aber wohl nichts mehr zu tun? Meiner Meinung nach schon. Weil text_type redundant ist. Wenn man das alles sinnvoll zerlegt, wird text_type überflüssig. >> Und nun zu einem konkreten Beispiel. Ich greife mal die Postleitzahlen >> heraus: >> >> create table geodb_plz ( >> id integer not null primary key, >> plz varchar(255) not null >> ); >> >> Das nenne ich atomar. > Und was ist deine id? Ein Integer. Steht doch da. > Woher weiss nun ein Ort, welche PLZ zu ihm gehoert? Indem er mit der PLZ verknüpft wird. > Woher weiss die PLZ, seit wann sie gueltig ist? Wenn sie das wissen muss, kann man ihr diese Information ja noch mitgeben. > Woher weiss die > PLZ, ob das nun zu einem einzigen Ort gehoert, zu welchen seiner > Ortsteile, zu welchen anderen Orten, zu welchem PLZ-Gebiet, zu welchen > Koordinaten? Das muss die PLZ doch gar nicht wissen, weil das in einer anderen Relation drinsteht. > Was soll dieses einsame Atom, so ganz allein ohne Molekülverbindungen? > Langweilt es sich dann nicht? Mit den ganzen anderen Relationen sicher nicht. >> Für andere Daten muss das entsprechend gemacht werden. Und dann braucht >> man eben Tabellen, die die Relationen herstellen, z. B. zwischen einer >> PLZ und einem Ort, oder zwischen einer PLZ und einer Koordinate, etc. > > Ah, du willst die Atome über Tabellen verbinden, statt die Atome gleich > in der Tabelle drin zu haben - und das spart Platz, ist verständlicher > und erhöht die Geschwindigkeit? Ja selbstverständlich. Weil in jeder "Kiste" nur noch gleichartige "Atome" drin sind. Das spart Metadaten und somit Platz, ist verständlicher und erhöht auch die Geschwindigkeit, weil ich keine Metadaten mehr heranziehen muss, um zu wissen, mit was für einer Art von Daten ich es überhaupt zu tun habe. >> Selbstverständlich erfordert das einiges an Gehirnschmalz und Zeit, eine >> entsprechende Datenstruktur zu definieren. > > Im Moment sehe ich nur eine Verkomplizierung, weil weitere Tabellen zur > Verknüpfung erforderlich sind. Nein, JETZT ist es kompliziert, weil verschiedenartige Daten in einer Tabelle drinstecken und ich zusätzliche Verknüpfungen brauche, um festzulegen, welche Art von Daten ich zur Abfrage heranziehen will. > Wer das zur Performance-Optimierung > braucht, der sollte diese IMHO selbst anlegen - denn für mich sieht das > nach redundanten Daten aus. Mitnichten. Eine vernünftige, normalisierte Datenstruktur vermeidet ja gerade Redundanzen. cu, Robo :) From robert.boeck at googlemail.com Tue Mar 18 03:33:28 2008 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Tue, 18 Mar 2008 03:33:28 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <20080317205629.CBE1.STEPHAN.S@gmx.net> References: <20080316200715.CBDE.STEPHAN.S@gmx.net> <20080317205629.CBE1.STEPHAN.S@gmx.net> Message-ID: Stephan S wrote: >> > Du hast hier schon mehrfach behauptet, bei der gegenwärtigen Datenbank-Struktur >> > wäre von Normalisierung keine Spur, mich würde dazu mal interessieren, gegen >> > welche Normalform Deiner Meinung nach verstoßen wird? >> >> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht. > > Das ist eine Behauptung. Wo ist ein Beleg oder ein Beispiel? Welches > Attribut enthält Deiner Meinung nach einen nichtatomaren Wertebereich? Der Knackpunkt ist für mich geodb_textdata.text_type. Dieses Attribut wäre überflüssig, würde man nicht verschiedene Datenarten in eine Tabelle reinstopfen. > [...] >> > Die Behauptung, die Datenbankstruktur wäre ein "Saustall" >> > ohne Belege dafür oder eine Alternative zu präsentieren, finde ich >> > ehrlich gesagt etwas unverfroren, >> >> Du willst allen Ernstes behaupten, Kritik wäre nur zulässig, wenn man >> gleichzeitig eine Alternative für das kritisierte Objekt anbietet? > > Nein, wenn Du nochmal genau liest, steht da, dass ich bei der Äußerung > von Kritik in einer derart harschen Form, Belege für die aufgestellten > Behauptungen oder zumindest einen Alternativ-Entwurf erwarte, denn das > würde zeigen, dass du dich mit dem Gegenstand deiner Kritik auseinander > gesetzt hast. Fundierte Kritik ist sehr willkommen, unreflektierte > Schmähungen und Worthülsen nicht. Ok, dann nochmal bildlich. Wenn ich Äpfel, Birnen, Bananen, Tomaten, etc. zusammen in eine Kiste reinwerfe, ist das für mich ein "Saustall". Wenn aber jede Gattung in einer eigenen Kiste liegt, dann ist es sauber, aufgeräumt und klar strukturiert. >> Ich habe jedoch den Eindruck, dass derjenige, der die Datenbankstruktur >> entworfen hat, noch nicht mal wusste, dass so etwas wie Normalisierung >> überhaupt existiert. > > Zum einen habe ich den Eindruck, du hast dir nicht die Mühe gemacht das > Mailinglisten-Archiv zu bemühen und die diesbezüglichen Mails zu lesen. > OK, wäre auch etwas Arbeit. Wo sollte ich deiner Meinung nach anfangen? Bei Adam und Eva? Das wäre nicht nur etwas Arbeit, das wäre verdammt viel Arbeit. > Weiterhin erwecken deine Äußerungen den Eindruck, dass du dich mal > -ähnlich oberflächlich wie mit der opengeodb- mit Datenbank-Normalisierung > beschäftigt hast und bei jeder Gelegenheit damit um dich wirfst. > Normalisierung ist ein Konzept zur Vermeidung von Redundanzen und > Inkonsistenzen, keine Religion. Und was ist geodb_textdata.text_type? Ein Konzept zur Erzeugung von Redundanzen? > Zum dritten habe ich den Eindruck, dass Du dir noch immer nicht die Mühe > gemacht hast, zu ergründen warum die Struktur so ist wie sie ist. Glaube mir, ich hatte schon genug Mühe damit, zu ergründen, wie man der Struktur die Daten entlocken kann, die man gerne haben möchte. > Beim Entwickeln einer alternativen Struktur, die Art und Umfang der > Information aufnehmen kann, die die opengeodb bietet hättest Du schnell > gemerkt, dass eine "vereinfachte" Form wie sie dir vorschwebt dies nicht > leisten kann. Ich kann mir einfach nicht vorstellen, dass es nicht möglich sein soll, die Opengeodb so zu strukturieren, dass die Struktur verständlicher wird. > Versuche einfach mal in deiner vereinfachten Form die > verschiedenen Hierarchie-Ebenen in unterschiedlichen Staaten oder > Bundesländern abzubilden. Das kann ich nicht, weil ich die Verwaltungsgliederung in anderen Staaten nicht kenne. >> > Die jetzige Struktur bietet die maximale >> > Flexibilität aus der sich jeder die Daten, die er benötigt extrahieren >> > kann, und das sollte meiner Meinung nach auch so bleiben! >> >> Flexibility through obscurity? > > Du verwechselst hier Ursache und Auswirkung, die Flexibilität wird nicht > durch Unverständlichkeit erreicht. Stimmt, ich habs falsch formuliert, aber es bot sich grad an. ;-) Ich hätte wohl besser schreiben sollen: Flexibility by accepting obscurity. Oder anders gesagt: Was nutzt die ganze Flexibilität, wenn kaum einer durchblickt? > Dir erscheint es unverständlich, weil > die Flexibilität einen höheren Abstraktionsgrad erzwingt. Wenn du aber > glaubst, es gibt ein leichter verständliches Modell, das die gleiche > Flexibilität bietet, dann ist hier jeder froh darüber. Immer her damit. Ich habe keines parat und mir ist auch klar, dass man so ein Datenmodell nicht einfach aus dem Ärmel schüttelt. >> Trotzdem nehme ich mir das Recht heraus, Kritik zu üben. > > Das sei dir unbenommen, aber wenn Deine Kritik gehört und beachtet > werden soll, sollte sie auch mit irgendetwas untermauert sein. Schau dir doch die Postings hier der vergangenen Monate an. Immer wieder wird deutlich, dass die Leute bei der Datenstruktur einfach nicht durchblicken. > Du mißverstehst die Motivation hinter opengeodb, hier werden Geodaten > gesammelt, bearbeitet und zur Verfügung gestellt. Und dafür ist die > bestehende Datenbank-Struktur entwickelt worden. Du willst die Struktur > auf Deinen eingeschränkten Bedarf (Webanwendung o.ä.) hin optimieren, > das kannst Du gerne für dich tun. Nein, das siehst du falsch. Ich bin der Meinung, die Datenstruktur sollte durchaus felexibel, aber trotzdem verständlich sein. Klar sollte jeder die Daten, die er benötigt, in eine dafür passende Struktur überführen. Und eine etwas verständlichere Struktur der Rohdaten wäre dafür sicher nicht von Nachteil. > Für eine Umkreissuche ist das > bestehende Datenbankmodell sicherlich absolut ungeeignet und > unperformant, da hast Du recht. Und deshalb ist jedem angeraten (wie > hier schon hundertmal erwähnt wurde) sich die benötigten Informationen > zu extrahieren und in eine für seinen Zweck passende Struktur zu > überführen. Das kann und will die opengeodb nicht leisten. > > Du scheinst das ja -wie etliche vor dir- bereits erfolgreich > durchgeführt zu haben, also wo liegt dein Problem? Mein Problem liegt darin, dass es viele Leute gibt, die einfach nicht durchblicken. Das kann man leicht erkennen, wenn man die Postings hier ein wenig mitverfolgt. Und mein Problem liegt darin, dass ich meine eigenen SQL-Statements, die ich mir mal vor anderthalb Jahren zusammengeschustert habe, um die Daten zu extrahieren, jetzt selbst auf Anhieb nicht mehr verstehe. > Niemand hier glaubt, dass die Opengeodb in der jetzigen Form perfekt ist > und jeder der helfen will sie zu verbessern ist hier gern gesehen. Dazu > gehört aber die Bereitschaft etwas mehr einzubringen, als ein paar > abwertende Statements. Da kann ich leider nur sehr begrenzt beitragen, weil mir die Voraussetzungen, insbesondre was Verwaltungsgliederungen anderer Staaten anbelangt, nicht bekannt sind. cu, Robo :) From traut at gmx.de Tue Mar 18 08:16:51 2008 From: traut at gmx.de (Martin Trautmann) Date: Tue, 18 Mar 2008 08:16:51 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> <47DEB9FB.2040600@gmx.de> Message-ID: <47DF6C63.60906@gmx.de> Robert Böck wrote: >>> Die Vorteile speziell für die Opengeodb wären, dass die SQL-Statements, >>> um Daten abzufragen, bei weitem nicht so komplex wären, wie sie jetzt >>> sind (momentan muss man u. a. ganz exzessiv mit Selbstbezügen arbeiten, >>> um der Datenbank bestimmte Datensätze zu entlocken). >> fuer bestimmte ja - aber gerade normalisiert ergeben sich >> moeglicherweise mehr Bezuege als wenn man alles in eine einzige Tabelle >> reinpfropft. > > In der Praxis werden sich für Abfragen weniger Bezüge ergeben, eben weil > nicht alles in eine Tabelle reingestopft ist und somit schon die Bezüge > für die Datenart (text_type) wegfallen. Nun, du polemisierst hier mit "reingestopft" und "Saustall" und ignorierst dabei, dass wir nicht nur eine Kiste "Obst" mit durcheinander Äpfeln und Birnen haben, sondern jedes einzelne Obststück fein sortiert seinen Platz hat. Nach meiner unfachmännischen Meinung ist es einer guten Datenbank total egal, ob die Daten nun normalisiert vorliegen oder mit einem Type etikettiert sind. Bei einer schlechten Datenbank wage ich die Behauptung, dass manche mit dem einen Ansatz besser zurechtkommen, manche mit dem anderen. > Wenn man das, was jetzt in geodb_textdata drinsteckt, > auseinanderklamüsert, dann reduziert es einerseits die Datenmenge, weil > text_type wegfallen kann, andererseits vereinfacht es die Abfragen, weil > ich keinen text_type dafür herziehen muss, nur um festzulegen, welche > Art von Daten (PLZ, Ort, etc.) ich haben will. Statt dessen musst du sagen, in welcher Tabelle nachgesehen werden muss. Nehmen wir ein einfaches Beispiel: Suche mir mal in deinem Ansatz die Daten zum Eintrag "Hampuri" heraus. Du wirst damit wohl in der Kiste "rote Äpfel aus Neuseeland" suchen müssen: INSERT INTO geodb_textdata VALUES(17838,500100000,'Hampuri','fi',0,0,null,null,'3000-01-01',300500000); Wenn ich dich richt verstehe, möchtest du Hampuri nun nicht einsortieren nach textdata:500100000:fi -> Hampuri sondern nach 500100000_fi Das lässt sich absolut einfach normalisieren: INSERT INTO geodb_textdata_500100000_fi VALUES(17838,'Hampuri',0,0,null,null,'3000-01-01',300500000); Ich kann dir die SQL-Datei gerne in dieser Form konvertierten, dann kannst du deine Behauptung belegen. Zeige mir aber erst mal, wie du die Suche nach "Hampuri" gestalten würdest, wenn du nun atomarisiert suchen musst nach Äpfel (Name, Type 5001*), rot (Unterscheidung nach allgemeinem Name, Kurzform, Langform, Sortierform, ..., hier also 500100000) aus Neuseeland (hier die Sprachversion "fi"). Deine atomarisierte Suchfunktion muss hier also nachsehen, ob Hampuri in rote Äpfel aus Neuseeland liegt - oder vielleicht in der Kiste rote Äpfel aus Papua-Neuguinea (500100000_yi) oder in der Kiste rote Äpfel aus Hawai (500100000_he). Womöglich musst du sogar noch kleinere Kisten anlegen, wie z.B. "grüner, fauler Apfel aus Deutschland", um den Regierungsbezirk Magdeburg zu finden: INSERT INTO geodb_textdata VALUES(190,500100099,'Regierungsbezirk Magdeburg','de',1,1,null,null,'2007-06-30',300500000); -> INSERT INTO geodb_textdata_500100099_de_ehem VALUES(190,'Regierungsbezirk Magdeburg',1,1,null,null,'2007-06-30',300500000); Das ist der ehemalige Regierungsbezirk Magdeburg, der zum 30. Juni 2007 aufgelöst wurde und daher wohl in die Kiste der "faulen Äpfel" gehört. Konsequent weiter gedacht gehört der aber in die Kiste der faulen, grünen Äpfel aus Deutschland, die in Deutschland abgepackt wurden, von deutschen Erntehelfern, usw., um irgendwann auf dem Atom INSERT INTO geodb_textdata_500100099_de_1_1_ehem_x_y_z VALUES(190,'Regierungsbezirk Magdeburg'); anzukommen. (nochmal zur Erinnerung: Äpfel = Name; grün = Name in Langform; aus Deutschland = Sprache de; in Deutschland verpackt = is_native_lang; von deutschen Erntehelfern = is_default_name; faul = valid_until in der Vergangenheit; ...) >>> Es geht schon mal damit los, dass die Tabelle keinen primary key hat. >>> loc_id ist ein foreign key. >> Wie kommst du darauf, die loc_id waere kein primary key? Sie wird also >> solcher verwendet. > > Weil die loc_id in der Tabelle geodb_locations der Primärschlüssel ist. > Wenn ich nun geodb_locations.loc_id mit geodb_textdata.loc_id verknüpfe, > folgt daraus, dass geodb_textdata.loc_id ein Fremdschlüssel ist. Ah, ok, in der textdata ist sie tatsaechlich Fremdschlüssel. Du brauchst also noch eine Hilfstabelle, um der geodb_location.loc_id darüber mitzuteilen, dass plz_id zu dieser loc_id gehört - und irgendwie scheinst du zu glauben, dass du mit diesen Hilfstabellen Platz sparst? >>> Dann ist da alles mögliche drin, was gar nicht zusammengehört (also >>> Postleitzahlen, Ortsnamen in verschiedenen Schreibweisen, Bundesländer, >>> Regiertungsbezirke, etc.) >> Das gehoert nicht zusammen, glaubst du? Seltsam. > > Genauso wie Äpfel, Birnen und Tomaten nicht zusammengehören. Die gehören > auch in getrennte Kisten. Ja, du kannst natürlich bei Apfel-Anton einkaufen und in Bertas Birnenladen die Birnen holen - ich gehe gleich zu Obi. >>> Die Tabelle enthält Daten (text_val) und >>> Metadaten (text_type) gleichermaßen. Alles wild durcheinander wie Kraut >>> und Rüben. >> Das hat mit Normalisierung aber wohl nichts mehr zu tun? > > Meiner Meinung nach schon. Weil text_type redundant ist. Wenn man das > alles sinnvoll zerlegt, wird text_type überflüssig. Mir scheint eher, du hast eine Abneigung gegen den text_type, weil du die Problematik noch nicht verstanden hast. Zugegeben, das ist beliebig kompliziert. Mit wildcard-Operationen auf 50001* wird manches leichter... Ich befürchte, du würdest dich bald vor lauter Kisten nicht mehr umdrehen können. Was machst du beispielsweise, falls ich bald mal das einbaue: 500600000 - amtlicher Gemeindeschlüssel 500600010 - amtlich ergäntzter Gemeindeschlüssel 500600020 - frei ergänzter Gemeindeschlüssel 500600100 - Landes/Gemeindeschlüssel Nimm z.B. Hamburg mit dem Gemeindeschlüssel 02000000. Der Stadtbezirk Hamburg-Mitte ist einer von sieben Stadtbezirken mit dem frei ergänzten Gemeindeschlüssel 020000001 und weiteren 15 Stadtteilen wie z.B. Hamm-Nord mit Gemeindeschlüssel 02000000104 In manchen Orten sind diese Unternummerierungen amtlich, könnte also als 500600010 markiert werden. Andernfalls mache ich diese Ergänzung frei Schnauze und schaffe mir diesen frei ergänzten Gemeindeschlüssel als extrem leistungsfähigen Primärschlüssel, der in den ersten beiden Stellen das Bundesland, den nächsten drei den Landkreis, dann den Regierungsbezirk und die Gemeinde benennt. Wer mehrere Länder in einer Datenbank zusammenpackt, der kann sich die gesamten Hierarchies ersparen, wenn er statt dessen in 500600100 den Wert DE02000000104 findet - das ist die einfache Kombination von Länderabkürzung und 5006000?0 Schönen Gruß Martin From sn at heise.de Tue Mar 18 11:13:56 2008 From: sn at heise.de (Sven Neuhaus) Date: Tue, 18 Mar 2008 11:13:56 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47DF9010.9010309@mengs.de> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> <47DEB9FB.2040600@gmx.de> <47DF6C63.60906@gmx.de> <20080318074656.M28882@agisb.com> <47DF869C.6060403@gmx.de> <47DF9010.9010309@mengs.de> Message-ID: <47DF95E4.4020008@heise.de> Hallo, mir erschließt sich aus der bisherigen Diskussion auch nicht der Vorteil, den separate Tabellen für jede Art von Datentyp bringen sollen. Es ist doch gehüpft wie gesprungen ob ich nun eine zusätzliche Spalte habe, die den Typen festlegt, oder stattdessen eine separate Tabelle. Im ersten Fall joine ich dann halt mehrmals mit der gleichen Tabelle, im letzten Fall diverse unterschiedliche Tabellen. Man könnte sich auch ein View definieren daß dann genau die Rolle der separaten Tabelle übernimmt. Einen Vorteil für das aktuelle Modell sehe ich aber ganz klar: Neue Arten von Daten in die OpenGeoDB einzufügen erfordert keine Änderungen an der Datenbankstruktur, man muß lediglich neue Typen definieren. Gruß, -Sven Neuhaus From thomas at bornhaupt.de Tue Mar 18 11:33:53 2008 From: thomas at bornhaupt.de (Thomas Bornhaupt) Date: Tue, 18 Mar 2008 11:33:53 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47DF95E4.4020008@heise.de> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> <47DEB9FB.2040600@gmx.de> <47DF6C63.60906@gmx.de> <20080318074656.M28882@agisb.com> <47DF869C.6060403@gmx.de> <47DF9010.9010309@mengs.de> <47DF95E4.4020008@heise.de> Message-ID: <47DF9A91.2000708@bornhaupt.de> Hallo, > mir erschließt sich aus der bisherigen Diskussion auch nicht der > Vorteil, den separate Tabellen für jede Art von Datentyp bringen sollen. > > Es ist doch gehüpft wie gesprungen ob ich nun eine zusätzliche Spalte > habe, die den Typen festlegt, oder stattdessen eine separate Tabelle. > Für das schreiben der paar Zeilen des Zugriffes ist das wohl richtig. Aber es macht schon einen Unterschied ob von einer Datenbank nur ein 10tel, wenn nicht sogar nur 100tel, durch den Ram gejagt werden muss, weil man die notwendigen Spalten extrahiert hat. Ja Ja, das kann eine gute Datenbank Cachen, aber nicht jeder hat so was. Aus Performensgründen macht es immer Sinn die Datenbank so klein wie nötig zu machen. Aber es steht doch jedem frei seine Tabellen aus der Ursuppe zu köcheln. Gruß Thomas From sn at heise.de Tue Mar 18 11:55:58 2008 From: sn at heise.de (Sven Neuhaus) Date: Tue, 18 Mar 2008 11:55:58 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47DF9A91.2000708@bornhaupt.de> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> <47DEB9FB.2040600@gmx.de> <47DF6C63.60906@gmx.de> <20080318074656.M28882@agisb.com> <47DF869C.6060403@gmx.de> <47DF9010.9010309@mengs.de> <47DF95E4.4020008@heise.de> <47DF9A91.2000708@bornhaupt.de> Message-ID: <47DF9FBE.2050004@heise.de> Thomas Bornhaupt schrieb: >> mir erschließt sich aus der bisherigen Diskussion auch nicht der >> Vorteil, den separate Tabellen für jede Art von Datentyp bringen sollen. >> >> Es ist doch gehüpft wie gesprungen ob ich nun eine zusätzliche Spalte >> habe, die den Typen festlegt, oder stattdessen eine separate Tabelle. >> > Für das schreiben der paar Zeilen des Zugriffes ist das wohl richtig. > > Aber es macht schon einen Unterschied ob von einer Datenbank nur ein > 10tel, wenn nicht sogar nur 100tel, durch den Ram gejagt werden muss, > weil man die notwendigen Spalten extrahiert hat. > Ja Ja, das kann eine gute Datenbank Cachen, aber nicht jeder hat so was. Da es einen Index für die Spalte "text_type" gibt dürfte sich das in der Performance nicht allzusehr unterscheiden. Aber besser wäre natürlich wenn das jemand mal nachmisst... Die Tabelle ist übrigens von der Größe aber auch recht überschaubar (bei mir unter 40MB) und dürfte deshalb in den meisten Fällen komplett im Hauptspeicher verweilen. Gruß, -Sven From opengeodb at digitaldogma.de Tue Mar 18 12:48:26 2008 From: opengeodb at digitaldogma.de (Eric) Date: Tue, 18 Mar 2008 12:48:26 +0100 Subject: [opengeodb] =?iso-8859-1?q?Unterschied_PLZ=2ETAB_zu_PLZ_Werten_in?= =?iso-8859-1?q?nerhalb_L=E4nder-TABs?= In-Reply-To: <47DF9FBE.2050004@heise.de> Message-ID: <20080318114914.E3DE6A3805E@mercurix.net> Hallo liebe Leute, ich lese hier schon seit einiger Zeit mit und habe lange versucht die Struktur von OpenGeoDB zu verstehen, was für mich als Hobby-Programmierer oft fast zur Verzeweiflung geführt hat. Ich verstehe inzwischen aber einigermaßen, wie die DB funktioniert (Aufgrund meines Durchhaltevermögens). Nachdem ich dann endlich kapiert hatte, dass ich für meine Zwecke rekursive Abfragen durchführen muss um alle Informationen zu erhalten, die ich gerne hätte (was mit mysql nicht geht), dämmerte es mir dann endlich welchen Zweck die hirarchies Tabelle eigentlich hat. Leider war die Tabelle in meinem DUMP leer, weshalb ich mir ein Skript basteln musste, welches diese erzeugt. Da mein Skript aber eher zusammengefrickelt ist und wahrscheinlich zig Fehler enthält hier meine erste Frage: Frage 1: Gibt es ein fertiges PHP Skript, welches mir die Hirarchies erzeugen kann? Außerdem bin ich dabei die Datenbank so umzubauen, dass sie für mich gut funktioniert. Dazu verwende ich die TAB Dateien. Zurzeit stellt sich mir aber folgende Frage: Frage 2: Wo ist der Unterschied zwischen den Daten innerhalb der PLZ.TAB Datei und den PLZ Daten, die jeweils bei den Städten innerhalb der Länder Dateien zu finden sind. Welche sind aktueller, welche umfassender? Außerdem habe ich Schwierigkeiten die PLZ Daten aus PLZ.TAB den jeweiligen Städten zuzuordnen. Anhand des Stadt-Namens geht es nicht (z.B. gibt es ein Essen in Holland und ein Essen in Deutschland, welches nochdazu in der Dhier.tab anders heißt als in der plz.tab - nämlich "Essen an der Ruhr"). Anhand der Lon und Lat ging das bei mir auch nicht, weil sich die Daten leicht unterscheiden und außerdem manchmal Lon und Lat vertauscht ist etc. - Auch anhand der eines abgleichs der PLZ Liste zu den Städten in den Länderdateien mit den PLZ aus plz.tab gestaltete sich schwierig, weil die Daten scheinbar nicht immer übereinstimmten. Kann mir das jemand erklären? Gruß Eric From traut at gmx.de Tue Mar 18 13:34:58 2008 From: traut at gmx.de (Martin Trautmann) Date: Tue, 18 Mar 2008 05:34:58 -0700 (PDT) Subject: [opengeodb] =?utf-8?q?Unterschied_PLZ=2ETAB_zu_PLZ_Werten_innerha?= =?utf-8?q?lb_L=C3=A4nder-TABs?= In-Reply-To: <20080318114914.E3DE6A3805E@mercurix.net> References: <518133742@web.de> <518806081@web.de> <47B1ED45.1090804@wonderer.de> <47DA2B36.3050101@gmx.de> <47DC244D.7070804@gmx.de> <47DCE673.4020804@gmx.de> <1113821737.20080316124440@gmx.de> <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> <47DEB9FB.2040600@gmx.de> <47DF6C63.60906@gmx.de> <20080318074656.M28882@agisb.com> <47DF869C.6060403@gmx.de> <47DF9010.9010309@mengs.de> <47DF95E4.4020008@heise.de> <47DF9A91.2000708@bornhaupt.de> <47DF9FBE.2050004@heise.de> <20080318114914.E3DE6A3805E@mercurix.net> Message-ID: <16120098.post@talk.nabble.com> > Frage 1: Gibt es ein fertiges PHP Skript, welches mir die Hirarchies erzeugen kann? Gegenfrage: Warum geht das nicht mit SQL? Fuer PHP kenne ich keines. Basierend auf den .tab gibt es eines, das genauso wie der SQL-Dump auch die hierarchies erzeugen kann. > Frage 2: Wo ist der Unterschied zwischen den Daten innerhalb der PLZ.TAB Datei und den PLZ Daten, die jeweils bei den Städten innerhalb der Länder Dateien zu finden sind. Welche sind aktueller, welche umfassender? PLZ.tab und D.tab bieten voellig unterschiedliche Daten. PLZ.tab bietet die Daten fuer Typ 100800000, PLZ-Gebiete. Diese sind in Einzelfaellen deckungsgleich zu Staedten. Da aber eine Stadt viele PLZ-Gebiete umfassen kann oder aber ein PLZ-Gebiet viele unterschiedliche Orte abdeckt, sind es ganz andere Informationen. > Außerdem habe ich Schwierigkeiten die PLZ Daten aus PLZ.TAB den jeweiligen Städten zuzuordnen. Anhand des Stadt-Namens geht es nicht (z.B. gibt es ein Essen in Holland und ein Essen in Deutschland, welches nochdazu in der Dhier.tab anders heißt als in der plz.tab - nämlich "Essen an der Ruhr"). Du kannst mit vermutlich 100 % Uebereinstimmung aus dem Abgleich von Ortseintrag und seinen Postleitzahlen und einem PLZ-Eintrag und dessen Orts-Repraesentanten beide zusammenbringen, auch wenn sie nicht wirklich zusammengehoeren. > Anhand der Lon und Lat ging das bei mir auch nicht, weil sich die Daten > leicht unterscheiden und außerdem manchmal Lon und Lat vertauscht ist etc. > - Auch anhand der eines abgleichs der PLZ Liste zu den Städten in den Länderdateien mit den PLZ aus plz.tab gestaltete sich schwierig, weil die Daten scheinbar nicht immer übereinstimmten. In der PLZ.tab reicht Laengengrad lon von 5.97 bis 14.98 und Breitengrad lat von 47.37 bis 55.02. Eine Vertauschung der Daten kann ich daher ausschliessen. Du hast allerdings Recht, dass in DE.tab die Spalten nach lat/lon und in PLZ.tab als lon/lat vorliegen. Das ist bei jeder Konvertierung oder jedem Import frei zuordnungsfaehig. Ist es das, was du meinst? Andernfalls solltest du unbedingt einen Fehler melden. Schoenen Gruss Martin -- View this message in context: http://www.nabble.com/Fragen-zu-opengeodb-%28PLZ-Koordinaten%2C-Performance%2C-andere-RDBMS%29-tp15412691p16120098.html Sent from the Php German - opengeodb mailing list archive at Nabble.com. From froschpopo at gmx.de Tue Mar 18 19:25:31 2008 From: froschpopo at gmx.de (Lucas Mengel) Date: Tue, 18 Mar 2008 19:25:31 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <3D1F0C42F22D44ECA73CD13D4BE4E4A6@XQHQPC> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> <47DEB9FB.2040600@gmx.de> <47DF6C63.60906@gmx.de> <20080318074656.M28882@agisb.com> <47DF869C.6060403@gmx.de> <3D1F0C42F22D44ECA73CD13D4BE4E4A6@XQHQPC> Message-ID: <47E0091B.4060002@gmx.de> Thomas Wicht schrieb: > Den text_type gibt es um den Wert text_val eine Bedeutung zu geben, > wenn ich Postleitzahlen abfragen möchte gebe ich den text_type dazu an. Das habe ich schon verstanden. Aber ich habe noch nicht so ganz verstanden, was genau gegen ein Beispiel wie dieses hier spricht: Tabelle:locations id MEDIUMINT NOT NULL PRIMARY KEY loc_id MEDIUMINT NULL text_val VARCHAR(250) NOT NULL Tabelle:postcodes id MEDIUMINT AUTO_INCREMENT NOT NULL PRIMARY KEY loc_id MEDIUMINT NULL text_val INT(5) NOT NULL usw. Wir dürfen auch nicht vergessen: Je schwieriger das ganze ist, desto weniger Leute pflegen die Datenbank, weil ja keiner versteht, wie Daten eingeliefert werden sollen geschweige denn wie er sie selbst einpflegen kann. From traut at gmx.de Tue Mar 18 22:19:35 2008 From: traut at gmx.de (Martin Trautmann) Date: Tue, 18 Mar 2008 22:19:35 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <3D1F0C42F22D44ECA73CD13D4BE4E4A6@XQHQPC> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> <47DEB9FB.2040600@gmx.de> <47DF6C63.60906@gmx.de> <20080318074656.M28882@agisb.com> <47DF869C.6060403@gmx.de> <3D1F0C42F22D44ECA73CD13D4BE4E4A6@XQHQPC> Message-ID: <47E031E7.7050100@gmx.de> Thomas Wicht wrote: > Wenn Ihr für alles eine extra Tabelle machen wollt, so müsst Ihr wieder x > Tabellen > erstellen die plz mit Stadtteilen verbinden, Stadtteile mit Orten , Orte mit > Bundesländern , Bundesländer mit Ländern > > Und genau dies hatte eigentlich mal die hierachies Tabelle übernommen. und die versagt bei Häusern in Strassen in Ortsteilen in Stadtvierteln in Stadtbezirken... > Ich sehe das Problem eher in der mangelten Dokumentation und fehlenden > Beispielen. Jeder der > das erste Mal mit der geodb arbeitet bekommt einen Anfall, leider wahr - vor allem wenn Doku und Version nicht mehr zusammenpassen. From traut at gmx.de Tue Mar 18 22:22:49 2008 From: traut at gmx.de (Martin Trautmann) Date: Tue, 18 Mar 2008 22:22:49 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <54AD8C8D14A84111BA41ECAD8981B150@XQHQPC> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> <47DEB9FB.2040600@gmx.de> <47DF6C63.60906@gmx.de> <20080318074656.M28882@agisb.com><47DF869C.6060403@gmx.de> <3D1F0C42F22D44ECA73CD13D4BE4E4A6@XQHQPC> <47E0091B.4060002@gmx.de> <54AD8C8D14A84111BA41ECAD8981B150@XQHQPC> Message-ID: <47E032A9.7090804@gmx.de> Thomas Wicht wrote: > und genau da war die hierarchies Tabelle einfach perfekt für > > Ich weiß nicht weshalb diese rausgenommen wurde. Wurde oft genug geschrieben: - redundant - pflegeaufwendig - statisch zu begrenzt für zukünftige Ergänzungen From froschpopo at gmx.de Wed Mar 19 10:18:56 2008 From: froschpopo at gmx.de (Lucas Mengel) Date: Wed, 19 Mar 2008 10:18:56 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <20080319002758.CBED.STEPHAN.S@gmx.net> References: <20080318074656.M28882@agisb.com> <47DF869C.6060403@gmx.de> <20080319002758.CBED.STEPHAN.S@gmx.net> Message-ID: <47E0DA80.2090705@gmx.de> Ja Okay, das verstehe ich. Aber es wäre trotzdem cool, wenn hierarchies dann gefüllt ausgeliefert wird. Weil ich habe echt keine Ahnung, wie ich diese selber füllen muss um z.B. alle deutschen Postleitzahlen auszugeben. Die Antwort "dann musst du alle Ebenen durchlaufen" bringt mir herzlich wenig. Stephan S schrieb: >> So sehe ich das auch! >> Ich habe auch nie verstanden, warum es diese text_type >> überhaupt gibt. Man könnte geenauso gut tabellen machen, >> dann würde man das wenigstens noch verstehen! und pflegen >> kann man das genauso gut! > > Nein, der Vorzug der aktuellen Struktur ist, dass die Erfassung weiterer > Datentypen durch hinzufügen eines text_types möglich ist, ohne die > Datenbank-Struktur zu ändern. > > Füge in deinem Modell beispielsweise die Erfassung der Geburtenrate pro > Jahr hinzu und du siehst was ich meine. Die jetzige Struktur ist bereits > ausreichend, um die Information aufzunehmen, es genügt ein Eintrag in > der Tabelle geodb_type_names und man kann loslegen die Daten zu erfassen. > >> Ich würde auch schon damit anfangen und das Ergebnis hier >> publizieren, wenn ich denn das aktuelle Modell verstehen >> würde!!! > > Das ist im Prinzip ganz einfach: Alle Daten sind zentral über die loc_id > verknüpft, der Wert von text_type (in Tabelle geodb_textdata) beschreibt > als Fremdschlüssel der Tabelle geodb_type_names die Bedeutung des Wertes. > > So erhälst Du mit der Abfrage > > SELECT gtn.name, gt.text_val > FROM geodb_textdata AS gt > LEFT JOIN geodb_type_names AS gtn ON gt.text_type = gtn.type_id > WHERE loc_id = 21855 > > alle Informationen zu Oberammergau, die als Text interpretiert werden > sollten. Analog dazu liefert > > SELECT gtn.name, gi.int_val > FROM geodb_intdata AS gi > LEFT JOIN geodb_type_names AS gtn ON gi.int_type = gtn.type_id > WHERE loc_id = 21855 > > alle Informationen, die als Integer-Wert interpretiert werden sollten, > in diesem Fall die Einwohnerzahl. Das ganze kannst Du noch mit > geodb_coordinates und geodb_floatdata machen und hast alle Informationen > die in der Datenbank zur loc_id von Oberammergau vorhanden sind. > > Dabei solltest Du noch wissen, von welchem Typ der Eintrag in der > geodb_locations ist. > > SELECT gtn.type_id, gtn.name, COUNT(*) AS amount > FROM geodb_locations AS gl > LEFT JOIN geodb_type_names AS gtn ON gl.loc_type = gtn.type_id > GROUP BY gl.loc_type > > liefert dir eine Übersicht über die vorhandenen Location-Typen. > Oberammergau ist eine "politische Gliederung" > > Über entsprechende Joins kannst Du dir die Daten für deine Zwecke > aufbereiten. Willst Du zum Beispiel eine Tabelle mit Landkreisen > erstellen, erstellst du dir eine Tabelle (geodb_landkreise) und einem > Feld für den Landkreisnamen (lkrs_name) und führst die folgende Query > aus: > > INSERT INTO geodb_landkreise (lkrs_name) > SELECT lkrs_name.text_val > FROM geodb_locations AS gl > LEFT JOIN geodb_textdata AS lkrs_name ON gl.loc_id = lkrs_name.loc_id > WHERE gl.loc_type =100500000 /* ID für Landkreis */ > AND lkrs_name.text_type =500100000 /* ID für Name */ > > Damit hast Du alle Landkreisnamen eingefügt. Möchtest Du weitere > Informationen zum Landkreis hinzufügen, musst Du eben weitere Joins auf > die geodb_textdata mit dem passenden text_type durchführen. > Z.B. KFZ-Kennzeichen, type_id bzw.text_type 500500000: > > INSERT INTO geodb_landkreise (lkrs_name, lkrs_kfz) > SELECT lkrs_name.text_val AS landkreis, kfz_name.text_val AS kfz > FROM geodb_locations AS gl > LEFT JOIN geodb_textdata AS lkrs_name ON gl.loc_id = lkrs_name.loc_id > LEFT JOIN geodb_textdata AS kfz_name ON gl.loc_id = kfz_name.loc_id > WHERE gl.loc_type =100500000 /* ID für Landkreis */ > AND lkrs_name.text_type =500100000 /* ID für Name */ > AND kfz_name.text_type =500500000 /* ID für KFZ-Kennzeichen */ > > Analog funktioniert das auch mit den anderen Tabellen für Koordinaten, int > und float Werte. > > Mit diesen Informationen solltest du dir nun deine eigene Datenbank mit > einem dir passenden Schema zusammenbauen können. > > Gruß > Stephan > From gemander at gmx.net Wed Mar 19 11:47:36 2008 From: gemander at gmx.net (R. Gemander) Date: Wed, 19 Mar 2008 11:47:36 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47E0DA80.2090705@gmx.de> References: <20080318074656.M28882@agisb.com> <47DF869C.6060403@gmx.de> <20080319002758.CBED.STEPHAN.S@gmx.net> <47E0DA80.2090705@gmx.de> Message-ID: <47E0EF48.9030605@gmx.net> Ich bekomms immer noch nicht hin. Ich hab: SELECT text.text_val as plz, coord.lat as lat, coord.lon as lon FROM geodb_textdata as text LEFT JOIN geodb_coordinates as coord ON(text.loc_id = coord.loc_id) WHERE text.loc_id IN (SELECT loc_id FROM geodb_textval WHERE geodb_textval.text_type = 50030000) AND text.text_type = 50030000 ORDER BY plz die liefert mir aber zu jeder Postleitzahl mindestens 3 Datensätze. Wie bekomm ich denn nun daraus einen eindeutigen? Ich weiss das lat und lon unterschiedliche Werte haben, aber der erste (mit den kürzeren lat, lon Einträgen) würde mir für jede PLZ reichen. DISTINCT ist irgendwie nicht so ganz das was ich brauch. Gruß, Ronny Stephan S schrieb: >> [...] >> >> Analog funktioniert das auch mit den anderen Tabellen für Koordinaten, int >> und float Werte. >> >> Mit diesen Informationen solltest du dir nun deine eigene Datenbank mit >> einem dir passenden Schema zusammenbauen können. >> >> Gruß >> Stephan >> >> > > From wendorff at uni-paderborn.de Thu Mar 20 15:43:39 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Thu, 20 Mar 2008 15:43:39 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47DF9010.9010309@mengs.de> References: <47DD114A.4050705@gmx.de> <20080316200715.CBDE.STEPHAN.S@gmx.net> <47DE1848.2070307@gmx.de> <47DEB9FB.2040600@gmx.de> <47DF6C63.60906@gmx.de> <20080318074656.M28882@agisb.com> <47DF869C.6060403@gmx.de> <47DF9010.9010309@mengs.de> Message-ID: <47E2781B.2090809@uni-paderborn.de> Ich habe mir jetzt diese elende Diskussion durchgelesen, die hier zustande gekommen ist in den vier Tagen, die ich jetzt nicht da war. Ein paar Anmerkungen dazu: 1) Primärschlüssel: Primärschlüssel sind für viele Tabellen da, für die anderen normalerweise nicht notwendig, weil die, in denen der Primärschlüssel fehlt, nur weitere Attribute zu den Entities in Tabellen mit Primärschlüsseln enthalten. Insofern ist ein synthetischer Primärschlüssel normalerweise nicht notwendig - und wer ihn für die eigene Anwendung benötigt, der kann ihn sich notfalls doch erzeugen - in der Projektinternen Datenbank stimmen die Schlüssel, und zum Austausch mit der opengeodb als Ganzem werden diese zusätzlichen Schlüssel nicht benötigt. 2) Normalisierung: Die bestehende Datenstruktur ist optimiert für einige Aufgaben - zum Beispiel der Suche nach einem Text über eben verschiedene Typen hinweg. Ich kann nach Bremen suchen und kriege eben nicht nur die Stadt, sondern auch das Bundesland und diverse andere Daten dazu - ich muss dafür aber eben nicht unbedingt über alle Tabellen, in denen irgendwie ein Name als Text abgelegt ist suchen. Insofern ist diese Zusammenlegung der Textdaten in einer Tabelle durchaus besser als die Trennung in einzelne Tabellen. 3) Das Trennen der Datenbank in einzelne Typ-Tabellen selbst ist aber nicht weiter kompliziert - da reicht je ein SQL-Befehl: INSERT INTO detail_tabelle (Feld1, Feld2, ...) VALUES (SELECT * FROM opengeodb_text_data WHERE text_type=xxxx) Wenn man jetzt detail_tabelle noch ein autoinc-Feld als Primärschlüssel gibt, hat man auch damit kein Problem, und über entsprechende DELETE- und ON DUPLICATE KEY- Constraints kann man das ganze auch für Updates anpassen, und über Einschränkungen zur Sprache oder zur nativen Sprache ist auch das rausschmeißen von Fremdsprachen kein Problem mehr. Uwe Mengs schrieb: > Wenns hilft könnte man ja ein Tool bereitstellen, welches die Struktur > der OpenGeoDB kennt und darstellt und jeder sich spalten und Typen > zusammenklickern die er gerne hätte und in was für Tabellen und das Tool > generiert das dann und stellt die Daten zum Download bereit. Wird zwar > nciht ganz in Echtzeit gehen, aber mit nem Versatz von 1,2 Stunden > mittels eines Cronjobs sehe ich da kein Problem. > > Gruß Uwe Genau das kam mir auch als Gedanke - eine Download-Oberfläche, in der man die benötigten Attribute auswählt, die dann zu Exportdateien gepackt und zum Download bereitgestellt werden. Ob dies per Cronjob oder direkt und mit Caching-Mechanismen für häufig benötigte Daten bzw. Teildatenmengen erfolgt, ist eine andere Frage. Wer sich damit beschäftigen möchte, das zu implementieren - ich vermute, dass niemand etwas dagegen hätte. Gruß Peter Wendorff From stephan.s at gmx.net Thu Mar 20 17:42:07 2008 From: stephan.s at gmx.net (Stephan Schuster) Date: Thu, 20 Mar 2008 17:42:07 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47E0EF48.9030605@gmx.net> References: <20080318074656.M28882@agisb.com> <47DF869C.6060403@gmx.de> <20080319002758.CBED.STEPHAN.S@gmx.net> <47E0DA80.2090705@gmx.de> <47E0EF48.9030605@gmx.net> Message-ID: <20080320174156.B91D.STEPHAN.S@gmx.net> > Ich bekomms immer noch nicht hin. > > Ich hab: > > SELECT text.text_val as plz, coord.lat as lat, coord.lon as lon > FROM geodb_textdata as text > LEFT JOIN geodb_coordinates as coord > ON(text.loc_id = coord.loc_id) > WHERE text.loc_id IN (SELECT loc_id FROM geodb_textval WHERE > geodb_textval.text_type = 50030000) > AND text.text_type = 50030000 > ORDER BY plz > > die liefert mir aber zu jeder Postleitzahl mindestens 3 Datensätze. Wie > bekomm ich denn nun daraus einen eindeutigen? Ich weiss das lat und lon > unterschiedliche Werte haben, aber der erste (mit den kürzeren lat, lon > Einträgen) würde mir für jede PLZ reichen. DISTINCT ist irgendwie nicht > so ganz das was ich brauch. Die Tabelle geodb_textval existiert bei mir nicht. Folgende Abfrage liefert wohl, was du suchst: SELECT plz.text_val AS plz, coord.lat, coord.lon FROM geodb_textdata plz LEFT JOIN geodb_coordinates coord ON plz.loc_id = coord.loc_id WHERE plz.text_type = 500300000 ORDER BY plz Willst Du noch die entsprechenden Orts-Namen dazu, verwendest Du folgendes: SELECT plz.text_val, name.text_val, coord.lat, coord.lon FROM geodb_textdata plz LEFT JOIN geodb_textdata name ON name.loc_id=plz.loc_id LEFT JOIN geodb_coordinates coord ON plz.loc_id = coord.loc_id WHERE plz.text_type = 500300000 /* ID für Postleitzahl */ AND name.text_type = 500100000 /* ID für name */; wobei dies natürlich Redundanzen beim Städte-Namen erzeugt... Gruß Stephan From wendorff at uni-paderborn.de Thu Mar 20 17:43:31 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Thu, 20 Mar 2008 17:43:31 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <20080318232609.CBEB.STEPHAN.S@gmx.net> References: <20080317205629.CBE1.STEPHAN.S@gmx.net> <20080318232609.CBEB.STEPHAN.S@gmx.net> Message-ID: <47E29433.1030803@uni-paderborn.de> Um die Liste nicht übermäßig zu strapazieren, zitiere ich nicht die ganze Mail - aber: Danke, sehr schön; ich habe dem hier nichts hinzuzufügen (obwohl ich das meiste so oder so ähnlich auch schreiben wollte vor dem Lesen. Gruß Peter Wendorff From gemander at gmx.net Thu Mar 20 18:38:05 2008 From: gemander at gmx.net (R. Gemander) Date: Thu, 20 Mar 2008 18:38:05 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <20080320174156.B91D.STEPHAN.S@gmx.net> References: <20080318074656.M28882@agisb.com> <47DF869C.6060403@gmx.de> <20080319002758.CBED.STEPHAN.S@gmx.net> <47E0DA80.2090705@gmx.de> <47E0EF48.9030605@gmx.net> <20080320174156.B91D.STEPHAN.S@gmx.net> Message-ID: <47E2A0FD.4090505@gmx.net> Stephan Schuster schrieb: >> Ich bekomms immer noch nicht hin. >> [...] > Willst Du noch die entsprechenden Orts-Namen dazu, verwendest Du folgendes: > > SELECT plz.text_val, name.text_val, coord.lat, coord.lon > FROM geodb_textdata plz > LEFT JOIN geodb_textdata name ON name.loc_id=plz.loc_id > LEFT JOIN geodb_coordinates coord ON plz.loc_id = coord.loc_id > WHERE plz.text_type = 500300000 /* ID für Postleitzahl */ > AND name.text_type = 500100000 /* ID für name */; > Das ergibt bei mir 53.167 Datensätze. Ich gehe davon aus bei Dir auch? > wobei dies natürlich Redundanzen beim Städte-Namen erzeugt... > Das ist nicht sehr schlimm. Vielleicht sogar hilfreich um später mal noch eine gezielte Auswahl des/der Stadt/Stadtteils einzubauen. Ich wollte nur eine kleinere Tabelle, die ich zur Entfernungsberechnung zweier vorhandener Postleitzahlen nutzen kann. Ich hab mir zusätzlich dazu noch einen Primärschlüssel angelegt, den übertrage ich im Format prim1, prim2, entfernung in eine zusätzliche Tabelle. Da bei einer Webanwendung das System ziemlich keucht, wenn es 10 oder 15 Entfernungen zu einer bestimmten PLZ errechnen soll und nur die Summe x an Ausführungszeit hat. > Gruß > Stephan > > Vielen Dank nochmal! Gruß, Ronny From winkelmann at blue-metallic.de Thu Mar 20 20:14:48 2008 From: winkelmann at blue-metallic.de (Jan-Simon Winkelmann) Date: Thu, 20 Mar 2008 20:14:48 +0100 Subject: [opengeodb] =?iso-8859-15?q?Alle_St=E4dte_und/oder_Landkreise_in_?= =?iso-8859-15?q?einem_Bundesland=3F?= Message-ID: <47E2B7A8.5050800@blue-metallic.de> Hallo Liste, ich stehe (nach meinem inzwischen gelösten Kartenproblem) mal wieder vor einer Problematik. Diesmal mit der opengeodb selbst. Und zwar möchte ich gerne (ohne die geoclassphp, sofern die das denn überhaupt kann) eine Liste von allen Städten in einem Bundesland oder allen Landkreisen in einem Bundesland haben. Geht das irgendwie oder fehlt da die Zuordnung? gruß Jan From stephan.s at gmx.net Thu Mar 20 20:37:24 2008 From: stephan.s at gmx.net (Stephan Schuster) Date: Thu, 20 Mar 2008 20:37:24 +0100 Subject: [opengeodb] nur deutschland In-Reply-To: <47E2A0FD.4090505@gmx.net> References: <20080320174156.B91D.STEPHAN.S@gmx.net> <47E2A0FD.4090505@gmx.net> Message-ID: <20080320203531.B922.STEPHAN.S@gmx.net> Hallo, > > Willst Du noch die entsprechenden Orts-Namen dazu, verwendest Du folgendes: > > > > SELECT plz.text_val, name.text_val, coord.lat, coord.lon > > FROM geodb_textdata plz > > LEFT JOIN geodb_textdata name ON name.loc_id=plz.loc_id > > LEFT JOIN geodb_coordinates coord ON plz.loc_id = coord.loc_id > > WHERE plz.text_type = 500300000 /* ID für Postleitzahl */ > > AND name.text_type = 500100000 /* ID für name */; > > > Das ergibt bei mir 53.167 Datensätze. Ich gehe davon aus bei Dir auch? Die Größenordnung stimmt, allerdings sind es bei mir 60686. Gruß Stephan From stephan.s at gmx.net Thu Mar 20 20:52:47 2008 From: stephan.s at gmx.net (Stephan Schuster) Date: Thu, 20 Mar 2008 20:52:47 +0100 Subject: [opengeodb] =?iso-8859-1?q?Alle_St=E4dte__und/oder_Landkreise_in_?= =?iso-8859-1?q?einem_Bundesland=3F?= In-Reply-To: <47E2B7A8.5050800@blue-metallic.de> References: <47E2B7A8.5050800@blue-metallic.de> Message-ID: <20080320204314.B924.STEPHAN.S@gmx.net> Hallo Jan, > Und zwar möchte ich gerne (ohne die geoclassphp, sofern die das denn > überhaupt kann) eine Liste von allen Städten in einem Bundesland oder > allen Landkreisen in einem Bundesland haben. Geht das irgendwie oder > fehlt da die Zuordnung? machbar ist das Ganze sicher, der Schlüssel dazu sind die Datensätze vom Typ 400100000 (= Teil von) in der Tabelle geodb_textdata. Diese ordnen der jeweiligen loc_id die übergeordnet Location zu. Hier müsstest Du dann die jeweiligen Ebenen durchlaufen. Alle Ortschaften zum Landkreis Pinneberg (loc_id 485) erhälst Du beispielsweise mit folgender Abfrage: SELECT gtv.loc_id, name.text_val AS name, typ.text_val AS typ FROM geodb_textdata gtv LEFT JOIN geodb_textdata name ON gtv.loc_id = name.loc_id LEFT JOIN geodb_textdata typ ON gtv.loc_id = typ.loc_id WHERE name.text_type = 500100000 /* Name */ AND typ.text_type = 400300000 /* Typ */ AND gtv.text_type = 400100000 /* Teil von */ AND gtv.text_val = '485' /* loc_id des Landkreis Pinneberg */; Analog dazu müsstest Du deine Abfragen gestalten. Möglicherweise kannst du auch http://fa-technik.adfc.de/code/opengeodb/dump/Dhier.sql für die gewünschte Hierarchie-Struktur verwenden, aber ich glaube es hat sich noch niemand die Mühe gemacht diese zu prüfen. BTW: Ich glaube nicht, dass die geoclass.php noch mit dem aktuellen Schema zusammenarbeitet... Gruß Stephan From wendorff at uni-paderborn.de Thu Mar 20 21:32:30 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Thu, 20 Mar 2008 21:32:30 +0100 Subject: [opengeodb] =?iso-8859-1?q?Alle_St=E4dte__und/oder_Landkreise_in_?= =?iso-8859-1?q?einem_Bundesland=3F?= In-Reply-To: <20080320204314.B924.STEPHAN.S@gmx.net> References: <47E2B7A8.5050800@blue-metallic.de> <20080320204314.B924.STEPHAN.S@gmx.net> Message-ID: <47E2C9DE.3050006@uni-paderborn.de> ??? 400100000 steht in geodb_textdata? Wenn das Teil-Von-Beziehungen sind, sind das locid-Werte, damit gehören die doch wohl eindeutig in geodb_intdata, oder? Ist jetzt kein Einwand zu Stefan oder Jan-Simon, eher eine generelle Frage, ob hier nicht dann ein Fehler in der Verwendung der Struktur vorliegt. Gruß Peter Wendorff Stephan Schuster schrieb: > Hallo Jan, > > >> Und zwar möchte ich gerne (ohne die geoclassphp, sofern die das denn >> überhaupt kann) eine Liste von allen Städten in einem Bundesland oder >> allen Landkreisen in einem Bundesland haben. Geht das irgendwie oder >> fehlt da die Zuordnung? >> > > machbar ist das Ganze sicher, der Schlüssel dazu sind die Datensätze vom > Typ 400100000 (= Teil von) in der Tabelle geodb_textdata. Diese ordnen > der jeweiligen loc_id die übergeordnet Location zu. Hier müsstest Du > dann die jeweiligen Ebenen durchlaufen. > > Alle Ortschaften zum Landkreis Pinneberg (loc_id 485) erhälst Du > beispielsweise mit folgender Abfrage: > > SELECT gtv.loc_id, name.text_val AS name, typ.text_val AS typ > FROM geodb_textdata gtv > LEFT JOIN geodb_textdata name ON gtv.loc_id = name.loc_id > LEFT JOIN geodb_textdata typ ON gtv.loc_id = typ.loc_id > WHERE name.text_type = 500100000 /* Name */ > AND typ.text_type = 400300000 /* Typ */ > AND gtv.text_type = 400100000 /* Teil von */ > AND gtv.text_val = '485' /* loc_id des Landkreis Pinneberg */; > > Analog dazu müsstest Du deine Abfragen gestalten. Möglicherweise kannst > du auch http://fa-technik.adfc.de/code/opengeodb/dump/Dhier.sql > für die gewünschte Hierarchie-Struktur verwenden, aber ich glaube es hat sich > noch niemand die Mühe gemacht diese zu prüfen. > > BTW: Ich glaube nicht, dass die geoclass.php noch mit dem aktuellen > Schema zusammenarbeitet... > > Gruß > Stephan > > From stephan.s at gmx.net Thu Mar 20 23:05:08 2008 From: stephan.s at gmx.net (Stephan Schuster) Date: Thu, 20 Mar 2008 23:05:08 +0100 Subject: [opengeodb] =?iso-8859-1?q?Alle_St=E4dte__und/oder_Landkreise_in_?= =?iso-8859-1?q?einem_Bundesland=3F?= In-Reply-To: <47E2C9DE.3050006@uni-paderborn.de> References: <20080320204314.B924.STEPHAN.S@gmx.net> <47E2C9DE.3050006@uni-paderborn.de> Message-ID: <20080320225726.B926.STEPHAN.S@gmx.net> Hallo Peter > 400100000 steht in geodb_textdata? ja. > Wenn das Teil-Von-Beziehungen sind, sind das locid-Werte, damit gehören > die doch wohl eindeutig in geodb_intdata, oder? Die Frage ist berechtigt, da loc_id laut Strukturdump ein Integer ist, hast Du wohl recht. > Ist jetzt kein Einwand zu Stefan oder Jan-Simon, eher eine generelle > Frage, ob hier nicht dann ein Fehler in der Verwendung der Struktur > vorliegt. Falls niemand einen plausiblen Einwand hat, sollte dies eigentlich geändert werden. An dieser Stelle sollte man auch überlegen, ob dies nicht auch für type_id 400200000 (Ebene) gilt. Die Bedeutung von Ebene ist mir auch nicht ganz klar. Gruß Stephan From winkelmann at blue-metallic.de Fri Mar 21 00:00:02 2008 From: winkelmann at blue-metallic.de (Jan-Simon Winkelmann) Date: Fri, 21 Mar 2008 00:00:02 +0100 Subject: [opengeodb] =?iso-8859-1?q?Alle_St=E4dte__und/oder_Landkreise_in_?= =?iso-8859-1?q?einem_Bundesland=3F?= In-Reply-To: <20080320225726.B926.STEPHAN.S@gmx.net> References: <20080320204314.B924.STEPHAN.S@gmx.net> <47E2C9DE.3050006@uni-paderborn.de> <20080320225726.B926.STEPHAN.S@gmx.net> Message-ID: <47E2EC72.1020800@blue-metallic.de> >> Ist jetzt kein Einwand zu Stefan oder Jan-Simon, eher eine generelle >> Frage, ob hier nicht dann ein Fehler in der Verwendung der Struktur >> vorliegt. >> > > Falls niemand einen plausiblen Einwand hat, sollte dies eigentlich > geändert werden. An dieser Stelle sollte man auch überlegen, ob dies > nicht auch für type_id 400200000 (Ebene) gilt. Die Bedeutung von Ebene > ist mir auch nicht ganz klar. > > Gruß > Stephan > > Wobei sich für mich allgemein die Frage stellt wo das überhaupt wirklich vollständig dokumentiert ist?!? gruß Jan From robert.boeck at googlemail.com Fri Mar 21 00:35:55 2008 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Fri, 21 Mar 2008 00:35:55 +0100 Subject: [opengeodb] =?iso-8859-1?q?Alle_St=E4dte_und/oder_Landkreise_in_e?= =?iso-8859-1?q?inem_Bundesland=3F?= In-Reply-To: <47E2B7A8.5050800@blue-metallic.de> References: <47E2B7A8.5050800@blue-metallic.de> Message-ID: Hallo Jan, Jan-Simon Winkelmann wrote: > ich stehe (nach meinem inzwischen gelösten Kartenproblem) mal wieder vor > einer Problematik. Diesmal mit der opengeodb selbst. > Und zwar möchte ich gerne (ohne die geoclassphp, sofern die das denn > überhaupt kann) eine Liste von allen Städten in einem Bundesland oder > allen Landkreisen in einem Bundesland haben. Geht das irgendwie oder > fehlt da die Zuordnung? Ich habe mir vor einiger Zeit mal einige Abfragen in mühevoller Kleinarbeit zusammengebaut. Diese Abfragen beziehen sich auf Bayern, aber du kannst sie ja auf das jeweilige Bundesland anpassen. Beachte, dass diese Abfragen nur mit einer intakten geodb_hierarchies funktionieren. ------------------------------------------------------------------------ Regierungsbezirk: 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 ------------------------------------------------------------------------ Landkreis: 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