Fragen zu opengeodb (PLZ-Koordinaten, Performance, andere RDBMS)

[Peter Wendorff]

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
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

> 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

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Peter Wendorff]

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
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Gemander, Ronny]

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
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

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

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Robert Böck]

Martin Trautmann wrote:

> 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.

Von fein sortiert kann keine Rede sein. Vielmehr von durcheinander wie
Kraut und Rüben.

>> 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.

Ja und? Das ist wenigstens klar strukturiert und übersichtlich.

> 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:

Nö, wieso? Ich suche einfach in der Kiste "Äpfel".

>>> 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?

Wieso Hilfstabelle? Die Stammtabelle hat nur einen Primärschlüssel. Alle
anderen Tabellen haben einen Primärschlüssel, einen Fremdschlüssel und
ein Datenfeld. So kann man die Daten anderen Daten aus anderen Tabellen
prima zuordnen. Man braucht keine Hilfstabellen. Außer man benötigt eine
n:m-Beziehung.

>>>> 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.

Mal abgesehen davon, dass Obi kein Obst, sondern nur Glühobst ;-) führt,
liegt dieses auch nicht wie Kraut und Rüben auf einem Wühltisch, sondern
fein säuberlich sortiert in Regalen.

> 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

Macht 4 neue Tabellen.

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

> Martin Trautmann wrote:
>
> > 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.
>
> Von fein sortiert kann keine Rede sein. Vielmehr von durcheinander wie
> Kraut und Rüben.

Fein sortiert nach loc_id und type. Keine Suche nach dem richtigen
Fremdschlüssel und der Tabelle auf die sich der Schlüssel bezieht.

> >> 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.
>
> Ja und? Das ist wenigstens klar strukturiert und übersichtlich.

Wieso ist das übersichtlicher als die jetzige Form? Weil Du es so
gewohnt bist und nicht über deinen Tellerrand blicken kannst?

> [...]

> > 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
>
> Macht 4 neue Tabellen.

Für dich und alle Nutzer deines Schemas. Bei jeder Erweiterung musst Du
deine Struktur ändern, oder auf zukünftige Updates verzichten. Für
Nutzer der jetzigen Struktur bedeutet dies keinerlei Änderung an
Struktur und Anwendung.

BTW: Für 1:1 Beziehungen willst Du eigene Relationen schaffen? Unsinnig.
Füge lieber passende Attribute in der Relation hinzu, die deine
Gemeinden enthält.

Wenn Du tatsächlich nahezu jeden Datentyp in eine eigene Tabelle
auslagern willst, kommst Du bereits jetzt auf mehr als 40 Tabellen wenn
Du die volle Funktionalität der OpenGeoDB abbilden willst. Dazu kommen
die entsprechenden Attribute in der Haupt-Relation, bzw die Tabellen für
die Zuordnung bei n:m Beziehungen. Das findest Du wirklich übersichtlich?
Wenn das dein Ernst ist, solltest Du dir doch ein Buch über
Datenbank-Design besorgen...

Für mich erübrigt sich wohl die weitere Diskussion mit dir, das führt
wohl nirgendwo hin.

Stephan

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Robert Böck]

Hallo Stephan,

Stephan S wrote:

>> >> 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.
>
> Das ist eine Frage der Sichtweise. Was du als verschiedene Datenarten
> wahrnimmst, interpretieren andere als Daten die als Text zu
> interpretieren sind,

Wenn man eine Datenbank hat, in der es um Geokoordinaten geht, die mit
Orten, Postleitzahlen und was weiß ich verknüpft sind, dann macht es
meiner Meinung nach schon Sinn, einen Ort auch als Ort zu sehen, und
nicht nur als schnöden Datensatz von Typ "Text".

> und bevor Du monierst, es stehen auch Zahlen drin:
> Dir als Programmierer ist Typisierung sicher ein Begriff.

Dann könnte man die Koordinaten ja auch noch mit in die Tabelle
reinpacken. Und den ganzen Rest auch. Mit Typecasting ist das ja alles
kein Problem. Und spart nochmal ein paar Tabellen.

> Wenn Du möchtest, kannst Du geodb_textdata.text_type auch als
> Fremdschlüssel aus der Tabelle geodb_type_names sehen, das kommt deinem
> Verständnis von Datenbank-Modellen und Normalisierung sicher näher.

Das ändert aber nichts daran, dass geodb_textdata.text_type redundant
ist. Jedenfalls meiner Auffassung nach.

>> > 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?
>
> Welche Daten sind deiner Meinung nach redundant vorhanden?

geodb_textdata.text_type selbst ist redundant, weil es überflüssig ist,
wenn man die Daten sauber trennt.

> Wo ist text_type nicht atomar? Belege deine Behauptungen bitte mit Beispielen!

Wer behauptet das?

>> > 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.
>
> Probier es aus. Bitte. Du hast alle Daten zur Verfügung. Ich hoffe, dass
> nicht alle Dinge davon abhängen, ob du dir sie vorstellen kannst.

Mit den Daten, die jetzt in der Opengeodb drin sind, geht es. Und wenn
man einen zusätzlichen Datentyp aufnehmen will, muss man eben eine neue
Tabelle dazubauen.

Wenn man ein Datenmodell entwickelt, muss man sich eben _vorher_ darüber
Gedanken machen, welche Daten dieses Modell aufnehmen können soll. Wenn
man ein universelles Datenmodell baut, also praktisch eine eierlegende
Wollmilchsau, hat man zwar den Vorteil, dass man sich erst hinterher
Gedanken darüber machen muss, welche Daten man denn nun aufnehmen will,
aber man hat auch den Nachteil, dass das Datenmodell schnell beliebig
kompliziert und unverständlich 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.
>
> Und weil du diese nicht kennst und keine Lust hast dich zu informieren,
> sollen alle anderen darauf verzichten?

Wer behauptet das?

> Hast du nicht erst kürzlich
> darauf hingewiesen, dass die opengeodb möglicherweise zukünftig andere
> Länder aufnimmt?

Das war nicht ich.

>> Ich hätte wohl besser schreiben sollen:
>> Flexibility by accepting obscurity.
>>
>> Oder anders gesagt: Was nutzt die ganze Flexibilität, wenn kaum einer
>> durchblickt?
>
> Weil du nicht durchblickst, heisst das nicht, dass dies auch bei allen
> anderen so ist. Was meinst du, wieviele Leute sich hier die Daten holen,
> nachfragen, wenn sie was nicht verstehen und wieder gehen.

Schon allein die Tatsache, dass viele nachfragen, weil sie etwas nicht
verstehen, zeigt doch, wie kompliziert die ganze Geschichte ist.

>> 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.
>
> Dann stelle diese "verständlichere Struktur" hier vor.

Ich habe aber keine in der Schublade liegen.

> Dir schwebt ein "klassisches" Datenbank-Modell vor, mit einer
> Haupttabelle z.B. locations und alle zugehörigen Daten (z.B.
> Postleitzahlen, Bundesland, Landkreis etc.) als Fremdschlüssel-referenzierte
> Daten in eigenen Tabellen.

So in etwa.

> Selbst wenn Du nicht weisst, wie die
> Hierarchie-Strukturen woanders aufgebaut sind, wirst Du wissen, dass es
> Staaten gibt, die keine Bundesländer besitzen, wie gehst Du damit um?

