Fehler in PLZ.tab

[Matthias Dietrich-2]

Hi,

ich misch mich mal ganz kurz ein...

> Ehrlich gesagt - die SQL-Datenstruktur ist eine einzige Katastrophe. Von
> Normalisierung keine Spur. Da blickt doch kaum jemand durch.

Da muss ich dir absolut Recht geben, Robert!

> Und du wunderst dich, dass dann unpräzise Fragen kommen. Mich wundert das
> überhaupt nicht.

So wie ich das sehe, kann Martin allerdings gar nichts für diese
Struktur.  Die hatte er ja einfach nur übernommen.  Ich hatte damit auch
schon meine Schwierigkeiten, und habe es soweit durch dringen können,
wie ich es bisher gebraucht habe.  Dennoch möchte ich irgendwann die
Daten für meine Zwecke neu ordnen, damit die Suche nicht so ewig dauert.

Dabei habe ich mir auch schon überlegt, dass man gemeinsam eine
komplette und sinnvolle Architektur für das ganze finden.  Allerdings
hatte ich dazu noch keine Zeit.  Aber wenn sich ein paar finden, die da
mitmachen würden, könnte man sich schonmal vorab per Liste unterhalten
und mit dem Definieren beginnen.

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

[Matthias Dietrich-2]

Uarks!

Matthias Dietrich schrieb:
> [... schlechtes Deutschsprech ...]

Sorry, ich bin wohl schon ein wenig müde.  Ich hoffe, man kann
verstehen, was ich eigentlich meine ;).

Viele Grüße,
   Matthias
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Robert Böck wrote:
> Ehrlich gesagt - die SQL-Datenstruktur ist eine einzige Katastrophe.

Ich finde auch, dass die recht unuebersichtlich ist - deswegen verwende
ich selbst sie ja auch nicht, deswegen gibt es auch IMHO sehr
übersichtliche .txt-Varianten.

Der Teil auf der Liste hier ist aber nur ein kleiner Teil der Geschichte
(vgl. Sourceforge-Foren) - und wenn man Antworten will, dann sollte man
sich auch bei den Fragen etwas Muehe geben.

Wenn er SQL verwenden will, sein Problem. Vorauszusetzen, dass jeder
andere weiss, was SEINE Befehle auf SEINER Version der Daten in SEINER
SQL-Umgebung ergeben, erscheint mir etwas zu abgehoben.

Ich kann aber auch einfach die Klappe halten und mir die Arbeit der
Antworten sparen. Hilfst du ihm bitte weiter?

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

[Robert Böck]

Hallo Matthias,

Matthias Dietrich wrote:

> ich misch mich mal ganz kurz ein...

Gerne doch!

>> Ehrlich gesagt - die SQL-Datenstruktur ist eine einzige Katastrophe. Von
>> Normalisierung keine Spur. Da blickt doch kaum jemand durch.
>
> Da muss ich dir absolut Recht geben, Robert!

Mal ein kleines Beispiel. Ich habe mir vor längerer Zeit mal eine
Abfrage gestrickt, die alle Orte in Bayern ausspuckt, inklusive
Geokoordinaten, KFZ-Kennzeichen und Landkreis-Zugehörigkeit:

SELECT ort.loc_id as l_ort,
       ort.text_val as t_ort,
       coord.lon as lon,
       coord.lat as lat,
       kfz.text_val as t_kfz,
       hi.id_lvl5 as lkr_id
FROM geodb_hierarchies hi,
     geodb_textdata land,
     geodb_textdata ort,
     geodb_textdata bundesland,
     geodb_textdata kfz,
     geodb_coordinates coord,
     geodb_locations loc
WHERE hi.id_lvl2=land.loc_id AND
      land.text_val='DE' AND
      land.text_type=500100001 AND
      hi.id_lvl3=bundesland.loc_id AND
      bundesland.text_val='BY' AND
      bundesland.text_type=500100001 AND
      ort.loc_id=hi.loc_id AND
      ort.text_type=500100000 AND
      hi.loc_id=hi.id_lvl6 AND
      loc.loc_id=hi.loc_id AND
      loc.loc_type=100700000 AND
      coord.loc_id=hi.loc_id AND
      kfz.loc_id=hi.loc_id AND
      kfz.text_type=500500000
ORDER BY l_ort

Um jetzt eine Liste der Landkreise in Bayern rauszubekommen, um die Orte
selbigen zuordnen zu können, braucht es immerhin noch diese Abfrage:

SELECT ort.loc_id as l_ort,
       ort.text_val as t_ort,
       hi.id_lvl4 as rbez_id
FROM geodb_hierarchies hi,
     geodb_textdata land,
     geodb_textdata ort,
     geodb_textdata bundesland
WHERE hi.id_lvl2=land.loc_id AND
      land.text_val='DE' AND
      land.text_type=500100001 AND
      hi.id_lvl3=bundesland.loc_id AND
      bundesland.text_val='BY' AND
      bundesland.text_type=500100001 AND
      ort.loc_id = hi.loc_id AND
      ort.text_type = 500100000 AND
      hi.loc_id=hi.id_lvl5
ORDER BY l_ort

Die Abfrage, um eine Liste der Regierungsbezirke in Bayern
rauszubekommen, um die Landkreise selbigen zuordnen zu können, ist nicht
minder kompliziert:

