einspielen von daten nach :MariaDB

[Rainer_]

Ich habe im Internet eine ältere Version von opengeodb gefunden. Diese versuche ich nun zu installieren, doch die MARIA macht mir da einen Strich durch die Rechnung.

INSERT INTO geodb_textdata VALUES(105,400100000,'104',null,null,null,null,null,'3000-01-01',300500000)

Als Fehlermeldung bekomme ich:

#4025 - CONSTRAINT CONSTRAINT_1 fehlgeschlagen: geodata.geodb_textdata

Das verstehe ich nicht ganz und aus den FehlermeldungenErklärungen die ich im Netz finde auch nicht.

Kann mir jemand einen Hinweis geben wie ich die Daten in die Datenbank bekomme?

Rainer

[Tabellenkalk]

Hallo,

Constraints sind Bedingungen, die die Daten erfüllen müssen. Prüf mal die erwarteten Datentypen.

Gruß
Kalk

[Rolf B]

Hallo Rainer_,

Ich habe im Internet eine ältere Version von opengeodb gefunden.

Warum eine ältere? Vielleicht sogar irgendwie verbrasselte? Nimm doch eine aktuelle, vom Original:

http://opengeodb.giswiki.org/wiki/OpenGeoDB_Downloads

Mit der - und MySQL 5.6 - kann ich importieren. Man muss nur in den create table Befehlen TYPE durch ENGINE ersetzen. Muh - das ist doch nun schon ewig so, wieso ändern die ihre Scripte nicht???

Allerdings sieht das INSERT Statement in der DE.SQL, Zeile 3, bei Dir genauso aus wie bei mir.

Fehler bekomme ich nur, wenn ich das ende-SQL laufen lasse und danach nochmal zu importieren versuche. Muss ja auch, dann sind die Indexe da und verhindern duplicate keys.

Constraint-Fehler bekomme ich keine, und der check, der für die textdata Tabelle definiert ist, gilt hauptsächlich für 500er Texttypen. Das einzige, was für alle Sätze gemacht wird, ist eine Prüfung von valid_since und data_type_since, die müssen beide null oder beide nicht null sein.

Eine Maria lach ich mir dafür jetzt nicht extra an...

Rolf

[Linuchs]

Hallo Rolf,

Warum eine ältere? Vielleicht sogar irgendwie verbrasselte? Nimm doch eine aktuelle, vom Original:

Für die Umkreisberechnung in meinem Veranstaltungskalender habe ich um 2008 die damalige Geo-Datenbank Deutschland geladen. In meiner Erinnerung waren das ca. 8000 Datensätze, also 8000 Postleitzahlen.

Inzwischen sind viele Orte manuell erfasst worden. Einerseits, weil Vereine ihr „Dorf“ und nicht die Samtgemeinde sehen wollen, andererseits, weil viele Neugliederungen und Neuschöpfungen von Ortsnamen - besonders in der Ex-DDR - alte Namen abgelöst haben.

Und nicht zuletzt die Orte in A, CH und NL, die in 13 Jahren manuell dazugekommen sind. Und ein paar hundert sonstwo, wo irgend jemand mal ein Event eingetragen hat.

Jede Veranstaltung ist mit einer ort_id verknüpft. Jetzt zu Corona-Zeiten ist das Minimum von Veranstaltungen erreicht. Vermutlich ein günstiger Zeitraum, um aufzuräumen.

Gerne hätte ich den aktuellen Geo-Stand der Orte in A, CH, D und NL.

Wie könnte ich die mit den vorhandenen Daten abgleichen?

Ich denke nicht, dass sich A-1190 Wien wegen der Plattentektonik wesentlich verschoben hat. Aber wenn ein Dorf hinzugeschlagen wird, verschiebt sich der Mittelpunkt. Mittelpunkte im Wald, auf einem See hatten wir alles schon. Aber dann hat sich ein Chor beklagt, weil deren Marker (Mittelpunkt des Dortmunder Stadtteils) auf einen Friedhof zeigte ;-)

Könnte ich die Werte ALT - NEU gegeneinander laufen lassen und bei Übereinstimmung von land_kz, plz und ort_name die (neuen) Geo-Koordinaten unter der vorhandenen ort_id übernehmen?

Viel wichtiger wäre aber, untergegangene Orte zu löschen und neue Orte aufzunehmen. Aber keine Idee, wie ich die erkennen kann. Was NICHT in den neuen Daten ist, könnte erloschen sein, aber auch ein berechtigter Eintrag bei mir.

Gruß, Linuchs

[Rolf B]

Hallo Linuchs,

sorry, das klingt aufwändig. Hast Du Einträge der opengeodb modifiziert? Oder hast Du für die "falschen" Positionen Einträge am Chor oder am Event gemacht, die dann Vorrang vor den Einträgen der opengeodb haben?

Das würde es einfach machen; du müsstest einfach nur die alte opengeodb durch die neue ersetzen. Das setzt allerdings voraus, dass die Locations ihre loc_id behalten haben. Es wäre fatal, wenn die jetztige loc_id 417 (Stadt Köln) irgendwann mal dem Ort gehört hätte, der heute die loc_id 25144 trägt. Mache würden zwar sagen, dass das stimmt, aber so richtig glücklich wäre das wohl nicht. Das müsste man recherchieren, bei opengeo nachfragen oder ein Vergleichsprogramm laufen lassen.

D.h. du musst schauen:

• haben loc_id ihren Namen geändert (passenden textdata Eintrag finden)
• welche loc_id sind entfallen (das sind untergegangene Orte) und verwendest Du die bei Dir?

Klingt nach einem schnuckeligen PHP Programm, bei dem man Knoten in die Finger bekommt. Leg schonmal Maiskörner bereit und stell sie auf den Server, wenn das Programm läuft. Am Tempo des "Pop Pop Pop" kannst Du feststellen, wie viele Orte gerade gefunden werden 😂

Rolf