Ich hänge die nächste Verwaltungsebene einfach eine Ebene höher ein. Es
muss natürlich dann dokumentiert sein oder noch besser eine Tabelle
geben, in der die Verwaltungsstrukturen für jedes Land gespeichert sind.

> Egal, wie du deine (angeblich) einfachere Struktur auch aufbaust, du
> wirst mit deinen Tabellen immer vor Problemen stehen, wenn Daten
> dazukommen oder wegfallen. Möchtest Du beispielsweise die
> durchschnittliche Schuhgröße der Männer über 40 mit erfassen, benötigst
> Du:
>
> - eine zusätzliche Tabelle für die Schuhgrößen
> - einen Fremdschlüssel oder (bei n:m-Relationen) sogar eine zusätzliche
>   Transfer-Tabelle mit den Zuordnungen.

Ich habe doch schon geschrieben, dass man sich _vorher_ Gedanken machen
sollte, was alles an Daten rein soll, bevor man eine Datenstruktur baut.
Und was ist so schlimm daran, eine neue Tabelle einzufügen?

> Oder versuche das ganze mit der Erfassung von Postleitzahlen, die
> Postfächern zugeordnet sind. Wie gehst du vor?

Wenn man diese Information haben will, braucht eben die Postleitzahl
noch ein weiteres Feld, in dem steht, ob sie zu einem Postfach gehört
oder nicht.

> Bei jeder Änderung der zu erfassenden Daten musst Du deine
> Datenbank-Struktur ändern, jeder Nutzer deines Modells muss diese
> Änderungen spätestens beim Update seiner Daten nachvollziehen. Dabei
> riskierst Du immer, dass bestehende Anwendungen nicht mehr funktionieren.

Nicht unbedingt. Wenn bestehende Tabellen nicht geändert werden und nur
neue hinzukommen, sehe ich kein Problem.

> In der jetzigen Struktur musst Du lediglich einen neuen Typ definieren
> und kannst mit der Dateneingabe starten. Alle Anwendungen laufen weiter
> wie bisher.

Ob ich einen neuen Typ definiere oder eine neue Tabelle einfüge, macht
doch für die Abwärtskompatiblität keinen Unterschied.

> Der Aufwand nur benötigte Teildaten aus deiner Datenbank zu extrahieren,
> ist wesentlich höher, als jetzt.

Warum?

> Und wo ist der Unterschied, ob Du 5x geodb_textdata mit entsprechendem Alias
> joinst oder 5 Tabellen, mit unterschiedlichen Namen? Hast Du nicht erst
> Tips mit sprechenden Aliasen gegeben?

Wenn ich 5 x geodb_textdata joine muss die DB diese Tabelle 5 x laden.
Wenn ich aber die geodb_textdata in 5 Tabellen aufteile und diese 5
einzelnen Tabellen joine, muss die DB nur ein Fünftel der Datenmenge
laden. Ungefähr jedenfalls. Für die Datenbank macht das einen großen
Unterschied; umso mehr, je größer die Datenmenge wird.

> Die jetzige Struktur ist aus der Erkenntnis entstanden, dass die, die du
> favorisierst, den anfallenden Daten nicht gerecht wird, denn eine solche
> Struktur war ursprünglich vorhanden. Ich schick Dir gerne mal einen Dump
> der opengeodb 0.1.3. Und ich kann dir versichern dass Normalisierung
> bei der Entwicklung der jetzigen Struktur auch ein großes Thema war. Und
> wenn du wieder behaupten willst, das Schema wäre nicht normalisiert,
> bring Belege, wenn du weiter ernst genommen werden willst.

Vielen Dank, aber ich habe die 0.2.4d im 0.1.3-Layout vorliegen.

Und auch wenn es dir wahrscheinlich nicht gefällt, muss ich sagen, dass
die Tabelle geodb_locations hochgradig redundante Daten enthält. Was
soll bitte daran normalisiert sein, wenn immer wieder "Landkreis xyz"
drinsteht? Die Landkreise gehören in eine eigene Tabelle und über
Fremdschlüssel in der geodb_locations referenziert. Und nicht nur die
Landkreise.

Allerdings ist dieses Layout in der Tat erheblich weniger kompliziert.

>> 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.
>
> Die Bereitschaft zu lernen und sich mit den Dingen auseinanderzusetzen
> sind nun einmal Vorraussetzung hier. Lesen lernen ist auch schwer und
> die Welt wäre ärmer, wenn man auf 80% der Worte verzichten würde, weil
> nur 20% sie benutzen wollen.

Dann empfehle ich dir, Ungarisch zu lernen. Ich kann es nicht, aber ich
weiß, dass es als Erwachsener extrem schwierig bis nahezu unmöglich ist.
Ich kenne eine Ungarin, die mir gesagt hat, dass man es, wenn man es
nicht schon von frühester Kindheit an gelernt hat, praktisch nicht mehr
lernen kann. Da hilft dir die Bereitschaft, lernen zu wollen, auch nur
begrenzt weiter.

Finnisch soll im Übrigen ähnlich schwierig sein.

Um nun wieder die Kurve zu kriegen: Die Struktur der Opengeodb kommt mir
ein bisschen vor wie Ungarisch ...

>> 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.
>
> Und das ist ein Fehler der opengeodb? Du solltest dazu übergehen, deinen
> Code besser zu kommentieren / dokumentieren.

Wie soll ich meinen Code oder besser meine SQL-Statements vernünftig
kommentieren, wenn die Opengeodb an sich schon schlecht dokumentiert
ist? Ich habe mir die SQL-Abfragen seinerzeit in mühevoller Kleinarbeit
anhand von Beispielen, die ich bei Sourceforge gefunden habe,
zusammengezimmert.

>> Da kann ich leider nur sehr begrenzt beitragen, weil mir die
>> Voraussetzungen, insbesondre was Verwaltungsgliederungen anderer Staaten
>> anbelangt, nicht bekannt sind.
>
> Darum geht es nicht. Du könntest -mit etwas gutem Willen- selbst prüfen,
> ob das, was du hier anregst, sinnvoll ist und ob die Kritik die du übst
> berechtigt ist.

Ob irgendetwas sinnvoll oder berechtigt ist, ist immer eine Frage der
Sichtweise.

> Wenn Du dazu nicht bereit bist, brauchen wir nicht
> weiter zu diskutieren, schade um die Zeit.

Ich bin der Meinung, eine weitere Diskussion bringt uns nicht weiter,
weil die Standpunkte einfach zu verschieden sind.

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Peter Wendorff]

Hallo Robert.