SELECT ort.loc_id as l_ort,
       ort.text_val as t_ort
FROM geodb_hierarchies hi,
     geodb_textdata land,
     geodb_textdata ort,
     geodb_textdata bundesland
WHERE hi.id_lvl2=land.loc_id AND
      land.text_val='DE' AND
      land.text_type=500100001 AND
      hi.id_lvl3=bundesland.loc_id AND
      bundesland.text_val='BY' AND
      bundesland.text_type=500100001 AND
      ort.loc_id = hi.loc_id AND
      ort.text_type = 500100000 AND
      hi.loc_id=hi.id_lvl4
ORDER BY l_ort

Und da frage ich mich: Wer bitteschön soll da durchblicken? Ich habe mir
das mal vor einem guten Jahr zusammengepfriemelt, und heute blicke ich
da selbst auch nicht mehr durch ...

>> Und du wunderst dich, dass dann unpräzise Fragen kommen. Mich wundert das
>> überhaupt nicht.
>
> So wie ich das sehe, kann Martin allerdings gar nichts für diese
> Struktur.  Die hatte er ja einfach nur übernommen.

Und da hast _du_ vollkommen recht. Das ist auch keine Kritik gegenüber
Martin, sondern eine Feststellung.

Was ich allerdings an Martin kritisiere, ist, dass er Leute schwach
anmacht, die aufgrund der Tatsache, dass die Datenstruktur
unübersichtlich ist, ganz offensichtlich einfach nicht richtig durchblicken.

> Ich hatte damit auch
> schon meine Schwierigkeiten, und habe es soweit durch dringen können,
> wie ich es bisher gebraucht habe.  Dennoch möchte ich irgendwann die
> Daten für meine Zwecke neu ordnen, damit die Suche nicht so ewig dauert.
>
> Dabei habe ich mir auch schon überlegt, dass man gemeinsam eine
> komplette und sinnvolle Architektur für das ganze finden.  Allerdings
> hatte ich dazu noch keine Zeit.  Aber wenn sich ein paar finden, die da
> mitmachen würden, könnte man sich schonmal vorab per Liste unterhalten
> und mit dem Definieren beginnen.

Dein Wort in Gottes Gehörgang. Allerdings mangelt es mir auch an Zeit ...

cu, Robo :)

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

[Martin Trautmann]

Robert Böck wrote:

> Mal ein kleines Beispiel. Ich habe mir vor längerer Zeit mal eine
> Abfrage gestrickt, die alle Orte in Bayern ausspuckt, inklusive
> Geokoordinaten, KFZ-Kennzeichen und Landkreis-Zugehörigkeit:

Die einfache Lösung: Suche nach allen Orten, bei denen der
Gemeindeschlüssel mit 09 beginnt - so mache ich das.

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

[Robert Böck]

Hallo Martin,

Martin Trautmann wrote:

>> Ehrlich gesagt - die SQL-Datenstruktur ist eine einzige Katastrophe.

> Ich finde auch, dass die recht unuebersichtlich ist - deswegen verwende
> ich selbst sie ja auch nicht, deswegen gibt es auch IMHO sehr
> übersichtliche .txt-Varianten.

Natürlich, die OpenGeoDB ist Open Source, und jeder kann - im Rahmen der
Lizenz - damit machen, was er will. Und wenn du dich entschieden hast,
die OpenGeoDB in Form von Textdateien weiterzupflegen, ist das deine
freie Entscheidung.

Das Problem ist aber, dass die OpenGeoDB früher als SQL-Dump verteilt
wurde, und dass es sicher viele Anwendungen gibt, die mit der
SQL-Version umgehen können, nicht aber mit den Textdateien.

Und das Problem ist, dass in der aktuellen SQL-Distribution Tabellen
fehlen, ohne die früher gebaute SQL-Statements nicht funktionieren.

Und ganz offensichtlich gibt es auch viele Leute, die die OpenGeoDB
gerne in Form einer SQL-Datenbank verwenden möchten.

> Der Teil auf der Liste hier ist aber nur ein kleiner Teil der Geschichte
> (vgl. Sourceforge-Foren) - und wenn man Antworten will, dann sollte man
> sich auch bei den Fragen etwas Muehe geben.
>
> Wenn er SQL verwenden will, sein Problem.

Also bitte! Eine relationale Datenbank ist das Mittel der Wahl, um
solche Datenbestände zu verwalten. Und damit wären wir bei SQL ...

Und wenn ich eine irgendeine Abfrage machen will, muss ich im
einfachsten Fall einfach nur einen SQL-Befehl in die SQL-Konsole
eintippen. Bei Textdateien muss ich mir schon ein Script stricken ...

> Vorauszusetzen, dass jeder
> andere weiss, was SEINE Befehle auf SEINER Version der Daten in SEINER
> SQL-Umgebung ergeben, erscheint mir etwas zu abgehoben.

Was heißt SEINE Version? Wenn man, wovon in den meisten Fällen
auszugehen ist, die Version benutzt, die zum Download angeboten wird,
dann ist es eine klar definierte Version, und nicht SEINE Version ...

> Ich kann aber auch einfach die Klappe halten und mir die Arbeit der
> Antworten sparen. Hilfst du ihm bitte weiter?

