In-Reply-To: <
4785FE8F.4090606@...>
On 2008-01-10 12:16, Sascha Mantscheff wrote:
> Martin Trautmann schrieb:
>> On 2008-01-10 09:52, Sascha Mantscheff wrote:
>>> Dazu wären die Skripte bzw. das Verfahren hilfreich, nach dem die von
>>> Dir genannte Hiearchietabelle erzeugt wurde.
>>
>> Bist du sicher, dass die dir helfen würden?
>>
> Deine Skepsis ist berechtigt. Wenn ich es richtig verstehe, werden hier
> *.tab-Dateien nach SQL gewandelt.
Genau
> Dann muss ich fragen, woher denn die
> *.tab-Dateien kommen? Werden die aus dem Datenbestand abgeleitet, oder
> sind es Grunddaten, die gepflegt werden?
Die .tab-Daten entstammen der 0.2.4d-SQL-Version, die seither massiv als
Grunddaten erweitert wurden
Auf der Plattform, wo das laeuft, steht keine SQL-Umgebung zur Verfuegung.
Es laeuft dort alles ueber Text-Dateien und Perl-Scripts.
Die Basisdaten liegen daher in den .tab-Dateien vor, aus denen
.sql-Dateien konvertiert werden.
> Das sind schon die richtigen Befehle, und damit wird es auch stimmig.
> Aber im Dump D.sql sind offenbar opengeodb-(begin|end).sql nicht enthalten.
Deswegen wollte ich von dir wissen, von welcher Version du sprichst.
dump/D.sql ist nur ein vorlaeufiger Zwischenstand, um die Einbindung von
Ortsteilen und Strassen vorzufuehren. Ich hoffe, jemand koenne oder wolle
sich die Daten mal ansehen, ob diese ueberhaupt brauchbar sind.
>> Du musst mir weiterhelfen, was hier fuer dich der Unterschied zwischen
>> 2005 und heute ist. Auf welche SQL-Daten beziehst du dich dabei?
>>
>
> Wenn ich das so genau wüsste. Quelldaten liegen keine vor, nur
> MySQL-Tabellen, die wohl aus früheren einem GeoDB-Import und
> Nachbearbeitung entstanden sind.
Ok, so alte Daten habe ich vielleicht noch irgendwo auf Backups. Zu der
Zeit damals interessierten mich nur die .txt-Versionen.
> Die locations-Tabelle beispielsweise
> sieht aus wie unten gezeigt.
> +----------+--------------+------+-----+---------+----------------+
> | Field | Type | Null | Key | Default | Extra |
> +----------+--------------+------+-----+---------+----------------+
> | id | int(12) | NO | PRI | NULL | auto_increment |
> | typ | int(12) | YES | | NULL | |
> | name | varchar(250) | YES | | NULL | |
> | name_int | varchar(250) | YES | | NULL | |
> | gs | varchar(8) | YES | | NULL | |
> | adm0 | char(2) | YES | MUL | NULL | |
> | adm1 | char(2) | YES | MUL | NULL | |
> | adm2 | varchar(250) | YES | MUL | NULL | |
> | adm3 | varchar(250) | YES | MUL | NULL | |
> | adm4 | varchar(250) | YES | | NULL | |
> | ort | varchar(250) | YES | MUL | NULL | |
> | ortsteil | varchar(250) | YES | | NULL | |
> | gemteil | varchar(250) | YES | | NULL | |
> | breite | float | YES | | NULL | |
> | laenge | float | YES | | NULL | |
> | kfz | char(3) | YES | | NULL | |
> | plz | text | YES | | NULL | |
> +----------+--------------+------+-----+---------+----------------+
Ja, das sieht nach fruehesten Versionen von Thomas aus. Seither kam viel
overhead dazu, der mir im Normalfall als ueberfluessig erscheint. Der
Inhalt dieser Tabelle entspricht recht genau der
http://downloads.sourceforge.net/opengeodb/opengeodb-0.2.4d-UTF8-text-orte.zip# Bedeutung der einzelnen Felder:
#
# Feld 1: eindeutiger Schlüssel (Primary Key)
# Felder 2 bis 8: hierarchische Verwaltungsgliederung, hier:
# Feld 2: Staat (DE == Deutschland)
# Feld 3: Bundesland, s.o.
# Feld 4: Regierungsbezirk
# Feld 5: Landkreis
# Feld 6: Verwaltungszusammenschluss
# Feld 7: Ort
# Feld 8: Ortsteil/Stadtteil
# Feld 9: Gemeindeteil unspezifizierter Art
# Feld 10: Anderer Ort
# Felder 11 und 12: Koordinaten:
# Feld 11: Längengrad
# Feld 12: Breitengrad
# Felder 13 und 14: Andere Merkmale, hier:
# Feld 13: Autokennzeichen
# Feld 14: Postleitzahl(en)
Schoenen Gruss
Martin
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung:
http://www.gmx.net/de/go/freemail--
Mailingliste OpenGeoDB
Listenadresse:
opengeodb@...
Informationen:
http://opengeodb.deMit freundlicher Unterstütztung von php::bar (
http://phpbar.de)