Robert Böck schrieb:
>> Selbst wenn Du nicht weisst, wie die
>> Hierarchie-Strukturen woanders aufgebaut sind, wirst Du wissen, dass es
>> Staaten gibt, die keine Bundesländer besitzen, wie gehst Du damit um?
>>    
>
> Ich hänge die nächste Verwaltungsebene einfach eine Ebene höher ein. Es
> muss natürlich dann dokumentiert sein oder noch besser eine Tabelle
> geben, in der die Verwaltungsstrukturen für jedes Land gespeichert sind.
>  
Und dann willst Du nach Städten suchen - wie machst Du das?
Nach konstanter Ebene suchen geht nicht - denn je nachdem, wo die Stadt
liegt, fehlen ja übergeordnete Ebenen - oder eben nicht, und Städte sind
auf unterschiedlichen Ebenen eingeordnet.
Mit den Teil-Von-Beziehungen in Reinform ginge das noch, aber damit ist
die geodb_hierarchies wieder nicht dabei, die so viele unbedingt haben
wollen (ich bin mir grade nicht sicher, ob Du auch zu der Fraktion
gehörst, die die hierarchies haben wollten).

Um bei deinem Ansatz jedenfalls Staats- oder auch Landesgrenzen (auch
unter den Bundesländern gibt es Unterschiede wie z.B. fehlende
Regierungsbezirke etc) zu ignorieren, brauchst Du entweder wieder einen
Typ innerhalb der Einträge, oder die Abfragen werden beliebig komplex,
weil alle Eigenheiten einzelner Regionen in der Anwendungsprogrammierung
berücksichtigt werden müssen.
> Ich habe doch schon geschrieben, dass man sich _vorher_ Gedanken machen
> sollte, was alles an Daten rein soll, bevor man eine Datenstruktur baut.
>  
Diese Aussage lasse ich für einige Softwareentwicklungen zum Teil
gelten, nicht aber für ein Projekt wie die opengeodb.
Bei einigen geisterten bei diesem Projekt sicherlich von Anfang an Ideen
im Kopf herum, wie man Straßen, Häuser, Einwohnerzahlen,
Altersstrukturen, Arbeitslosenzahlen, Verkehrsanbindungen oder sonst
irgendwas mit einbauen könnte - vielleicht auch die Schuhgrößen, die an
anderer Stelle hier genannt worden sind.
Dein Vorschlag wäre gewesen: Bastelt eine Datenbank mit ca 200 Tabellen,
die das alles abbilden kann, und lasst 180 davon leer.
Klar - hätte man machen können, aber die Fragen wären nicht weniger
geworden, nur anders gelagert: Welche Tabellen brauche ich denn jetzt?
Mit der aktuellen Struktur lassen sich verschiedenartigste Daten recht
gut verwalten und auch auslesen - wenn man weiß, wie es funktioniert.
> Und was ist so schlimm daran, eine neue Tabelle einzufügen?
>  
Nicht mehr oder weniger, als alles in eine zu packen, was gleichartig
behandelt werden kann: Bisher musst Du den Quelltext anpassen, um z.B.
weitere types zu unterstützen, mit neuen Tabellen eben auch.
>> Bei jeder Änderung der zu erfassenden Daten musst Du deine
>> Datenbank-Struktur ändern, jeder Nutzer deines Modells muss diese
>> Änderungen spätestens beim Update seiner Daten nachvollziehen. Dabei
>> riskierst Du immer, dass bestehende Anwendungen nicht mehr funktionieren.
>>    
> Nicht unbedingt. Wenn bestehende Tabellen nicht geändert werden und nur
> neue hinzukommen, sehe ich kein Problem.
>  
Wenn nur neue Typen hinzukommen, sehe ich aber auch kein Problem.
>> In der jetzigen Struktur musst Du lediglich einen neuen Typ definieren
>> und kannst mit der Dateneingabe starten. Alle Anwendungen laufen weiter
>> wie bisher.
>>    
> Ob ich einen neuen Typ definiere oder eine neue Tabelle einfüge, macht
> doch für die Abwärtskompatiblität keinen Unterschied.
>  
Das ist richtig, wenn man deinen Vorschlag als Struktur umgesetzt hat,
die Umstellung würde aber eben einen großen Umbruch geben, der plötzlich
sehr viele Anwendungen inkompatibel machen würde.
Eine Sache kannst Du mit neuen Tabellen aber nicht leisten, was die
aktuelle Struktur kann:
Wenn du eine Tabelle mit den Typnamen hast, die den Typkonstanten
sprechende Namen bzw. Beschreibungen zuordnet, so kannst Du in einer
Anwendung direkt auch neue Datentypen mit unterstützen - zumindest in
der Ausgabe.
Wenn ich zu einer locid alle Informationen suche, muss ich eben nur in
geodb_textdata nach allen Einträgen suchen, die diese locid tragen, dazu
ein Join zwischen dem Typ und der Typentabelle, und ich kann direkt die
Beschreibung des Eintrags und den Wert selbst ausgeben, für den Benutzer
vielleicht ganz nützlich, obwohl ich es bei der Programmierung nicht
berücksichtigt habe.

>> Und wo ist der Unterschied, ob Du 5x geodb_textdata mit entsprechendem Alias
>> joinst oder 5 Tabellen, mit unterschiedlichen Namen? Hast Du nicht erst
>> Tips mit sprechenden Aliasen gegeben?
>>    
>
> Wenn ich 5 x geodb_textdata joine muss die DB diese Tabelle 5 x laden.
> Wenn ich aber die geodb_textdata in 5 Tabellen aufteile und diese 5
> einzelnen Tabellen joine, muss die DB nur ein Fünftel der Datenmenge
> laden. Ungefähr jedenfalls. Für die Datenbank macht das einen großen
> Unterschied; umso mehr, je größer die Datenmenge wird.
>  

Rechnen wir mal durch...
Die gesamte opengeodb hat bei mir im Moment eine Größe von ca 100 MB,
davon entfallen ca 70% auf die geodb_textdata.
Häufigste Anwendungen für geodb_textdata sind:
- ich habe eine locid und brauche spezifische Textdaten dazu, also joine
ich eine Teilmenge. Jedes Datenbank-Managementsystem, was den Namen
sinnvoll verdient (ich hoffe, ich trete Martin mit dieser Aussage jetzt
nicht auf den Schlips, weil er auf den Textdateien arbeitet), benutzt
für diesen Join die entsprechenden Indizes - bei mir existiert (direkt
eingespielt, keine Änderungen am heruntergeladenen SQL-Dump vorgenommen)
in diesem Falle ein index über das Feld loc_id mit dem Namen
text_lid_idx. Damit wird eben die Tabelle nicht mehr vollständig,
sondern nur noch sehr teilweise geladen.
Bei einer Suche nach einem Text wird der Index text_val_idx verwendet,
bei Betrachtung nur bestimmter Typen text_type_idx und so weiter.
Lediglich ein kombinierter Index über text_val und text_type wäre
vielleicht noch einer Überlegung wert.

Gruß

Peter Wendorff
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

Hallo Robo,
>
> Stephan S wrote:
[...]
> > Wenn Du möchtest, kannst Du geodb_textdata.text_type auch als
> > Fremdschlüssel aus der Tabelle geodb_type_names sehen, das kommt deinem
> > Verständnis von Datenbank-Modellen und Normalisierung sicher näher.
>
> Das ändert aber nichts daran, dass geodb_textdata.text_type redundant
> ist. Jedenfalls meiner Auffassung nach.

??? Fremdschlüssel sind nahezu immer redundant vorhanden, das liegt in
der Natur der Sache. Der Fremdschlüssel für den Landkreis Pinneberg
würde sich in deiner Tabelle mit Gemeinden ca. 49 mal finden. Lies mal
http://de.wikipedia.org/wiki/Redundanz_%28Information%29
den Abschnitt "Datenbanken und Datenstrukturen"