Sorry, ich kann da nicht weiterhelfen, weil ich mich mit der
SQL-Katastrophe schon seit über einem Jahr nicht mehr auseinandergesetzt
habe und mit den Textdateien noch nie.

cu, Robo :)

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

[Robert Böck]

Hallo Martin,

Martin Trautmann wrote:

>> Mal ein kleines Beispiel. Ich habe mir vor längerer Zeit mal eine
>> Abfrage gestrickt, die alle Orte in Bayern ausspuckt, inklusive
>> Geokoordinaten, KFZ-Kennzeichen und Landkreis-Zugehörigkeit:

> Die einfache Lösung: Suche nach allen Orten, bei denen der
> Gemeindeschlüssel mit 09 beginnt - so mache ich das.

Oha! Dazu muss man aber erst mal wissen, dass man das so machen kann.
Ich wusste es bisher nicht. Woher soll man das denn wissen? Und wenn man
es nicht sowieso weiß, dann wird man sich wohl kaum auf die Suche nach
dieser Information machen (können).

Meine Idee seinerzeit war halt, alle klar ersichtlichen Informationen
aus der Datenbank so zu verknüpfen, dass das übrigbleibt, was man gerne
haben möchte ...

cu, Robo :)

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

[Lucas Mengel]

 >>Warum weisst du das nicht? Kannst du nicht herausfinden, wofür die  
loc_id 105 steht? Es ist Deutschland -
dein Aufhänger für alle deutschen

Hi Martin! Vorab: Ich bin für JEDE, absolut JEDE, Hilfe von dir sehr
Dankbar.

Mein Problem ist teilweise auch, dass ich von dir Zahlen erfahre, die
für mich nicht nachvollziehbar sind, so wie 105.
Ich mache mir die ganze Zeit meine Gedanken darüber, wie du zwischen
zig-tausend Zahlen gerade auf 105 gekommen bist bzw. welchen
Weg du gegangen bist, um diese Zahl ausfindig zu machen.

Was genau 105 bedeutet weiss ich schon, seitdem du es im Forum
geschrieben hast.
Aber wie hast du das herausbekommen?

 >>Suche nach allem, was in 400100000 ein 105 enthält und in 400200000
eine 3. Damit solltest du anfangen, deine Hierarchies zu erstellen.

Warum nicht gleich:
"Um alle deutschen Städte/Infos zu ermitteln, brauchst du erstmal alle
deutschen Bundesländer."

Ok, die habe ich jetzt.
Ich habe mir selbstverständlich auch die Datensätze angeschaut, die sich
hinter den loc_id's der Bundesländer verbergen.

1. Die loc_id 117 steht z.B. für Nordrhein-Westfalen.

2. loc_id 14634 ist eine Stadt in Nordrhein-Westfalen, nämlich Bochum.

3. ich habe festgestellt, dass 117 und 14634 eine Gemeinsamkeit haben:
5006000000 (in 14634 die ersten beiden Stellen).

Soweit bin ich nun.
Was folgt weiter?

LG, Lucas






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

[Lucas Mengel]

Nebenbei: Was habt ihr eigentlich gegen SQL?
SQL ist die Standard-Abfrage-Sprache für Datenbanken. Das hat eigentlich
nichts mit Struktur oder so zu tun.
Es ist doch wurst ob man mit SQL eine einfache CSV-Datei, oder eine
komplexe Datenbank wie Oracle oder mySQL abfragt.

Und jetzt zur Sache:
Ich habe kürzlich mal im Internet recherchiert, wer alles die openGeoDB
einsetzt. Das habe ich herausgefunden, indem ich mir
den Quelltext der HTML-Seiten angesehen habe. Dort tauchen selbst in den
größten deutschen Communities die aus der
openGeoDB bekannten loc_id's auf.
Mir ist danach bewusst geworden, dass ich das Ausmaß der openGeoDB
völlig unterschätzt habe.
Diese Datenbank wird in zig-tausend Plattformen, überwiegend Flirt und
Social-Networks (web2.0-Seiten) mit teilweise ettlichen
Millionen von Mitgliedern eingesetzt.
Nach Stichproben der größten deutschen Communities komme ich zu dem
Fazit, dass ca. 50 Millionen deutsche Nutzer auf
die openGeoDB vertrauen.

In der Praxis ist die Anwendung fast immer identisch:
User geben über ein Web-Interface ihre Postleitzahl an, woraufhin in
einem für sie reservierten Datensatz die Koordinaten und
weitere Informationen aus der openGeoDB gespeichert werden.

Nun das entscheidende: Damit später eine wirklich effiziente
Umkreissuche entstehen kann müssen die Koordinaten in der
User-Datenbank der jeweiligen Community/Anwendung gespeichert werden.
Ich glaube kaum, dass irgendeine dieser Plattformen bei jeder
Suchanfrage dieses beknackte Ebenen-Modull durchläuft.
Ganz im Gegenteil: Die Betreiber solcher Seiten zerlegen die openGeoDB
in ihre Einzelteile und zwar solang, bis sie exakt ihrem
Anspruch entspricht.

Ich stelle außerdem einfach mal folgende Behauptung in den Raum:
Wer in der Lage ist, komplexe Umkreissuchen und Entfernungeberechnungen
umzusetzen, der ist auch in der Lage, eine eigene
Architektur zu entwickeln, die sich jeweils an den örtlichen
Gegebenheiten orientiert.
Anders formuliert: Wer eine Community basteln kann, der hat seine
eigenen Datenbankstrukturen und wenn er irgendetwas nicht
braucht, dann ist das ein Fremdkörper im eigenen System.

Ich bin nach wie vor der Meinung, man sollte einfach eine einzelne
SQL-Tabelle ausliefern und den Rest den Leuten überlassen.
Darunter sind hochbezahlte und qualifizierte Programmmierer, die dem
jeweiligen Betreiber eine maßgeschneiderte Lösung in sein
vorhandenes System implentieren.


LG,
Lucas

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

[Lucas Mengel]

>Und wenn ich eine irgendeine Abfrage machen will, muss ich im
>einfachsten Fall einfach nur einen SQL-Befehl in die SQL-Konsole
>eintippen. Bei Textdateien muss ich mir schon ein Script stricken ...

Hi Robert !

Es gibt übrigens viele Leute die das ärgert. Deshalb gibt's coole
Applikationen die Treiber zur Vermittlung von SQL und reinen Textdateien
zur Verfügung stellen.
Ein solches Beispiel wäre z.N. Perl-DBI, anhand dessen man auch mittels
SQL auf CSV-Dateien zugreifen kann.
Das funktioniert wie ein Treiber, also ein Vermittler zwischen der Sprache
und dem Objekt.

Liebe Grüße,
Lucas


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

[Martin Trautmann]

Robert Böck wrote:

> Das Problem ist aber, dass die OpenGeoDB früher als SQL-Dump verteilt
> wurde, und dass es sicher viele Anwendungen gibt, die mit der
> SQL-Version umgehen können, nicht aber mit den Textdateien.

Ich verwendete von Anfang an die Textversion - als Import in eine
andere, relationale Datenbank.

Tatsächlich steckt in opengeodb derzeit nicht übermässig viel, was
Relationen erforderte. Die Hierarchies waren vielleicht eine davon. Mit
"Teil von" haben wir jetzt eine echte Verknüpfung der Daten miteinander.
  Ansonsten passen die Basisdaten ja offensichtlich sehr einfach in eine
einzige Tabellenstruktur hinein.


> Und das Problem ist, dass in der aktuellen SQL-Distribution Tabellen
> fehlen, ohne die früher gebaute SQL-Statements nicht funktionieren.

Dann müssen diese Tabellen eben wieder erzeugt werden - IMHO am
einfachsten aus den Daten selbst heraus.

> Und ganz offensichtlich gibt es auch viele Leute, die die OpenGeoDB
> gerne in Form einer SQL-Datenbank verwenden möchten.

Deswegen wird auch von mir ein SQL-Dump angeboten.

>> Wenn er SQL verwenden will, sein Problem.
>
> Also bitte! Eine relationale Datenbank ist das Mittel der Wahl, um
> solche Datenbestände zu verwalten. Und damit wären wir bei SQL ...

Wofür verwendest du Relationen tastsächlich? In meinen Anwendungen
ergeben die sich typischerweise erst mit den Daten selbst, in anderen
Tabellen. Innerhalb der opengeodb verwende ich sie kaum.


>> Vorauszusetzen, dass jeder
>> andere weiss, was SEINE Befehle auf SEINER Version der Daten in SEINER
>> SQL-Umgebung ergeben, erscheint mir etwas zu abgehoben.
>
> Was heißt SEINE Version? Wenn man, wovon in den meisten Fällen
> auszugehen ist, die Version benutzt, die zum Download angeboten wird,
> dann ist es eine klar definierte Version, und nicht SEINE Version ...

Es gibt die 0.2.5 die derzeit offiziell auf sourceforge liegt - und es
gibt derzeit einen 0.2.6 dump, der bisher erst auf fa-technik liegt und
der elementare Fehler behebt: level in Österreich und die Vertauschung
von lat/lon in den versionierten Daten.

Mit welcher Datenbank er arbeitet, weiss ich nicht, interessiert mich
auch nicht - möglicherweise ergeben sich je nach Datenbank
unterschiedliche Syntax oder Ausgabeformate. Solange er mir das Ergebnis
seiner Anfrage nicht mitteilt, weiss ich nicht, welche Probleme er mit
den Ergebnissen tatsächlich hat.


Sprich: ICH verwende kein SQL und ICH kann mit seinen SELECTs nichts
anfangen.

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

[Martin Trautmann]

Lucas Mengel wrote:
> Nebenbei: Was habt ihr eigentlich gegen SQL?

Überhaupt nichts - aber ich habe einen Web-Anbieter, der mit kein SQL
anbietet und ich habe Anwendungen, für die ich kein SQL brauche.

> SQL ist die Standard-Abfrage-Sprache für Datenbanken. Das hat eigentlich
> nichts mit Struktur oder so zu tun.

Nur weil "Standard" in der Abkürzung drinsteckt heisst das nicht, dass
man es für alles brauchen würde.