> > Welche Daten sind deiner Meinung nach redundant vorhanden?
>
> geodb_textdata.text_type selbst ist redundant, weil es überflüssig ist,
> wenn man die Daten sauber trennt.

Meinst Du mit "redundant" etwa überflüssig? Das würde einiges erklären.
 
> > Wo ist text_type nicht atomar? Belege deine Behauptungen bitte mit Beispielen!
>
> Wer behauptet das?

Du. Hier:
>> >> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht.
 Du hast dich sogar selbst zitiert. Einen Beleg hast Du noch nicht
 geliefert...
 
 [...]

> >> > 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.
> >
> > Und weil du diese nicht kennst und keine Lust hast dich zu informieren,
> > sollen alle anderen darauf verzichten?
>
> Wer behauptet das?

Das impliziert dein Datenmodell,  das jetzige nimmt diese Information
problemlos auf.
 
 [...]
 
> Schon allein die Tatsache, dass viele nachfragen, weil sie etwas nicht
> verstehen, zeigt doch, wie kompliziert die ganze Geschichte ist.

Hat jemand behauptet, es wäre nicht kompliziert? Wer sich mit komplexen
Dingen beschäftigt muss nunmal in Kauf nehmen, dass man etwas
investieren muss.
 
> >> 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.
> >
> > Dann stelle diese "verständlichere Struktur" hier vor.
>
> Ich habe aber keine in der Schublade liegen.

Du möchtest also dass andere die Arbeit für dich erledigen, so wie du
dir das vorstellst? Du erwartest dass die Leute die die Daten pflegen
dir zuliebe eine Struktur verwenden, die sie für unsinnig halten, da man
sich ständig mit der Struktur, statt mit den Daten beschäftigt? Ohne
dass du schlüssige Argumente für deine Variante lieferst? "Ist für mich
verständlicher" ist kein Argument in diesem Sinn.
[...]
> Ich habe doch schon geschrieben, dass man sich _vorher_ Gedanken machen
> sollte, was alles an Daten rein soll, bevor man eine Datenstruktur baut.

Die Erfahrung der letzten Jahre hat gezeigt, dass die Anforderungen bei
Geoinformationen sich mit den wechselnden Nutzern ändern. Die jetzige
Struktur trägt dem Rechnung.

> Und was ist so schlimm daran, eine neue Tabelle einzufügen?

Man ändert die Struktur und mit jedem Update müssen nicht nur die
Nutzdaten aktualisiert werden, sondern die komplette Struktur. Und du
erhöhst den Aufwand eine Dokumentation zu pflegen, usw...
 [...]
>
> Ob ich einen neuen Typ definiere oder eine neue Tabelle einfüge, macht
> doch für die Abwärtskompatiblität keinen Unterschied.

Doch, im einen Fall änderst Du nur Daten, im anderen die Struktur und
Daten. Importiere ich die Daten aus deiner SQL-Datenbank muss ich meine
Struktur ebenfalls anpassen, da evtl Fremdschlüssel-Attribute nicht
vorhanden sind.

> > Der Aufwand nur benötigte Teildaten aus deiner Datenbank zu extrahieren,
> > ist wesentlich höher, als jetzt.
>
> Warum?

Vergleiche beide Varianten und denk selbst nach.

> > Und wo ist der Unterschied, ob Du 5x geodb_textdata mit entsprechendem Alias
> > joinst oder 5 Tabellen, mit unterschiedlichen Namen? Hast Du nicht erst
> > Tips mit sprechenden Aliasen gegeben?
>
> Wenn ich 5 x geodb_textdata joine muss die DB diese Tabelle 5 x laden.
> Wenn ich aber die geodb_textdata in 5 Tabellen aufteile und diese 5
> einzelnen Tabellen joine, muss die DB nur ein Fünftel der Datenmenge
> laden. Ungefähr jedenfalls. Für die Datenbank macht das einen großen
> Unterschied; umso mehr, je größer die Datenmenge wird.

Die Datenbank ist auf Flexibilität bei Erfassung und Pflege der Daten
ausgelegt, nicht auf möglichst performante Abfragen. Jeder, der ein
bisschen mitdenkt, erzeugt sich die Struktur die er braucht. Das ist dir
hier schon mehrfach erläutert worden.

[..]

> Und auch wenn es dir wahrscheinlich nicht gefällt, muss ich sagen, dass
> die Tabelle geodb_locations hochgradig redundante Daten enthält. Was
> soll bitte daran normalisiert sein, wenn immer wieder "Landkreis xyz"
> drinsteht? Die Landkreise gehören in eine eigene Tabelle und über
> Fremdschlüssel in der geodb_locations referenziert. Und nicht nur die
> Landkreise.

Wieder eine Behauptung, ohne  Beleg oder Beispiel. Wo steht immer wieder
""Landkreis xyz"? Oder nenn mir die Normalform, gegen die
geodb_locations verstösst?

1. NF: alle Attribute sind atomar, keines ist weiter zerlegbar.
2. NF: es existieren nur Schlüsselkandidaten, damit liegt automatisch
            die 2.NF vor
3. NF: gleicher Sachverhalt wie bei 2.NF

Du schwafelst, und weisst nicht wirklich was Normalisierung ist.

Konkret:

SELECT DISTINCT *
FROM geodb_locations
WHERE loc_type =100500000

liefert mir 440 Einträge vom Typ Landkreis. Wo siehst Du hier Redundanz.
Zeig mit bitte einen einzigen redundanten Datensatz!

> Allerdings ist dieses Layout in der Tat erheblich weniger kompliziert.
>
> >> 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.
> >
> > Die Bereitschaft zu lernen und sich mit den Dingen auseinanderzusetzen
> > sind nun einmal Vorraussetzung hier. Lesen lernen ist auch schwer und
> > die Welt wäre ärmer, wenn man auf 80% der Worte verzichten würde, weil
> > nur 20% sie benutzen wollen.
>
> Dann empfehle ich dir, Ungarisch zu lernen. Ich kann es nicht, aber ich
> weiß, dass es als Erwachsener extrem schwierig bis nahezu unmöglich ist.
> Ich kenne eine Ungarin, die mir gesagt hat, dass man es, wenn man es
> nicht schon von frühester Kindheit an gelernt hat, praktisch nicht mehr
> lernen kann. Da hilft dir die Bereitschaft, lernen zu wollen, auch nur
> begrenzt weiter.
>
> Finnisch soll im Übrigen ähnlich schwierig sein.

Du möchtest also, dass die Ungarn und die Finnen ihre Sprache
vereinfachen, damit du sie leichter lernen kannst? Im Ernst? Ich bin
beeindruckt von soviel Egozentrik.

[...]

> Wie soll ich meinen Code oder besser meine SQL-Statements vernünftig
> kommentieren, wenn die Opengeodb an sich schon schlecht dokumentiert
> ist? Ich habe mir die SQL-Abfragen seinerzeit in mühevoller Kleinarbeit
> anhand von Beispielen, die ich bei Sourceforge gefunden habe,
> zusammengezimmert.