Meine eigene Hauptanwendung ist der Code-Generator
fa-technik.adfc.de/code/ein, mit dem man sich aus zwei Millionen
Strassen nach Möglichkeit jede Wohnadresse in Deutschland in den
persönlichen EIN-Code zur Wertsachencodierung umwandeln lassen kann.

Die Menge der Strassen ist noch recht gering - für so kleine Mengen
taugen Textdateien recht gut. Schwieriger ist dort, wie man die Daten
aufbereiten und zusammensetzen kann. Der Anwender soll es möglichst
einfach haben, bei der Suche nach Schloßstraße, Schlossstr.,
Schloss-Straße, schlosstr usw. die richtige Antwort zu bekommen.

> In der Praxis ist die Anwendung fast immer identisch:
> User geben über ein Web-Interface ihre Postleitzahl an, woraufhin in
> einem für sie reservierten Datensatz die Koordinaten und
> weitere Informationen aus der openGeoDB gespeichert werden.
>
> Nun das entscheidende: Damit später eine wirklich effiziente
> Umkreissuche entstehen kann müssen die Koordinaten in der
> User-Datenbank der jeweiligen Community/Anwendung gespeichert werden.
> Ich glaube kaum, dass irgendeine dieser Plattformen bei jeder
> Suchanfrage dieses beknackte Ebenen-Modull durchläuft.

Dieses Ebenenmodul sollte auch nur ein einziges Mal benötigt werden. Am
einfachsten würden die entsprechenden Befehle direkt in den SQL-Dump
eingebaut. Beim Einlesen der SQL-Daten würden die entsprechenden
Tabellen dann automatisch angelegt.

Wenn SQL so leistungsfähig und standardisiert ist, wie du und ich
glauben, dann sollte das eine einfache Geschichte sein. In meiner
eigenen Datenbank hätte ich in wenigen Minuten ein rekursives Script
zusammengeschrieben, das die Hierarchien erzeugt haben könnte. Meine
Anwendung arbeitet aber nur auf Teilbeständen (ich habe die Länder nach
Tabellen getrennt, weil ich selbst nur Deutschland brauche), ist hier
also wenig geeignet.

Ich bin mir sicher, dass ich auch auf Basis der Textdateien mit perl
recht einfach ein Script schreiben könnte, das die Hierarchies erzeugt -
aber genau das ist eine Funktion, die nach meinem Glauben in eine
relationale Datenbank selbst hineingehört.

Ansonsten zum Standard von SQL: Meine Datenbank ist angeblich in der
Lage, SQL-Anfragen zu beantworten. Mir ist das ziemlich egal - meine
Datenbank ist zu dämlich, .sql als Import-Format zu verwenden. Auch
OpenOffice scheint mit einer Datenbank daherzukommen. Das scheint aber
auch nur SQL-Anfragen beantworten zu können. Wie man die .sql-Daten
hineinbekommen würde, keine Ahnung.

Früher pflegte Thomas auch etliche verschiedene .sql-Varianten für
Postgres, MySQL usw. - bei einem echten Standard sollte das nicht nötig
sein.

Mein Standard sind daher die .txt-Dateien - die lassen sich mit jedem
Texteditor verarbeiten, in fast jede Tabellenkalkulation importieren und
taugen als Austauschformat für fast jede einfacher gestrickte Datenbank.
Es gibt nur wenige Anwender, schätze ich, die tatsächlich von dem
profitieren, was opengeodb so unübersichtlich zu machen scheint:
Versionierung, Sprachvarianten usw.

> Ganz im Gegenteil: Die Betreiber solcher Seiten zerlegen die openGeoDB
> in ihre Einzelteile und zwar solang, bis sie exakt ihrem
> Anspruch entspricht.

Für eine schlichte Umkreissuche, was wohl die Hauptanwendunger der
opengeodb zu sein scheint, kann man natürlich auch SQL hernehmen. Ich
vermute, von der Performance ist meine Umkreissuche effizienter, die ich
für fa-technik.adfc.de/code/anbieter einsetze

> Ich bin nach wie vor der Meinung, man sollte einfach eine einzelne
> SQL-Tabelle ausliefern und den Rest den Leuten überlassen.
> Darunter sind hochbezahlte und qualifizierte Programmmierer, die dem
> jeweiligen Betreiber eine maßgeschneiderte Lösung in sein
> vorhandenes System implentieren.

Da sind wir wohl der gleichen Meinung - sonst würde ich mir nicht die
Mühe machen, .sql-Versionen zu erstellen.

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

[Martin Trautmann]

Robert Böck wrote:

> Hallo Martin,
>
> Martin Trautmann wrote:
>
>>> Mal ein kleines Beispiel. Ich habe mir vor längerer Zeit mal eine
>>> Abfrage gestrickt, die alle Orte in Bayern ausspuckt, inklusive
>>> Geokoordinaten, KFZ-Kennzeichen und Landkreis-Zugehörigkeit:
>
>> Die einfache Lösung: Suche nach allen Orten, bei denen der
>> Gemeindeschlüssel mit 09 beginnt - so mache ich das.
>
> Oha! Dazu muss man aber erst mal wissen, dass man das so machen kann.
> Ich wusste es bisher nicht. Woher soll man das denn wissen? Und wenn man
> es nicht sowieso weiß, dann wird man sich wohl kaum auf die Suche nach
> dieser Information machen (können).

Die Gemeindeschlüssel kamen auch erst erheblich später in die opengeodb
rein - zum Grossteil auf meinen intensiven Wunsch hin.

Du kennst die Systematik:

01: Bundesland
012: Regierungsbezirk
01234: Region
012345: Kreis
012345678: Gemeinde

Regierungsbezirke und Regionen gibt es nicht in jedem Bundesland - aber
selbst Hamburg oder Berlin haben den Dreisprung
Bundesland/Kreis/Gemeinde, auch wenn diese (nahezu) flächengleich sind.

Tatsächlich verwende ich den AGS als Primärschlüssel und baue einen
Grossteil meiner Hierarchien ausschliesslich darauf auf: Wenn ich zu
einem Ort das Kfz-Kennzeichen wissen will, dann nehme ich einfach die
ersten fünf Stellen des Gemeindeschlüssels und hole mir das Kennzeichen
vom Kreis.

Genaugenommen nehme ich hier eher das Kennzeichen der Gemeinde - denn es
gibt Einzelfälle, wo die Gemeinde ihr Kennzeichen behalten hat und der
Kreis ein anderes verwendet. Dort existiert also auf Gemeindeebene
optional ein eigenes Kennzeichen. Andernfalls holt sich die Gemeinde das
Kreiskennzeichen, das darüber wieder den Orten in der Gemeinde zur
Verfügung steht.

Für Österreich und Deutschland sind diese Gemeindeschlüssel extrem
hilfreich.

Die Schweiz verwendet hier ein anderes System, wo einfach auf jeder
Ebene einzeln durchgezählt wird. Hier habe ich die Gemeindeschlüssel
"verhunzt", weil mir "1234" noch nicht verrät, ob das der Schlüssel von
Gemeinde oder Bezirk ist. Strenggenommen muss hier der erste Buchstabe
(K, B oder G) weggeworfen werden. Bisher scheint das keinen gestört zu
haben.

Für andere Länder habe ich mit solcher Systematik noch nicht
beschäftigt. Es gibt sie teilweise weltweit, über NUTS. Es gibt sie
sicher in Frankreich, über die Departments. Für die derzeit verfügbaren
Länder (NL, B usw.) ist mir aber nichts derartiges bekannt.

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

[Martin Trautmann]

Lucas Mengel wrote:
>  >>Warum weisst du das nicht? Kannst du nicht herausfinden, wofür die  
> loc_id 105 steht? Es ist Deutschland -
> dein Aufhänger für alle deutschen
>
> Hi Martin! Vorab: Ich bin für JEDE, absolut JEDE, Hilfe von dir sehr
> Dankbar.
>
> Mein Problem ist teilweise auch, dass ich von dir Zahlen erfahre, die
> für mich nicht nachvollziehbar sind, so wie 105.

105 ist eine loc_id - und wenn du mit
fa-technik.adfc.de/code/opengeodb.pl einmal herumspielst, dann kommst du
über "Teil von" bzw. die Listenansicht mit "<" schnell bis ganz nach
oben, wo du bei Deutschland landest und die Nummer 105 siehst.

Diese Listenansicht wollte ich schon lange mal verbessern, dass man
nicht zwischen Listen und Einzelseiten herumwechselt, sondern in der
Listenansicht bleibt. Irgendwann mache ich das wohl auch mal...

> Ich mache mir die ganze Zeit meine Gedanken darüber, wie du zwischen
> zig-tausend Zahlen gerade auf 105 gekommen bist bzw. welchen
> Weg du gegangen bist, um diese Zahl ausfindig zu machen.

105 ist nur ein Primärschlüssel. Eigentlich interessieren dich immer nur
die Daten, die hinter dieser Zahl stecken - nämlich "Bundesrepublik
Deutschland".

> Was genau 105 bedeutet weiss ich schon, seitdem du es im Forum
> geschrieben hast.
> Aber wie hast du das herausbekommen?

Indem ich weiss, dass es einen Primärschlüssel gibt - ohne den wärst du
ziemlich aufgeschmissen. Das geht so weit, dass ich auch in der reinen
Text-Version, ganz ohne SQL, diesen Primärschlüssel brauche und verwende.

>  >>Suche nach allem, was in 400100000 ein 105 enthält und in 400200000
> eine 3. Damit solltest du anfangen, deine Hierarchies zu erstellen.
>
> Warum nicht gleich:
> "Um alle deutschen Städte/Infos zu ermitteln, brauchst du erstmal alle
> deutschen Bundesländer."

Weil das nicht stimmt. Du kannst auch sagen: Dieser Maulwurfshügel
gehört zu Deutschland, ohne zu wissen, zu welcher Gemeinde, zu welchem
Kreis, zu welchem Bundesland er gehört. Willst du aber die Hierarchies
erzeugen, so solltest du dich von Ebene zu Ebene nach unten durcharbeiten.

> Ok, die habe ich jetzt.
> Ich habe mir selbstverständlich auch die Datensätze angeschaut, die sich
> hinter den loc_id's der Bundesländer verbergen.
>
> 1. Die loc_id 117 steht z.B. für Nordrhein-Westfalen.
>
> 2. loc_id 14634 ist eine Stadt in Nordrhein-Westfalen, nämlich Bochum.
>
> 3. ich habe festgestellt, dass 117 und 14634 eine Gemeinsamkeit haben:
> 5006000000 (in 14634 die ersten beiden Stellen).