Versuche zu verstehen und komplettiere bzw. berichtige die Dokumentation
und hilf das Projekt zu verbessern. Davon lebt das Projekt. OpenGeoDB
ist kein Produkt, das du gekauft hast und es gibt keine Support-Garantie
die du in Anspruch nehmen kannst.

> >> Da kann ich leider nur sehr begrenzt beitragen, weil mir die
> >> Voraussetzungen, insbesondre was Verwaltungsgliederungen anderer Staaten
> >> anbelangt, nicht bekannt sind.
> >
> > Darum geht es nicht. Du könntest -mit etwas gutem Willen- selbst prüfen,
> > ob das, was du hier anregst, sinnvoll ist und ob die Kritik die du übst
> > berechtigt ist.
>
> Ob irgendetwas sinnvoll oder berechtigt ist, ist immer eine Frage der
> Sichtweise.

Wiederholte Kritik, die ohne die Bereitschaft geäußert wird, sich mit
dem kritisierten Objekt auch in der Tiefe zu beschäftigen ist niemals
berechtigt, das ist keine Frage der Sichtweise.

Du kommst hier ständig mit Redundanz und Normalisierung, ohne einen
einzigen konkreten Datensatz anzuführen, der deine Behauptungen
untermauert.

> Ich bin der Meinung, eine weitere Diskussion bringt uns nicht weiter,
> weil die Standpunkte einfach zu verschieden sind.

Dir stehen die Daten der OpenGeoDB frei zur Verfügung, mach damit was
dir sinnvoll erscheint. Falls Du etwas zustande bringst, was Deiner
Meinung nach besser ist als der Status Quo kannst Du das ja
veröffentlichen. Aber erwarte nicht, dass andere die Arbeit für dich
erledigen.

Gruß
Stephan

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Robert Böck]

Hallo Stephan,

Stephan Schuster wrote:

>> Das ändert aber nichts daran, dass geodb_textdata.text_type redundant
>> ist. Jedenfalls meiner Auffassung nach.
>
> ??? Fremdschlüssel sind nahezu immer redundant vorhanden, das liegt in
> der Natur der Sache.

Fremdschlüssel?

Ein Feld, das mit einer Konstante verglichen wird, ist dann auf einmal
ein Fremdschlüssel?

Ein Fremdschlüssel ist für mich ein Feld, das mit einem Primärschlüssel
in einer anderen Tabelle verglichen wird ...

>> > Wo ist text_type nicht atomar? Belege deine Behauptungen bitte mit Beispielen!
>>
>> Wer behauptet das?
>
> Du. Hier:
>>> >> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht.
>  Du hast dich sogar selbst zitiert. Einen Beleg hast Du noch nicht
>  geliefert...

text_type != geodb_textdata

[opengeodb 0.1.3]
>> Und auch wenn es dir wahrscheinlich nicht gefällt, muss ich sagen, dass
>> die Tabelle geodb_locations hochgradig redundante Daten enthält. Was
>> soll bitte daran normalisiert sein, wenn immer wieder "Landkreis xyz"
>> drinsteht? Die Landkreise gehören in eine eigene Tabelle und über
>> Fremdschlüssel in der geodb_locations referenziert. Und nicht nur die
>> Landkreise.
>
> Wieder eine Behauptung, ohne  Beleg oder Beispiel. Wo steht immer wieder
> ""Landkreis xyz"?

"Landkreis Ostallgäu" kommt z. B. so ziemlich genau 45 mal vor ...

> Konkret:
>
> SELECT DISTINCT *
> FROM geodb_locations
> WHERE loc_type =100500000

loc_type? Wo bitte gibt es bei der 0.1.3 einen loc_type?

Ich darf daran erinnern, dass du die 0.1.3 ins Gespräch gebracht hast!

>> > Die Bereitschaft zu lernen und sich mit den Dingen auseinanderzusetzen
>> > sind nun einmal Vorraussetzung hier.
>>
>> Dann empfehle ich dir, Ungarisch zu lernen. Ich kann es nicht, aber ich
>> weiß, dass es als Erwachsener extrem schwierig bis nahezu unmöglich ist.
>>
>> Finnisch soll im Übrigen ähnlich schwierig sein.
>
> Du möchtest also, dass die Ungarn und die Finnen ihre Sprache
> vereinfachen, damit du sie leichter lernen kannst?

Ich wollte lediglich verdeutlichen, dass eine Sache zu verstehen nicht
unbedingt etwas mit der Bereitschaft zu lernen zu tun hat.

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Robert Böck]

Hallo Peter,

Peter Wendorff wrote:

>>> Selbst wenn Du nicht weisst, wie die
>>> Hierarchie-Strukturen woanders aufgebaut sind, wirst Du wissen, dass es
>>> Staaten gibt, die keine Bundesländer besitzen, wie gehst Du damit um?
>>
>> Ich hänge die nächste Verwaltungsebene einfach eine Ebene höher ein. Es
>> muss natürlich dann dokumentiert sein oder noch besser eine Tabelle
>> geben, in der die Verwaltungsstrukturen für jedes Land gespeichert sind.
>>  
> Und dann willst Du nach Städten suchen - wie machst Du das?

Das ist dann doch für jedes Land dokumentiert, auf welcher Ebene jeweils
die Städte zu finden sind.

> Mit den Teil-Von-Beziehungen in Reinform ginge das noch, aber damit ist
> die geodb_hierarchies wieder nicht dabei, die so viele unbedingt haben
> wollen (ich bin mir grade nicht sicher, ob Du auch zu der Fraktion
> gehörst, die die hierarchies haben wollten).

Da bin ich mir selbst nicht sicher. Martin sagt, die hierarchies wären
überflüssig.

Ich habe mir mal Abfragen zusammengebaut (anhand der auf Sourceforge
vorhandenen Beispiele), die die hierarchies benutzen. Somit
funktionieren die Abfragen ohne die hierarchies nicht. Und ich gebe ganz
ehrlich zu, dass ich momentan keinen blassen Schimmer davon habe, wie
ich die Anfragen umbauen soll, damit sie ohne hierarchies funktionieren.
Ich habe mich allerdings auch noch nicht wirklich intensiv damit
auseinandergesetzt.

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Peter Wendorff]

Robert Böck schrieb:

> Hallo Peter,
>
> Peter Wendorff wrote:
>
>  
>>>> Selbst wenn Du nicht weisst, wie die
>>>> Hierarchie-Strukturen woanders aufgebaut sind, wirst Du wissen, dass es
>>>> Staaten gibt, die keine Bundesländer besitzen, wie gehst Du damit um?
>>>>        
>>> Ich hänge die nächste Verwaltungsebene einfach eine Ebene höher ein. Es
>>> muss natürlich dann dokumentiert sein oder noch besser eine Tabelle
>>> geben, in der die Verwaltungsstrukturen für jedes Land gespeichert sind.
>>>  
>>>      
>> Und dann willst Du nach Städten suchen - wie machst Du das?
>>    
>
> Das ist dann doch für jedes Land dokumentiert, auf welcher Ebene jeweils
> die Städte zu finden sind.
>  