Dein Beispiel 2. ist aber kein Bundesland.

> Soweit bin ich nun.
> Was folgt weiter?

Wenn du die Hierarchies der Bundesländer hast, dann gehst du zur Ebene 4
weiter, übernimmst die Hierarchie der zugehörigen Ebene 3, ergänzt sie -
und machst dann mit Ebene 5 weiter....
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Martin Trautmann wrote:
>> Soweit bin ich nun.
>> Was folgt weiter?
>
> Wenn du die Hierarchies der Bundesländer hast, dann gehst du zur Ebene 4
> weiter, übernimmst die Hierarchie der zugehörigen Ebene 3, ergänzt sie -
> und machst dann mit Ebene 5 weiter....


Lass dir das aber besser von einem SQL-Anwender erklären - ich hatte das
auf der Sourceforgeliste für dich schonmal gemacht. Anscheinend bin ich
nicht in der Lage, es dir zu vermitteln.

http://sourceforge.net/forum/message.php?msg_id=4657816

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

[Lucas Mengel]

 >Wenn du die Hierarchies der Bundesländer hast, dann gehst du zur Ebene
4 weiter, übernimmst die Hierarchie
 >der zugehörigen Ebene 3, ergänzt sie - und machst dann mit Ebene 5
weiter...

Ich verstehe das Beispiel auf
http://sourceforge.net/forum/message.php?msg_id=4657816 nicht.
Dort steht Flensburg und das ist kein Bundesland.
Ich weiss aber, dass Flensburg zu Schleswig-Holstein gehört.
Und Schleswig-Holstein liegt in Deutschland.

Ein solches Muster kann ich erkennen.

Nun folgt eine sehr konkrete Frage, wie du sie am liebsten magst:
Warum steht dort Flensburg?

Noch konkreter:
Mein Problem: Ich kann diese Ebenen nicht mit meinem Ziel in Verbindung
bringen und das lautet:
"Ich möchte alle Postleitzahlen von Deutschland haben"


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

[Robert Böck]

Hallo Martin,

Martin Trautmann wrote:

>>> Wenn er SQL verwenden will, sein Problem.
>>
>> Also bitte! Eine relationale Datenbank ist das Mittel der Wahl, um
>> solche Datenbestände zu verwalten. Und damit wären wir bei SQL ...

> Wofür verwendest du Relationen tastsächlich? In meinen Anwendungen
> ergeben die sich typischerweise erst mit den Daten selbst, in anderen
> Tabellen. Innerhalb der opengeodb verwende ich sie kaum.

Nun ja, aus den Relationen ergibt sich z. B., dass Bayern zu Deutschland
gehört, Schwaben zu Bayern, Ostallgäu zu Schwaben und Schwangau zum
Ostallgäu.

cu, Robo :)

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

[Robert Böck]

Hallo Martin,

Martin Trautmann wrote:

[Alle Orte in Bayern]

>>> Die einfache Lösung: Suche nach allen Orten, bei denen der
>>> Gemeindeschlüssel mit 09 beginnt - so mache ich das.
>>
>> Oha! Dazu muss man aber erst mal wissen, dass man das so machen kann.
>> Ich wusste es bisher nicht. Woher soll man das denn wissen? Und wenn man
>> es nicht sowieso weiß, dann wird man sich wohl kaum auf die Suche nach
>> dieser Information machen (können).
>
> Die Gemeindeschlüssel kamen auch erst erheblich später in die opengeodb
> rein - zum Grossteil auf meinen intensiven Wunsch hin.
>
> Du kennst die Systematik:
>
> 01: Bundesland
> 012: Regierungsbezirk
> 01234: Region
> 012345: Kreis
> 012345678: Gemeinde

Nein, kenne ich nicht. Bzw. kannte ich nicht - bis jetzt.

[...]
> Für Österreich und Deutschland sind diese Gemeindeschlüssel extrem
> hilfreich.
[...]
> Die Schweiz verwendet hier ein anderes System, wo einfach auf jeder
> Ebene einzeln durchgezählt wird. Hier habe ich die Gemeindeschlüssel
> "verhunzt", weil mir "1234" noch nicht verrät, ob das der Schlüssel von
> Gemeinde oder Bezirk ist. Strenggenommen muss hier der erste Buchstabe
> (K, B oder G) weggeworfen werden. Bisher scheint das keinen gestört zu
> haben.

Wenn das System der Gemeindeschlüssel nicht in jedem gleich ist, kann
man Abfragen darüber nicht universell verwenden. Die Relationen aus der
Datenbank aber schon.

cu, Robo :)

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

[Martin Trautmann]

Lucas Mengel wrote:
>  >Wenn du die Hierarchies der Bundesländer hast, dann gehst du zur Ebene
> 4 weiter, übernimmst die Hierarchie
>  >der zugehörigen Ebene 3, ergänzt sie - und machst dann mit Ebene 5
> weiter...
>
> Ich verstehe das Beispiel auf
> http://sourceforge.net/forum/message.php?msg_id=4657816 nicht.
> Dort steht Flensburg und das ist kein Bundesland.

Dort wird auch nicht behauptet, Flensburg wäre ein Bundesland.