Klar ist das dokumentiert.
Also ich hätte gerne alle Städte, die in der Opengeodb verzeichnet sind.
Du sagst, das ist für jedes Land dokumentiert, auf welcher Ebene die zu
finden sind - also schreibst Du mir dafür dann eine Abfrage, die mit
zigfachem IF jede unterschiedliche Regelung extra berücksichtigt?
Ich suche einfach nach Einträgen, bei denen die Ebene stimmt und kümmere
mich nicht darum, ob andere Ebenen unter Umständen fehlen oder nicht -
und das funktioniert, weil eben alle Städte auf der gleichen Ebene zu
finden sind.

Gruß
Peter

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

 Hallo Robo,

>
> Stephan Schuster wrote:
>
> >> Das ändert aber nichts daran, dass geodb_textdata.text_type redundant
> >> ist. Jedenfalls meiner Auffassung nach.
> >
> > ??? Fremdschlüssel sind nahezu immer redundant vorhanden, das liegt in
> > der Natur der Sache.
>
> Fremdschlüssel?
>
> Ein Feld, das mit einer Konstante verglichen wird, ist dann auf einmal
> ein Fremdschlüssel?

Falls Du dich auf die constants.txt beziehst, die früher die Bedeutung
des text_type definiert hat: Diese ist mittlerweile durch die Tabelle
geodb_type_names ersetzt worden. Falls diese bei dir nicht existiert,
könnte dir das bereits die Schwierigkeiten verdeutlichen, die Änderungen
in der Datenbank-Struktur mit sich bringen. Wenn ich mich noch einmal
kurz selbst zitieren darf (das hätte dir den Zusammenhang verdeutlichen
sollen, falls Du versuchst zu verstehen was ich schreibe):

| Wenn Du möchtest, kannst Du geodb_textdata.text_type auch als
| Fremdschlüssel aus der Tabelle geodb_type_names sehen, das kommt deinem
| Verständnis von Datenbank-Modellen und Normalisierung sicher näher.

[...]

> >> > Wo ist text_type nicht atomar? Belege deine Behauptungen bitte mit Beispielen!
> >>
> >> Wer behauptet das?
> >
> > Du. Hier:
> >>> >> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht.
> >  Du hast dich sogar selbst zitiert. Einen Beleg hast Du noch nicht
> >  geliefert...
>
> text_type != geodb_textdata

Relation != Attribut
Lies mal den Artikel den Du aus der Wikipedia angeführt hast und
beantworte die Frage, wie eine Relation atomar sein soll. Dann prüfst Du
die Attribute der Relation geodb_textdata und erklärst welches nicht
atomar ist. Das Ergebnis deiner Prüfung teilst Du uns dann bitte mit.
Oder du führst mal ein Beispiel an, was deiner Meinung nach nicht atomar
ist...
 

> [opengeodb 0.1.3]
> >> Und auch wenn es dir wahrscheinlich nicht gefällt, muss ich sagen, dass
> >> die Tabelle geodb_locations hochgradig redundante Daten enthält. Was
> >> soll bitte daran normalisiert sein, wenn immer wieder "Landkreis xyz"
> >> drinsteht? Die Landkreise gehören in eine eigene Tabelle und über
> >> Fremdschlüssel in der geodb_locations referenziert. Und nicht nur die
> >> Landkreise.
> >
> > Wieder eine Behauptung, ohne  Beleg oder Beispiel. Wo steht immer wieder
> > ""Landkreis xyz"?
>
> "Landkreis Ostallgäu" kommt z. B. so ziemlich genau 45 mal vor ...
>
> > Konkret:
> >
> > SELECT DISTINCT *
> > FROM geodb_locations
> > WHERE loc_type =100500000
>
> loc_type? Wo bitte gibt es bei der 0.1.3 einen loc_type?
>
> Ich darf daran erinnern, dass du die 0.1.3 ins Gespräch gebracht hast!

Nein, ich habe dir angeboten, dir einen Dump der 0.1.3 zu schicken,
damit du vergleichen kannst, wie unzureichend die Daten darin abgebildet
sind.

Willst Du damit sagen, Du wolltest mir erklären, dass die Struktur der
0.1.3 schlecht ist? Da stimmen wir absolut überein, allerdings ist mir
wirklich schleierhaft, wie Du aus dem (ich zitiere nochmal) Absatz

|Die jetzige Struktur ist aus der Erkenntnis entstanden, dass die, die du
|favorisierst, den anfallenden Daten nicht gerecht wird, denn eine solche
|Struktur war ursprünglich vorhanden. Ich schick Dir gerne mal einen Dump
|der opengeodb 0.1.3. Und ich kann dir versichern dass Normalisierung
|bei der Entwicklung der jetzigen Struktur auch ein großes Thema war. Und
|wenn du wieder behaupten willst, das Schema wäre nicht normalisiert,
|bring Belege, wenn du weiter ernst genommen werden willst.

schließt, dass sich meine Aussagen auf die 0.1.3 beziehen...
Falls es dir entgangen ist: wir diskutieren hier stets auf Grundlage der
aktuellen Datenbank-Struktur, die Martin dankenswerterweise unter
http://fa-technik.adfc.de/code/opengeodb/ bereitstellt.

[...]
> Ich wollte lediglich verdeutlichen, dass eine Sache zu verstehen nicht
> unbedingt etwas mit der Bereitschaft zu lernen zu tun hat.

Muss man hier alle Selbstverständlichkeiten durchkauen? Man benötigt die
Fähigkeit und die Bereitschaft sich mit dem Datenbank-Schema und der
Organisation von Geodaten auseinander zu setzen. Wer eines von beiden
nicht mitbringt, sollte sich einfach überlegen, ob es nicht Hobbies gibt
die seinen Fähigkeiten oder Kenntnissen besser entsprechen.

Gruß
Stephan

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Thomas Preymesser]

On 21/03/2008, Stephan Schuster <stephan.s@...> wrote:

BTW: Für 1:1 Beziehungen willst Du eigene Relationen schaffen? Unsinnig.

nö, nicht zwangsläufig. Manchmal kann das durchaus sinnvoll sein.

-Thomas

--
Thomas Preymesser
thopre@...
Telefon: 030 - 49 78 37 06
http://thopre.wordpress.com/
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

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.

Die hohe Anzahl an Ergebnisdatensätzen kam mir doch seltsam vor, da ich
irgendwie im Hinterkopf hatte, es gäbe ca. 16000 Postleitzahlen, die für
Ortschaften und Städte gültig sind. Also habe ich geprüft, welchen
loc_ids die Postleitzahlen zugeordnet sind:

SELECT count(*), gtn.type_id, gtn.name
FROM geodb_textdata plz
LEFT JOIN geodb_locations gl ON plz.loc_id = gl.loc_id
LEFT JOIN geodb_type_names gtn ON gl.loc_type = gtn.type_id
WHERE plz.text_type = 500300000
GROUP BY gtn.type_id;

Ergebnis:

+----------+-----------+-----------------------+
| count(*) | type_id   | name                  |
+----------+-----------+-----------------------+
|        2 | 100500000 | Landkreis             |
|    14099 | 100600000 | Politische Gliederung |
|     2437 | 100700000 | Ortschaft             |
|    44148 | 100800000 | Postleitzahlgebiet    |
+----------+-----------+-----------------------+
4 rows in set (2.54 sec)