Hierarchie: Deutschland > Schleswig-Holstein > Flensburg
loc_id: 105 > 119 > 466
Ebenen: 2 > 3 > 5

Flensburg ist also die loc_id 466, liegt auf Ebene 5 und ist Teil von 119.

Deutschland auf Ebene 2 hat also die Hierarchie
   Europa, Deutschland
Schleswig-Holsten auf Ebene 3 ist Teil von Deutschland und hat die
Hierarchie
   Europa, Deutschland, Schleswig-Holstein
Flensburg ist Teil von Schleswig-Holstein und hat daher die Hierarchie
   Europa, Deutschland, Schleswig-Holstein, Flensburg


> Nun folgt eine sehr konkrete Frage, wie du sie am liebsten magst:
> Warum steht dort Flensburg?

  Weil Flensburg einfach das erste Beispiel ist - ein willkürliches
Beispiel über mehrere Ebenen hinweg

> Noch konkreter:
> Mein Problem: Ich kann diese Ebenen nicht mit meinem Ziel in Verbindung
> bringen und das lautet:
> "Ich möchte alle Postleitzahlen von Deutschland haben"

Dein Ziel läuft raus auf "von Deutschland". In der Flensburger Zeile der
Hierarchien steht drin:
    Europa, Deutschland, Schleswig-Holstein, Flensburg
Nachdem du die Hierarchien aufgebaut hast, kannst du also deine Suche
direkt eingrenzen auf all das, was zu Deutschland gehört. Bis dahin
weisst du nur, dass Flensburg zu Schleswig-Holstein gehört, aber noch
nicht, dass damit Flensburg auch zu Deutschland gehört.

In SQL-Syntax lautet der Hierarchieeintrag von Flensburg, NACHDEM du ihn
erstellt hast:
geodb_hierarchies (466,5,104,105,119,NULL,466,NULL,NULL,NULL,NULL,
NULL,NULL, '3000-01-01',300500000);
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Georg Verweyen]

>Martin Trautmann antworte:
>Lucas Mengel wrote:
>>  >Wenn du die Hierarchies der Bundesländer hast, dann gehst du zur
>> Ebene
>> 4 weiter, übernimmst die Hierarchie
>>  >der zugehörigen Ebene 3, ergänzt sie - und machst dann mit Ebene 5
>> weiter...
>>
>> Ich verstehe das Beispiel auf
>> http://sourceforge.net/forum/message.php?msg_id=4657816 nicht.
>> Dort steht Flensburg und das ist kein Bundesland.
>
>Dort wird auch nicht behauptet, Flensburg wäre ein Bundesland.
>
>Hierarchie: Deutschland > Schleswig-Holstein > Flensburg
>loc_id: 105 > 119 > 466
>Ebenen: 2 > 3 > 5
>
>Flensburg ist also die loc_id 466, liegt auf Ebene 5 und ist Teil von 119.
>
>Deutschland auf Ebene 2 hat also die Hierarchie
>   Europa, Deutschland
>Schleswig-Holsten auf Ebene 3 ist Teil von Deutschland und hat die

Hierarchie
>   Europa, Deutschland, Schleswig-Holstein Flensburg ist Teil von
Schleswig-Holstein und hat daher die Hierarchie
>   Europa, Deutschland, Schleswig-Holstein, Flensburg
Hallo Martin,

Und das genau ist derzeit einer der größten Fehler: Der Ebene wird (sogar
länderspezifisch) einer Bedeutung zu geordnet, dabei gibt es doch die
Ebenen-Bedeutung in der geodb_locations. Wenn man generell ein Hierarchie
aufbauen will, muss man nicht vorher die Hierarchiestufen festlegen, sondern
könnte auch erstmal sagen: In der Welt liegt der Ortsteil Thomasberg.
Welt
+- Thomasberg
Wenn man dann durch andere Quellen feststellt, das Thomasberg ein Ortsteil
von Königswinter und Königswinter in Deutschland liegt, kann man das
einfügen
Welt
+- Deutschland
 +- Königswinter
  +- Thomasberg

Das mag sich jetzt komisch anhören, aber stell Dir vor Du hättest
Koordinaten von New York (Big Apple) und würdest Sie ohne Kenntnisse der
politischen Struktur in die Hierarchie einsortieren wollen.

Welt
+- Amerika
|+- United State of America
| +- New York
|
+- Europa
 +- Deutschland
  +- Nordrhein-Westfalen
   +- Köln
    +- Rhein-Sieg-Kreis
     +- Königswinter
      +- Thomasberg

Mit freundlichen Grüßen      Georg V.

P.S.: Ich muss meine Formulierung noch leicht von Datenbank nach
Datenhaltung modifizieren, da wir eigentlich Daten sammeln und die Form
(Datenbank MySQL und Textdateien) nur ein Mittel zum Zweck ist.
* Die OpenGeoDB ist eine freie Datenhaltung über Hierarchien (politische und
postalische) Strukturen mit einer zeitlichen Dimension.
Welche Hilfsmittel wir anbieten, damit Lucas seine PLZ-Zahlen hat, ist davon
unabhängig und nur ein kleines Randgebiet. Es kann durchaus auch ein
kostenpflichtiges Angebot sein.

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