Ich denke die zwei Landkreis-Zuordnungen für Goslar sind Fehler in der
Datenbank?

SELECT plz.text_val AS plz, txt.loc_id, txt.text_val AS name
FROM geodb_textdata plz
LEFT JOIN geodb_textdata txt ON gl.loc_id = txt.loc_id
LEFT JOIN geodb_locations gl ON plz.loc_id = gl.loc_id
LEFT JOIN geodb_type_names gtn ON gl.loc_type = gtn.type_id
WHERE plz.text_type = 500300000
  AND gl.loc_type = 100500000
  AND txt.text_type = 500100000;
 
+-------+--------+--------+
| plz   | loc_id | name   |
+-------+--------+--------+
| 38640 |    569 | Goslar |
| 38642 |    569 | Goslar |
+-------+--------+--------+
2 rows in set (0.03 sec)


Wenn ich Ortschaften und politische Gliederungen zusammenzähle, komme
ich auf den geschätzten Wert, wie aber sind in diesem Zusammenhang die
Postleitzahl-Gebieten zu werten?

Bisher erfolgt(e?) die Zuweisung der Koordinaten über die Zuordnung von
PLZ zu Ort, wobei die Postleitzahl dann eben die Koordinaten des Ortes
erhielt. Ist diese Vorgehensweise somit überholt?

Wenn ich Martins Entwurf zu Punkt 2 der README / Doku richtig
interpretiere, dann können jetzt über die Postleitzahlgebiete direkt den
PLZ Koordinaten zugewiesen werden, richtig? Das wäre ja eine
bemerkenswerte Verbesserung, sollte dann die Abfrage zur Auswahl der
passenden Datensätze nicht auf die Postleitzahl-Gebiete eingeschränkt
werden, also:

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_locations gl ON gl.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 */
  AND gl.loc_type = 100800000 /* ID für PLZ-Gebiet */;
 

Gruß
Stephan

--
Stephan Schuster <stephan.s@...>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Stephan S wrote:

> 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.
>
> Die hohe Anzahl an Ergebnisdatensätzen kam mir doch seltsam vor, da ich
> irgendwie im Hinterkopf hatte, es gäbe ca. 16000 Postleitzahlen, die für
> Ortschaften und Städte gültig sind. Also habe ich geprüft, welchen
> loc_ids die Postleitzahlen zugeordnet sind:
>
> SELECT count(*), gtn.type_id, gtn.name
> FROM geodb_textdata plz
> LEFT JOIN geodb_locations gl ON plz.loc_id = gl.loc_id
> LEFT JOIN geodb_type_names gtn ON gl.loc_type = gtn.type_id
> WHERE plz.text_type = 500300000
> GROUP BY gtn.type_id;
>
> Ergebnis:
>
> +----------+-----------+-----------------------+
> | count(*) | type_id   | name                  |
> +----------+-----------+-----------------------+
> |        2 | 100500000 | Landkreis             |
> |    14099 | 100600000 | Politische Gliederung |
> |     2437 | 100700000 | Ortschaft             |
> |    44148 | 100800000 | Postleitzahlgebiet    |
> +----------+-----------+-----------------------+
> 4 rows in set (2.54 sec)
>
> Ich denke die zwei Landkreis-Zuordnungen für Goslar sind Fehler in der
> Datenbank?

Ja, Landkreise haben keine PLZ

Die 100800000 sind aber wohl ein Eigentor von mir - die werden einfach
aus der Ebene gebildet (hier Ebene 8) und sind da aber falsch. Die
aktuellen Dumps sollten eigentlich überhaupt keine PLZ-Gebiete
enthalten. Entweder patche ich mein script oder ich korrigiere die
type-Declaration!?


> Bisher erfolgt(e?) die Zuweisung der Koordinaten über die Zuordnung von
> PLZ zu Ort, wobei die Postleitzahl dann eben die Koordinaten des Ortes
> erhielt. Ist diese Vorgehensweise somit überholt?

Ja, schon lange

> Wenn ich Martins Entwurf zu Punkt 2 der README / Doku richtig
> interpretiere, dann können jetzt über die Postleitzahlgebiete direkt den
> PLZ Koordinaten zugewiesen werden, richtig? Das wäre ja eine
> bemerkenswerte Verbesserung, sollte dann die Abfrage zur Auswahl der
> passenden Datensätze nicht auf die Postleitzahl-Gebiete eingeschränkt
> werden, also:

Im Prinzip ja - wobei die entsprechenden PLZ-Gebiets-Daten derzeit in
der PLZ.tab stecken und derzeit noch nicht im Dump dabei sind. Dafür
muss ich eine andere Konvertierung hinzufügen.

Schönen Gruß
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

Hallo Martin,

> > Die hohe Anzahl an Ergebnisdatensätzen kam mir doch seltsam vor, da ich
> > irgendwie im Hinterkopf hatte, es gäbe ca. 16000 Postleitzahlen, die für
> > Ortschaften und Städte gültig sind. Also habe ich geprüft, welchen
> > loc_ids die Postleitzahlen zugeordnet sind:
> >
> > SELECT count(*), gtn.type_id, gtn.name
> > FROM geodb_textdata plz
> > LEFT JOIN geodb_locations gl ON plz.loc_id = gl.loc_id
> > LEFT JOIN geodb_type_names gtn ON gl.loc_type = gtn.type_id
> > WHERE plz.text_type = 500300000
> > GROUP BY gtn.type_id;
> >
> > Ergebnis:
> >
> > +----------+-----------+-----------------------+
> > | count(*) | type_id   | name                  |
> > +----------+-----------+-----------------------+
> > |        2 | 100500000 | Landkreis             |
> > |    14099 | 100600000 | Politische Gliederung |
> > |     2437 | 100700000 | Ortschaft             |
> > |    44148 | 100800000 | Postleitzahlgebiet    |
> > +----------+-----------+-----------------------+
> > 4 rows in set (2.54 sec)
> >
> > Ich denke die zwei Landkreis-Zuordnungen für Goslar sind Fehler in der
> > Datenbank?
>
> Ja, Landkreise haben keine PLZ
>
> Die 100800000 sind aber wohl ein Eigentor von mir - die werden einfach
> aus der Ebene gebildet (hier Ebene 8) und sind da aber falsch. Die
> aktuellen Dumps sollten eigentlich überhaupt keine PLZ-Gebiete
> enthalten. Entweder patche ich mein script oder ich korrigiere die
> type-Declaration!?
>
>
> > Bisher erfolgt(e?) die Zuweisung der Koordinaten über die Zuordnung von
> > PLZ zu Ort, wobei die Postleitzahl dann eben die Koordinaten des Ortes
> > erhielt. Ist diese Vorgehensweise somit überholt?
>
> Ja, schon lange

Das verstehe ich dann allerdings nicht so richtig: Wenn Du die
Postleitzahlgebiete eigentlich gar nicht veröffentlichen willst, und die
Koordinaten-Zuordnung der PLZ über den Ort veraltet ist, wie gehe ich
denn dann korrekt vor, um eine PLZ zu verorten?

schönen Gruß
Stephan

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Stephan Schuster wrote:

>>> Bisher erfolgt(e?) die Zuweisung der Koordinaten über die Zuordnung von
>>> PLZ zu Ort, wobei die Postleitzahl dann eben die Koordinaten des Ortes
>>> erhielt. Ist diese Vorgehensweise somit überholt?
>> Ja, schon lange
>
> Das verstehe ich dann allerdings nicht so richtig: Wenn Du die
> Postleitzahlgebiete eigentlich gar nicht veröffentlichen willst, und die
> Koordinaten-Zuordnung der PLZ über den Ort veraltet ist, wie gehe ich
> denn dann korrekt vor, um eine PLZ zu verorten?

Die letzte opengeodb-release vor meiner Zeit enthielt die 10080000. Bei
mir flog sie erst mal raus, weil sie nicht in die Systematik passt.
Obendrein hat sie keinen grossen Aktualisierungsbedarf, weil sie sich
selten ändert und nahezu vollständig war.

Ich wollte da erst mal abwarten, wie sehr sie gefragt wird - und sie
unter Umständen völlig losgelöst anbieten. Denn eine der
Hauptanwendungen der gesamten opengeodb.de war oft nur eine Umkreissuche
nach PLZ. Da erscheint es einfacher, sich gleich nur auf die PLZ-Gebiete
zu beschränken und den Rest wegzulassen.

Auf Nachfrage habe ich also die PLZ.tab in das opengeodb-Verzeichnis
eingespielt (verlinkt), die ich selbst auch für die Umkreissuche auf
http://fa-technik.adfc.de/code/anbieter einsetze.

opengeodb bot das also schon seit einigen Jahren an - enthält es in der
aktuellen Release aber nicht mehr. Demzufolge kann man sich in der
aktuellen Release PLZ-Koordinaten wiederum über die Orte abholen. Gerade
bei Großstädten hatten wir früher keinerlei Ortsteile und damit eine
Orts-Koordinaten mit vielen zugehörigen PLZ-Einträgen. Nun haben wir
zunehmend auch Ortsteile und damit zunehmend eine genauere Auflösung der
tatsächlichen PLZ-Verteilung in einer Großstadt.

Kommen nun auch noch Straßen mit PLZ hinzu, so wird die Auflösung noch
genauer, als die reinen PLZ-Gebiets-Koordinaten anbieten können.

Dennoch wird die PLZ.tab vielleicht mal wieder in SQL-Form angeboten und
im Dump mitgeführt. Die Priorität dafür ist aber vergleichsweise gering,
die Daten haben mit opengeodb wenig zu tun und geben eine völlig andere
Systematik wieder.

Schönen Gruß
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Stephan Schuster]

> Stephan Schuster wrote:
>
> >>> Bisher erfolgt(e?) die Zuweisung der Koordinaten über die Zuordnung von
> >>> PLZ zu Ort, wobei die Postleitzahl dann eben die Koordinaten des Ortes
> >>> erhielt. Ist diese Vorgehensweise somit überholt?
> >> Ja, schon lange
> >
> > Das verstehe ich dann allerdings nicht so richtig: Wenn Du die
> > Postleitzahlgebiete eigentlich gar nicht veröffentlichen willst, und die
> > Koordinaten-Zuordnung der PLZ über den Ort veraltet ist, wie gehe ich
> > denn dann korrekt vor, um eine PLZ zu verorten?
>
> Die letzte opengeodb-release vor meiner Zeit enthielt die 10080000. Bei
> mir flog sie erst mal raus, weil sie nicht in die Systematik passt.
> Obendrein hat sie keinen grossen Aktualisierungsbedarf, weil sie sich
> selten ändert und nahezu vollständig war.
>
> Ich wollte da erst mal abwarten, wie sehr sie gefragt wird - und sie
> unter Umständen völlig losgelöst anbieten. Denn eine der
> Hauptanwendungen der gesamten opengeodb.de war oft nur eine Umkreissuche
> nach PLZ. Da erscheint es einfacher, sich gleich nur auf die PLZ-Gebiete
> zu beschränken und den Rest wegzulassen.
>
> Auf Nachfrage habe ich also die PLZ.tab in das opengeodb-Verzeichnis
> eingespielt (verlinkt), die ich selbst auch für die Umkreissuche auf
> http://fa-technik.adfc.de/code/anbieter einsetze.
>
> opengeodb bot das also schon seit einigen Jahren an - enthält es in der
> aktuellen Release aber nicht mehr. Demzufolge kann man sich in der
> aktuellen Release PLZ-Koordinaten wiederum über die Orte abholen. Gerade
> bei Großstädten hatten wir früher keinerlei Ortsteile und damit eine
> Orts-Koordinaten mit vielen zugehörigen PLZ-Einträgen. Nun haben wir
> zunehmend auch Ortsteile und damit zunehmend eine genauere Auflösung der
> tatsächlichen PLZ-Verteilung in einer Großstadt.

Da, wie du erwähnt hast, die Nutzung der Opengeodb hauptsächlich
in der Realisation einer PLZ-Umkreissuche besteht möchte ich in der Doku
gerne exemplarisch aufzeigen wie man die Daten dafür aufbereiten kann.
Leider bin ich aus Deiner Antwort immer noch nicht ganz schlau geworden
wie man dafür nun am besten vorgeht.

Das würde also bedeuten, um aus der Datenbank einer PLZ Koordinaten
zuzuordnen, würde man nach wie vor prüfen, welchen Orten die PLZ
zugeordnet ist und die entsprechenden Koordinaten verwenden. Dies
schließt dann die Möglichkeit ein, dass eine PLZ mehrere Koordinaten
haben kann.

Ich würde also die eingangs erwähnte Abfrage auf Postleitzahlen die
einer Location mit loc_id vom Typ 100600000 (pol. Gliederung) oder
100700000 (Ortschaft) einschränken und damit die PLZ-Gebiete außen vor
lassen.

SELECT gl.loc_id, plz.text_val AS plz, name.text_val AS ort, coord.lat, coord.lon
FROM geodb_textdata plz
LEFT JOIN geodb_textdata name ON name.loc_id = plz.loc_id
LEFT JOIN geodb_locations gl ON gl.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 */
  AND (
       gl.loc_type = 100600000 /* ID für pol. Gliederung */
       OR
       gl.loc_type = 100700000 /* ID für Ortschaft */
  );

Das ergäbe dann 16536 Datensätze. Falls man später dann PLZ zu Strassen
zuordnen kann müsste dies dann angepasst werden.

> Kommen nun auch noch Straßen mit PLZ hinzu, so wird die Auflösung noch
> genauer, als die reinen PLZ-Gebiets-Koordinaten anbieten können.
>
> Dennoch wird die PLZ.tab vielleicht mal wieder in SQL-Form angeboten und
> im Dump mitgeführt. Die Priorität dafür ist aber vergleichsweise gering,
> die Daten haben mit opengeodb wenig zu tun und geben eine völlig andere
> Systematik wieder.

Vielleicht sollte man auch alternativ die Vorgehensweise erläutern, wie
man die plz.tab in eine Datenbank-Tabelle überführen kann...

Außerdem sollte man vielleicht im Wiki eine Art changelog führen, um
festzuhalten, wie sich Struktur, sowie Art und Umfang der enthaltenen
Daten ändern...


schönen Gruß
Stephan

--
Stephan Schuster <stephan.s@...>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)