From traut at gmx.de Tue Oct 2 09:12:04 2007 From: traut at gmx.de (Martin Trautmann) Date: Tue, 02 Oct 2007 09:12:04 +0200 Subject: [opengeodb] opengeodb release 0.2.5.1 Message-ID: <4701EF44.1020806@gmx.de> Hallo, auf http://fa-technik.adfc.de/Codierung/opengeodb/dump/opengeodb-0251_2007-10-02.sql.gz habe ich eine neue beta-release erzeugt, in der die derzeit bekannten Fehler korrigiert wurden: - locid mit zu hohen int-Werten wurde in einen passenden int-Bereich verschoben. "Teil von" wurde auf entsprechende Werte korrigiert. In den Änderungs-Protokollen blieben jedoch die alten Werte - dort dürften sie nebensächlich sein? - intdata-Syntax wurde korrigiert - ' in den Daten wurde richtig an die SQL-Syntax angepasst Ich bitte darum, die sql-Daten auf ihre Verwendbarkeit zu prüfen. Sollten hier neue Fehler bemerkt werden, so müssen diese unbedingt korrigiert werden, bevor eine neue sourceforge-release möglich wäre. Schönen Gruß Martin From traut at gmx.de Tue Oct 2 09:30:19 2007 From: traut at gmx.de (Martin Trautmann) Date: Tue, 02 Oct 2007 09:30:19 +0200 Subject: [opengeodb] opengeodb release 0.2.5.1 In-Reply-To: <4701EF44.1020806@gmx.de> References: <4701EF44.1020806@gmx.de> Message-ID: <4701F38B.2070607@gmx.de> Martin Trautmann wrote: > Ich bitte darum, die sql-Daten auf ihre Verwendbarkeit zu prüfen. > Sollten hier neue Fehler bemerkt werden, so müssen diese unbedingt > korrigiert werden, bevor eine neue sourceforge-release möglich wäre. Fehler in den Daten selbst sind übrigens bekannt, wie z.B. ASCII: Die Feldinhalte enthalten derzeit oft noch Nicht-ASCII-Zeichen. Diese Daten sollte ich selbst einmal korrigieren. Vermutlich wäre es aber ein leichtes, mit ein paar SQL-Befehlen diese Werte in der Datenbank selbst zu korrigieren? Ausserdem fehlen bei Neueinträgen oft Daten, die aus der Ebene darüber übernommen werden könnten. Soll ich bei der Eingabe von Neueinträgen diese als Default-Werte einsetzen? Schönen Gruß Martin From gemander at gmx.net Tue Oct 2 10:14:39 2007 From: gemander at gmx.net (Gemander, Ronny) Date: Tue, 02 Oct 2007 10:14:39 +0200 Subject: [opengeodb] opengeodb release 0.2.5.1 In-Reply-To: <4701F38B.2070607@gmx.de> References: <4701EF44.1020806@gmx.de> <4701F38B.2070607@gmx.de> Message-ID: <4701FDEF.7050007@gmx.net> Martin Trautmann schrieb: > Martin Trautmann wrote: > >> Ich bitte darum, die sql-Daten auf ihre Verwendbarkeit zu prüfen. >> Sollten hier neue Fehler bemerkt werden, so müssen diese unbedingt >> korrigiert werden, bevor eine neue sourceforge-release möglich wäre. > > Fehler in den Daten selbst sind übrigens bekannt, wie z.B. > > ASCII: Die Feldinhalte enthalten derzeit oft noch Nicht-ASCII-Zeichen. > Diese Daten sollte ich selbst einmal korrigieren. Vermutlich wäre es > aber ein leichtes, mit ein paar SQL-Befehlen diese Werte in der > Datenbank selbst zu korrigieren? > > Ausserdem fehlen bei Neueinträgen oft Daten, die aus der Ebene darüber > übernommen werden könnten. > > Soll ich bei der Eingabe von Neueinträgen diese als Default-Werte einsetzen? Ja, das wäre super! Je einfacher man mit der DB arbeiten kann, um so besser ist es. Ansonsten von hier auch mal ein Dankeschön für Deine Arbeit, die mir schon viel geholfen hat. > > Schönen Gruß > Martin Gruss, Ronny From georg at familieverweyen.de Tue Oct 2 12:25:26 2007 From: georg at familieverweyen.de (Georg Verweyen) Date: Tue, 02 Oct 2007 12:25:26 +0200 Subject: [opengeodb] opengeodb release 0.2.5.1 Message-ID: <47021C96.6040907@familieverweyen.de> Hallo Martin, bei mir werden die Daten für int_data nicht eingespielt (Tabelle hat 7 Atrribute, SQL-Statement 8 Attribute). MfG Georg V. From traut at gmx.de Tue Oct 2 13:00:48 2007 From: traut at gmx.de (Martin Trautmann) Date: Tue, 02 Oct 2007 13:00:48 +0200 Subject: [opengeodb] opengeodb release 0.2.5. Message-ID: <20071002110048.7160@gmx.net> Hallo Georg, danke fuer den raschen Hinweis. Intdata sollte hoffentlich korrigiert sein. Ausserdem wurde die Flaechenangabe auf floatdata korrigiert. Aktualisierte Daten stehen unter dem bisherigen Link zur Verfuegung http://fa-technik.adfc.de/Codierung/opengeodb/dump/opengeodb-0251_2007-10-02.sql.gz (Weiterverlinkung von *0251* auf *02511*, die alten Daten liegen unter *02510*) Schoenen Gruss Martin -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From Porsch.Markus at schlaraffia.de Tue Oct 2 13:20:13 2007 From: Porsch.Markus at schlaraffia.de (Markus Porsch) Date: Tue, 2 Oct 2007 13:20:13 +0200 Subject: [opengeodb] Markus Porsch/WAT/DE/RECTICEL. Message-ID: Ich werde ab 01.10.2007 nicht im Büro sein. Ich kehre zurück am 04.10.2007. Ich werde auf Ihre Nachricht erst nach meinem Urlaub reagieren können. ---------------------------------------------------------------------------------------------------------------------------------------------- RECTICEL SCHLAFKOMFORT GmbH, Schlaraffiastraße 1-10, 44867 Bochum Geschäftsführer: Caroline Deschaumes, Werner Trenz - Registergericht Bochum HR B 6666 ---------------------------------------------------------------------------------------------------------------------------------------------- From georg at familieverweyen.de Tue Oct 2 17:20:18 2007 From: georg at familieverweyen.de (Georg V.) Date: Tue, 2 Oct 2007 17:20:18 +0200 Subject: [opengeodb] Version 0.2.5.1.1 Message-ID: Hallo Martin, jetzt sind nur noch zwei Indizes falsch, weil die entsprechende Attribute der Tabellen fehlen. create index float_stype_idx on geodb_floatdata(float_subtype); create index int_stype_idx on geodb_intdata(int_subtype); geodb_changelog 0 geodb_coordinates 40.721 geodb_floatdata 18.220 geodb_hierarchies 0 ? geodb_intdata 34.351 geodb_location 41.816 geodb_textdata 337.919 geodb_type_names 40 Ich werde mal später am Abend meine Abfrageroutine dagegen testen, aber ich habe das dumpfe Gefühl, dass hier die Datensätze in der Tabelle geodb_hierarchies fehlen. MfG Georg V. P.S.: MySQL meckert (zu Recht) über die Indizes von der Tabelle geodb_type_names und auch die anderen Indizes scheinen nach dem Motto mehr hilft mehr auf Verdacht angelegt zu sein. From traut at gmx.de Wed Oct 3 00:32:43 2007 From: traut at gmx.de (Martin Trautmann) Date: Wed, 03 Oct 2007 00:32:43 +0200 Subject: [opengeodb] Version 0.2.5.1.1 In-Reply-To: References: Message-ID: <4702C70B.8060505@gmx.de> Georg V. wrote: > jetzt sind nur noch zwei Indizes falsch, weil die entsprechende Attribute > der Tabellen fehlen. Hallo Georg, was heisst das? Welche Attribute fehlen? > create index float_stype_idx on geodb_floatdata(float_subtype); > create index int_stype_idx on geodb_intdata(int_subtype); Das sind Leichen aus der 0.2.4d-Struktur, die ungeprüft über http://fa-technik.adfc.de/Codierung/opengeodb/opengeodb-end.sql übernommen und hinzugefügt werden. Die beiden entsprechenden Zeilen sollten also rausfliegen? > geodb_changelog 0 ... Derzeit haben wir keinen changelog mehr drin > geodb_coordinates 40.721 > geodb_floatdata 18.220 > geodb_hierarchies 0 ? ... das sollten mehr sein > geodb_intdata 34.351 > geodb_location 41.816 > geodb_textdata 337.919 > geodb_type_names 40 > > Ich werde mal später am Abend meine Abfrageroutine dagegen testen, aber > ich habe das dumpfe Gefühl, dass hier die Datensätze in der Tabelle > geodb_hierarchies fehlen. Ich bin gespannt auf's Ergebnis. > P.S.: MySQL meckert (zu Recht) über die Indizes von der Tabelle > geodb_type_names und auch die anderen Indizes scheinen nach dem Motto mehr > hilft mehr auf Verdacht angelegt zu sein. Ja, vieles davon wurde vorausgreifend angelegt, wird aber noch nicht genutzt. Aus anderer Quelle bekam ich die Rückmeldung, dass die Schreibvarianten in 'he' / 'yi' Probleme machten. Bei dir ging das also anscheinend glatt durch? Schönen Gruß Martin From mj10777 at googlemail.com Wed Oct 3 08:51:38 2007 From: mj10777 at googlemail.com (Mark Johnson) Date: Wed, 3 Oct 2007 08:51:38 +0200 Subject: [opengeodb] Importfehlern bei opengeodb-0251_2007-10-02.sql Message-ID: >> http://fa-technik.adfc.de/Codierung/opengeodb/dump/opengeodb-0251_2007-10-02.sql.gz >> habe ich eine neue beta-release erzeugt, in der die derzeit bekannten >> Fehler korrigiert wurden: >> Ich bitte darum, die sql-Daten auf ihre Verwendbarkeit zu prüfen. >> Sollten hier neue Fehler bemerkt werden, so müssen diese unbedingt >> korrigiert werden, bevor eine neue sourceforge-release möglich wäre. Habe folgende Import-Fehlern bekommen : - nach jede fehler habe ich alle Sätze bis und einschließlich der fehlerhafte Satz gelöscht, daher die unterschiedliche Zeilennummern. FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02.sql ERROR 1064 (42000) at line 248673: You have an error .. near ' 63.11945397049163123394,null,null,null,'3000-01-01',300500000)' at line 1 FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02b.sql ERROR 1064 (42000) at line 217754: You have an error .. near '',500100000','he',0,0,null,null,'3000-01-01',300500000)' at line 1 FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql ERROR 1064 (42000) at line 17: You have an error .. near '',500100000','he',0,0,null,null,'3000-01-01',300500000)' at line 1 FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql ERROR 1064 (42000) at line 14: You have an error .. near '',500100000','yi',0,0,null,null,'3000-01-01',300500000)' at line 1 FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql ERROR 1064 (42000) at line 20: You have an error .. near '',500100000','he',0,0,null,null,'3000-01-01',300500000)' at line 1 FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql ERROR 1072 (42000) at line 6907: Key column 'int_subtype' doesn't exist in table FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007-10-02d.sql ERROR 1072 (42000) at line 19: Key column 'float_subtype' doesn't exist in table -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20071003/feff9f2b/attachment.html From mj10777 at googlemail.com Wed Oct 3 08:52:39 2007 From: mj10777 at googlemail.com (Mark Johnson) Date: Wed, 3 Oct 2007 08:52:39 +0200 Subject: [opengeodb] Liste von Koordinaten von PLZ eine Land/Ort Message-ID: Unter Verwendung eine Beispiel SQL, habe ich versucht eine Liste alle PLZ (mit deren Längen-/Breitengrad) eine Ort bzw. Land auszugeben. Die Postleitzahl kommt raus aber die Koordinaten sind von der Ort/Land. Beim durchsicht der DB, bin ich sicher das diese Werte pro PLZ vorhanden sind, aber wie man die ansprechen kann ist mir noch unklar. Vermutlich durch eine Unterabfrage auf der gefundene PLZ - aber mir ist zur zeit nicht klar wie. Sowas wie folgenes dürfte die richtige Richtung sein : coord.loc_id = geodb_textdata.loc_id = 'WHERE ((geodb_textdata.text_type = 500300000) AND (geodb_textdata.text_var = code.text_value))' aber mir ist nicht klar warum (oder wie) man die loc_id der PLZ nicht holen kann um es in die 'coord.loc_id = code.loc_id' zu verwenden. Irgendwas habe ich nicht richtig verstanden. Hier die Sql die ich ausprobiert habe (1.) für den Land 'Berlin' ; 2.) für den Stadt 'Berlin') SELECT coord.loc_id as "id_Coord", code.text_val as "PLZ", town.text_val as "Ort", land.text_val as "Land", coord.lat as "Latitude", coord.lon as "Longitude" FROM geodb_hierarchies hi, geodb_textdata land, geodb_textdata town, geodb_textdata code, geodb_coordinates coord WHERE hi.id_lvl3=land.loc_id AND land.text_val='BE' AND land.text_type=500100001 /* ISO 3166 */ AND town.loc_id = hi.loc_id AND town.text_type = 500100000 /* NAME */ AND code.loc_id = town.loc_id AND code.text_type = 500300000 /* AREA CODE */ AND coord.loc_id = code.loc_id ORDER BY 2 SELECT coord.loc_id as "id_Coord", code.text_val as "PLZ", town.text_val as "Ort", coord.lat as "Latitude", coord.lon as "Longitude" FROM geodb_hierarchies hi, geodb_textdata town, geodb_textdata code, geodb_coordinates coord WHERE hi.id_lvl6=town.loc_id AND town.text_val='Berlin' AND town.text_type = 500100000 /* NAME */ AND code.loc_id = hi.loc_id AND code.text_type = 500300000 /* AREA CODE */ AND coord.loc_id = code.loc_id ORDER BY 2 -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20071003/fcb5370c/attachment.html From mj10777 at googlemail.com Wed Oct 3 09:15:47 2007 From: mj10777 at googlemail.com (Mark Johnson) Date: Wed, 3 Oct 2007 09:15:47 +0200 Subject: [opengeodb] =?iso-8859-1?q?geodb=5Fhierarchies_S=E4etze=3D0=3A_op?= =?iso-8859-1?q?engeodb-0251=5F2007-10-02=2Esql?= Message-ID: > geodb_hierarchies 0 ? ... das sollten mehr sein Auch bei mir gabe es keine Datensätze für geodb_hierarchies. Erwartunggemäß gab es keine Abfrage Ergebnisse, auch nachdem man die Sätze aus der alte Version eingespielt habe. -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20071003/789a5df1/attachment.html From malte at hsv-mail.de Wed Oct 3 15:56:44 2007 From: malte at hsv-mail.de (Molt) Date: Wed, 3 Oct 2007 06:56:44 -0700 (PDT) Subject: [opengeodb] Importfehlern bei opengeodb-0251_2007-10-02.sql In-Reply-To: References: Message-ID: <13019522.post@talk.nabble.com> Kann ich bestätigen ... aber super, dass du dich drangesetzt hast! Mark Johnson-30 wrote: > > Habe folgende Import-Fehlern bekommen : > - nach jede fehler habe ich alle Sätze bis und einschließlich der > fehlerhafte Satz gelöscht, > daher die unterschiedliche Zeilennummern. > > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02.sql > ERROR 1064 (42000) at line 248673: You have an error .. near ' > 63.11945397049163123394,null,null,null,'3000-01-01',300500000)' at line 1 > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02b.sql > ERROR 1064 (42000) at line 217754: You have an error .. near > '',500100000','he',0,0,null,null,'3000-01-01',300500000)' at line 1 > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql > ERROR 1064 (42000) at line 17: You have an error .. near > '',500100000','he',0,0,null,null,'3000-01-01',300500000)' at line 1 > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql > ERROR 1064 (42000) at line 14: You have an error .. near > '',500100000','yi',0,0,null,null,'3000-01-01',300500000)' at line 1 > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql > ERROR 1064 (42000) at line 20: You have an error .. near > '',500100000','he',0,0,null,null,'3000-01-01',300500000)' at line 1 > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql > ERROR 1072 (42000) at line 6907: Key column 'int_subtype' doesn't exist in > table > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007-10-02d.sql > ERROR 1072 (42000) at line 19: Key column 'float_subtype' doesn't exist in > table -- View this message in context: http://www.nabble.com/Importfehlern-bei-opengeodb-0251_2007-10-02.sql-tf4560126.html#a13019522 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From traut at gmx.de Wed Oct 3 22:36:22 2007 From: traut at gmx.de (Martin Trautmann) Date: Wed, 03 Oct 2007 22:36:22 +0200 Subject: [opengeodb] =?iso-8859-1?q?geodb=5Fhierarchies_S=E4etze=3D0=3A_op?= =?iso-8859-1?q?engeodb-0251=5F2007-10-02=2Esql?= In-Reply-To: References: Message-ID: <4703FD46.1010608@gmx.de> Mark Johnson wrote: >> geodb_hierarchies 0 ? > ... das sollten mehr sein In der alten geodb 0.2.4 sollten die noch stärker vorhanden gewesen sein - sie wurden jetzt ersetzt durch die Ebenenangabe und Teil von. Hierarchien müssten hier also eher neu berechnet werden. Reichen dafür ein paar SQL-Befehle aus? Schönen Gruß Martin From traut at gmx.de Wed Oct 3 23:00:09 2007 From: traut at gmx.de (Martin Trautmann) Date: Wed, 03 Oct 2007 23:00:09 +0200 Subject: [opengeodb] Importfehlern bei opengeodb-0251_2007-10-02.sql In-Reply-To: References: Message-ID: <470402D9.2040200@gmx.de> Mark Johnson wrote: > http://fa-technik.adfc.de/Codierung/opengeodb/dump/opengeodb-0251_2007-10-02.sql.gz >>> habe ich eine neue beta-release erzeugt, in der die derzeit bekannten >>> Fehler korrigiert wurden: >>> Ich bitte darum, die sql-Daten auf ihre Verwendbarkeit zu prüfen. >>> Sollten hier neue Fehler bemerkt werden, so müssen diese unbedingt >>> korrigiert werden, bevor eine neue sourceforge-release möglich wäre. > > Habe folgende Import-Fehlern bekommen : > - nach jede fehler habe ich alle Sätze bis und einschließlich der > fehlerhafte Satz gelöscht, > daher die unterschiedliche Zeilennummern. Hallo Mark, besten Dank - denen werde ich nun nachgehen. > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02.sql > ERROR 1064 (42000) at line 248673: You have an error .. near ' > 63.11945397049163123394,null,null,null,'3000-01-01',300500000)' at line 1 Ein Koordinatenfehler - schon korrigiert. > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02b.sql > ERROR 1064 (42000) at line 217754: You have an error .. near > '',500100000','he',0,0,null,null,'3000-01-01',300500000)' at line 1 > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql > ERROR 1064 (42000) at line 17: You have an error .. near > '',500100000','he',0,0,null,null,'3000-01-01',300500000)' at line 1 > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql > ERROR 1064 (42000) at line 14: You have an error .. near > '',500100000','yi',0,0,null,null,'3000-01-01',300500000)' at line 1 > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql > ERROR 1064 (42000) at line 20: You have an error .. near > '',500100000','he',0,0,null,null,'3000-01-01',300500000)' at line 1 Das sind alles Fehler mit hebraeischen/yiddischen Zeichen: he, yi Kann hier jemand erklären, was daran falsch ist bzw. wie's richtig heissen muss? Version 0.2.4d: INSERT INTO geodb_textdata VALUES(106,'???????',500100000,'he',0,0,null,null,'3000-01-01',300500000); Version 0.2.5.2: INSERT INTO geodb_textdata VALUES(106,???????',500100000','he',0,0,null,null,'3000-01-01',300500000);/* A */ Die alte Syntax war anscheinend ok - aber warum? Ich vermute, das ' ist falsch gesetzt - aber ich kann hier nicht wirklich erkennen, wo er sitzt - die Umkehrung der Schreibrichtung scheint mir hier einen Streich zu spielen. Im VIM sieht die neuere Schreibweise eigentlich richtiger aus, anscheinend ein Trugschluss. > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007- 10-02c.sql > ERROR 1072 (42000) at line 6907: Key column 'int_subtype' doesn't exist in > table > > FreeBSD_62_01# mysql GeoDB < opengeodb-02511_2007-10-02d.sql > ERROR 1072 (42000) at line 19: Key column 'float_subtype' doesn't exist in > table Ah, danke - die subtypes hatte ich aus der Datenstruktur rausgeworfen, Mal sehen, ob wir sie irgendwann brauchen werden. Schönen Gruß Martin From malte at hsv-mail.de Thu Oct 4 00:32:03 2007 From: malte at hsv-mail.de (Molt) Date: Wed, 3 Oct 2007 15:32:03 -0700 (PDT) Subject: [opengeodb] Importfehlern bei opengeodb-0251_2007-10-02.sql In-Reply-To: <470402D9.2040200@gmx.de> References: <470402D9.2040200@gmx.de> Message-ID: <13029278.post@talk.nabble.com> Hmm, mag sein, dass ich das Problem nicht recht deute - aber der Typ müsste doch an 2. Stelle stehen? (106,500100000,'???????','he',0,0,null,null,'3000-01-01',300500000) klappt zumindest für mich genabbelt wrote: > > Das sind alles Fehler mit hebraeischen/yiddischen Zeichen: he, yi > Kann hier jemand erklären, was daran falsch ist bzw. wie's richtig > heissen muss? > > Version 0.2.4d: > INSERT INTO geodb_textdata > VALUES(106,'???????',500100000,'he',0,0,null,null,'3000-01-01',300500000); > > Version 0.2.5.2: > INSERT INTO geodb_textdata > VALUES(106,???????',500100000','he',0,0,null,null,'3000-01-01',300500000);/* > A */ > > Die alte Syntax war anscheinend ok - aber warum? > Ich vermute, das ' ist falsch gesetzt - aber ich kann hier nicht > wirklich erkennen, wo er sitzt - die Umkehrung der Schreibrichtung > scheint mir hier einen Streich zu spielen. Im VIM sieht die neuere > Schreibweise eigentlich richtiger aus, anscheinend ein Trugschluss. > -- View this message in context: http://www.nabble.com/Importfehlern-bei-opengeodb-0251_2007-10-02.sql-tf4560126.html#a13029278 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From malte at hsv-mail.de Thu Oct 4 00:36:20 2007 From: malte at hsv-mail.de (Molt) Date: Wed, 3 Oct 2007 15:36:20 -0700 (PDT) Subject: [opengeodb] Importfehlern bei opengeodb-0251_2007-10-02.sql In-Reply-To: <13029278.post@talk.nabble.com> References: <470402D9.2040200@gmx.de> <13029278.post@talk.nabble.com> Message-ID: <13029289.post@talk.nabble.com> Also hier scheint wirklich die Schreibrichtung einen Streich zu spielen! Hier in der Mailingliste ists jedenfalls korrekt wie man an den Qotes sieht - in der SQL-Datei steht die 500xxx aber an 3. Position. Molt wrote: > > Hmm, mag sein, dass ich das Problem nicht recht deute - aber der Typ > müsste doch an 2. Stelle stehen? > (106,500100000,'???????','he',0,0,null,null,'3000-01-01',300500000) > klappt zumindest für mich > > > genabbelt wrote: >> >> Das sind alles Fehler mit hebraeischen/yiddischen Zeichen: he, yi >> Kann hier jemand erklären, was daran falsch ist bzw. wie's richtig >> heissen muss? >> >> Version 0.2.4d: >> INSERT INTO geodb_textdata >> VALUES(106,'???????',500100000,'he',0,0,null,null,'3000-01-01',300500000); >> >> Version 0.2.5.2: >> INSERT INTO geodb_textdata >> VALUES(106,???????',500100000','he',0,0,null,null,'3000-01-01',300500000);/* >> A */ >> >> Die alte Syntax war anscheinend ok - aber warum? >> Ich vermute, das ' ist falsch gesetzt - aber ich kann hier nicht >> wirklich erkennen, wo er sitzt - die Umkehrung der Schreibrichtung >> scheint mir hier einen Streich zu spielen. Im VIM sieht die neuere >> Schreibweise eigentlich richtiger aus, anscheinend ein Trugschluss. >> > > -- View this message in context: http://www.nabble.com/Importfehlern-bei-opengeodb-0251_2007-10-02.sql-tf4560126.html#a13029289 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From traut at gmx.de Thu Oct 4 08:08:55 2007 From: traut at gmx.de (Martin Trautmann) Date: Thu, 04 Oct 2007 08:08:55 +0200 Subject: [opengeodb] Importfehlern bei opengeodb-0251_2007-10-02.sql In-Reply-To: <13029278.post@talk.nabble.com> References: <470402D9.2040200@gmx.de> <13029278.post@talk.nabble.com> Message-ID: <47048377.5070001@gmx.de> Molt wrote: > Hmm, mag sein, dass ich das Problem nicht recht deute - aber der Typ müsste > doch an 2. Stelle stehen? Ja, mit der Syntax ab 0.2.5 Für mich hatte es so ausgesehen, als wäre die 500100000 an zweiter Stelle - mein Editor kam wohl nicht mit hebräisch klar. Jetzt sollte es passen - neue Release ist fertig und eingespielt. Dank der diesmal raschen und intensiven Hilfe haben wir jetzt vielleicht eine benutzbare Version erreicht. Hauptunterschied zur 0.2.4, wo wir weniger Daten haben: Die PLZ-Gebiete sind nicht drin. Wie sehr werden die vermisst - oder was fehlt euch sonst? Schönen Gruß Martin From traut at gmx.de Thu Oct 4 08:27:52 2007 From: traut at gmx.de (Martin Trautmann) Date: Thu, 04 Oct 2007 08:27:52 +0200 Subject: [opengeodb] Importfehlern bei opengeodb-0251_2007-10-02.sql In-Reply-To: <470402D9.2040200@gmx.de> References: <470402D9.2040200@gmx.de> Message-ID: <470487E8.6060500@gmx.de> nun passt's auch besser im WWW: http://fa-technik.adfc.de/Codierung/opengeodb.pl?locid=105;c=D Jetzt habe ich die Seite insgesamt auf UTF-8 umgestellt - mal sehen, ob's klappt. Der HTML-Validator nennt mir noch ein paar kleine Fehler, die ich noch ausmerzen kann. Schönen Gruß Martin From malte at hsv-mail.de Thu Oct 4 12:34:54 2007 From: malte at hsv-mail.de (Molt) Date: Thu, 4 Oct 2007 03:34:54 -0700 (PDT) Subject: [opengeodb] Version 02513 (2007-10-02) Message-ID: <13037363.post@talk.nabble.com> Also bei mir wird die ohne Komplikationen ausgeführt, super Sache! Besten Dank :) -- View this message in context: http://www.nabble.com/Version-02513-%282007-10-02%29-tf4567986.html#a13037363 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From traut at gmx.de Thu Oct 4 14:17:04 2007 From: traut at gmx.de (Martin Trautmann) Date: Thu, 04 Oct 2007 14:17:04 +0200 Subject: [opengeodb] opengeodb release 0.2.5a Message-ID: <20071004121704.130340@gmx.net> Hallo, dank eurer Mithilfe und der letzten Bestätigung von Molt scheinen die Daten nun von der Syntax her korrekt zu sein. Ich habe daher die 0.2.5.1.3 als sourceforge-release 0.2.5a freigegeben. Im Moment ist das die komplette SQL-release. Bisher gab's hier auch split- und postgres-Varianten. Besteht dafür noch Bedarf? Zunkuenftig geplant ist, dass man sich direkt einen aktuellen Dump erstellen lassen kann, wahlweise komplett oder beschränkt auf eines der Länder. Habt ihr sonst spezielle Wünsche dafür? Schönen Gruß Martin -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger From traut at gmx.de Thu Oct 4 14:36:09 2007 From: traut at gmx.de (Martin Trautmann) Date: Thu, 04 Oct 2007 14:36:09 +0200 Subject: [opengeodb] SQL-Script fuer geodb_hierarchies Message-ID: <20071004123609.130320@gmx.net> Hallo, im aktuellen SQL-Dump finden sich keine geodb_hierarchies mehr - ich halte diese Daten derzeit für redundant. Sie wurden ersetzt durch Vererbungsmechanismen: 400100000 Teil von (of) 400200000 Ebene (level) 400200000 Typ (type) 400100000 verwendet die locid des zugehörigen, nächst höheren Eintrags. 400200000 verwendet Integer-Zahlen 400300000 verwendet beschreibenden Text Der Einfachheit halber deklariere ich hier alles noch als geodb_textdata. Sollte das geändert werden? Zur Erzeugung der geodb_hierarchies bräuchte man nun ein Script, das sich hier die passenden Werte heraussucht: finde alles bis Ebene 40020000 und fülle durch Durchwandern zur nächsthöheren Ebene über 400100000 und dessen 40020000 die geodb_hierarchies auf (bottom up) - oder starte von oben nach unten und übernimm den ganzen geodb_hierarchies-Eintrag aus der Ebene darüber (top-down). In der Deklaration der geodb_hierarchies ist nicht unbedingt eindeutig erklärt, ob die eigene Beschreibung schon Teil der Hierarchie ist oder leer bleibt. Je nach Land sind die Hierarchies auch nicht vollständig gefüllt. Beispielsweise springt in Österreich der level: 1 = Bundesland 3 = Bezirk 5 = Gemeinde 7 = Ort In Deutschland habe ich Bundesland, evtl. Regierungsbezirk, evtl. Region, Kreis (kreisfreie Stadt oder Stadkreis), evtl. Amt / Verwaltungsgemeinschaft, Gemeinde - und darunter beliebig die Ortschaften, Stadtteile, Stadtbezirke, Stadtviertel, Stadtquartiere, statistischen Bezirke, Dörfer, Weiler, Wohnplätze usw. Die Hierarchien wären also wohl staatenspezifisch aufzufüllen. Braucht die jemand? Hat dafür jemand eine SQL-Lösung? Schönen Gruß Martin -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From malte at hsv-mail.de Thu Oct 4 15:19:52 2007 From: malte at hsv-mail.de (Molt) Date: Thu, 4 Oct 2007 06:19:52 -0700 (PDT) Subject: [opengeodb] Version 02513 (2007-10-02) In-Reply-To: <13037363.post@talk.nabble.com> References: <13037363.post@talk.nabble.com> Message-ID: <13039726.post@talk.nabble.com> Die Ortsnamen haben bei mir alle den 500100000er Typ, dieser ist in der typenames jedoch nicht vorhanden. Sind evtl. der 500100000er Typ aus der textdata und der 500100001er Typ aus der typenames identisch? -- View this message in context: http://www.nabble.com/Version-02513-%282007-10-02%29-tf4567986.html#a13039726 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From georg at familieverweyen.de Thu Oct 4 21:19:07 2007 From: georg at familieverweyen.de (Georg V.) Date: Thu, 4 Oct 2007 21:19:07 +0200 Subject: [opengeodb] =?utf-8?q?geodb=5Fhierarchies?= Message-ID: <6b2490a786a483e214816a4dcdd0382e@mb8-2.1blu.de> Hallo Martin, ich finde es schade, dass die Datenstrukturen geändert werden und damit die Möglichkeit entzogen wird, die Nachfolger eines Levels fest zu stellen. Auf jedem Fall ist das Script infoOGDB in seiner Version 0.6 nicht mit der Datenversion 0.2.5a lauffähig. Aus dem gleichen Grund bitte deshalb auch darum, die (sowieso) veraltete Version 0.4 aus sourceforge zu entfernen. Ich werde mich irgendwann um eine neue lauffähige Version, die mit beiden Datenversionen arbeitsfähig ist, kümmern, aber andere Projekte haben derzeit Vorrang. Zu Deiner Frage mit der SPLIT-Version: 47 MB in eine MySQL-Datenbank einzuladen dauert etwas (:-/), so nebenbei können die meisten Webhoster maximal 16 MB große Dateien hochladen und haben eine "etwas" geringere Ausführungsdauer für SQL-Scripte. Oder um es kurz zu machen: Ja es wird eine Split-Version benötigt. Mein Wunsch dazu: Die Nummernbereiche der LOC_ID sollten innerhalb einer Datei geschlossen sein, damit man schneller feststellen kann, welche Datei noch nicht geladen wurde. MfG Georg V. P.S.: Übrigens scheint auch die Datensammlung http://dbpedia.org/ interessant sein, ich werde mal den Datenbestand abgleichen. From traut at gmx.de Thu Oct 4 21:57:19 2007 From: traut at gmx.de (Martin Trautmann) Date: Thu, 04 Oct 2007 21:57:19 +0200 Subject: [opengeodb] Version 02513 (2007-10-02) In-Reply-To: <13039726.post@talk.nabble.com> References: <13037363.post@talk.nabble.com> <13039726.post@talk.nabble.com> Message-ID: <4705459F.6040908@gmx.de> Molt wrote: > Die Ortsnamen haben bei mir alle den 500100000er Typ, dieser ist in der > typenames jedoch nicht vorhanden. Sind evtl. der 500100000er Typ aus der > textdata und der 500100001er Typ aus der typenames identisch? Stimmt, der Fehler war noch drin. Es fehlte auch ein Datumstyp - vgl. http://fa-technik.adfc.de/Codierung/opengeodb/opengeodb-end.sql From traut at gmx.de Thu Oct 4 22:06:10 2007 From: traut at gmx.de (Martin Trautmann) Date: Thu, 04 Oct 2007 22:06:10 +0200 Subject: [opengeodb] geodb_hierarchies In-Reply-To: <6b2490a786a483e214816a4dcdd0382e@mb8-2.1blu.de> References: <6b2490a786a483e214816a4dcdd0382e@mb8-2.1blu.de> Message-ID: <470547B2.5010308@gmx.de> Georg V. wrote: > Hallo Martin, > > ich finde es schade, dass die Datenstrukturen geändert werden und damit > die Möglichkeit entzogen wird, die Nachfolger eines Levels fest zu > stellen. Hallo Georg, Nachfolger hätten uns nur bis zur Gemeinde-Ebene hinab geholfen. Darunter versagen die bisherigen Hierarchien, die obendrein pflegeintensiv sind. > Auf jedem Fall ist das Script infoOGDB in seiner Version 0.6 nicht > mit der Datenversion 0.2.5a lauffähig. Aus dem gleichen Grund bitte > deshalb auch darum, die (sowieso) veraltete Version 0.4 aus sourceforge zu > entfernen. Ich werde mich irgendwann um eine neue lauffähige Version, die > mit beiden Datenversionen arbeitsfähig ist, kümmern, aber andere Projekte > haben derzeit Vorrang. Danke > Zu Deiner Frage mit der SPLIT-Version: 47 MB in eine MySQL-Datenbank > einzuladen dauert etwas (:-/), so nebenbei können die meisten Webhoster > maximal 16 MB große Dateien hochladen und haben eine "etwas" geringere > Ausführungsdauer für SQL-Scripte. Oder um es kurz zu machen: Ja es wird > eine Split-Version benötigt. Mein Wunsch dazu: Die Nummernbereiche der > LOC_ID sollten innerhalb einer Datei geschlossen sein, damit man schneller > feststellen kann, welche Datei noch nicht geladen wurde. Die Nummernbereiche sind jetzt schon nicht geschlossen - ich möchte den Split eher über die landesspezifische Trennung hinbekommen, weil viele ohnehin nur ein Land brauchen. > P.S.: Übrigens scheint auch die Datensammlung http://dbpedia.org/ > interessant sein, ich werde mal den Datenbestand abgleichen. Das sind andere Daten als die von ? http://tools.wikimedia.de/~kolossos/wp-world/pub_CSV_test3.sql.gz Letztere hatte ich mal angesehen. Vieles davon würde z.B. über die Schreibvarianten den Bestand bereichern. Vieles passt aber auch schlecht zusammen - ein schwieriger Abgleich. Schönen Gruß Martin From P.Beier at t-online.de Thu Oct 4 22:30:17 2007 From: P.Beier at t-online.de (Peter H. Beier) Date: Thu, 04 Oct 2007 22:30:17 +0200 Subject: [opengeodb] Version 02513 (2007-10-02) In-Reply-To: <20071004195300.29780.qmail@stefla-web.de> References: <20071004195300.29780.qmail@stefla-web.de> Message-ID: <47054D59.4080803@t-online.de> Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20071004/e627622b/attachment.html From traut at gmx.de Fri Oct 5 08:02:22 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 05 Oct 2007 08:02:22 +0200 Subject: [opengeodb] opengeodb release 0.2.5a In-Reply-To: <87ve9msdw5.fsf@biokovo-amd64.herceg.de> References: <20071004121704.130340@gmx.net> <87ve9msdw5.fsf@biokovo-amd64.herceg.de> Message-ID: <4705D36E.5020508@gmx.de> Slaven Rezic wrote: > Ich habe bislang die Variante opengeodb-...-UTF8-text-orte.zip > genutzt. Hallo Slaven, dafür brauchen wir keine SF-Releases mehr - die Text-Dateien kannst du direkt und jederzeit tagaktuell bekommen: http://fa-technik.adfc.de/Codierung/opengeodb/ -> D.tab usw. Schönen Gruß Martin From malte at hsv-mail.de Fri Oct 5 15:38:48 2007 From: malte at hsv-mail.de (Molt) Date: Fri, 5 Oct 2007 06:38:48 -0700 (PDT) Subject: [opengeodb] Version 02513 (2007-10-02) In-Reply-To: <13037363.post@talk.nabble.com> References: <13037363.post@talk.nabble.com> Message-ID: <13059554.post@talk.nabble.com> Die Typen 100900000 (ein unter Ortsname => evtl. Stadtteil?), 610000000 (Fläche) - evtl. fehlen noch andere. Die beiden stehen auch nicht in der end.sql -- View this message in context: http://www.nabble.com/Version-02513-%282007-10-02%29-tf4567986.html#a13059554 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From traut at gmx.de Fri Oct 5 20:39:25 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 05 Oct 2007 20:39:25 +0200 Subject: [opengeodb] Version 02513 (2007-10-02) In-Reply-To: <13059554.post@talk.nabble.com> References: <13037363.post@talk.nabble.com> <13059554.post@talk.nabble.com> Message-ID: <470684DD.80707@gmx.de> Molt wrote: > Die Typen 100900000 (ein unter Ortsname => evtl. Stadtteil?), 610000000 > (Fläche) - evtl. fehlen noch andere. Die beiden stehen auch nicht in der > end.sql Danke! Martin From mj10777 at googlemail.com Sun Oct 7 14:10:19 2007 From: mj10777 at googlemail.com (Mark Johnson) Date: Sun, 7 Oct 2007 14:10:19 +0200 Subject: [opengeodb] Erfahrungen mit der Umgang mit der neue Version 'opengeodb-02513_2007-10-02.sql' Message-ID: Als ich eine 'Fehlermeldung' zusammengestellen wollte und um dann eine Lösungansatz vorzuschagen, ist mir aufgefallen wie man die Abfragen mit der bestehede Struktur vornehmen soll. Daher stimmen ein Paar der 'Feststellungen' nicht, was sich später herausgestellt wieder. Ich habe daher die 'Vorarbeit' so wie geschrieben hier wiedergegeben, in der Hoffnung das andere die noch Probleme mit der 'neue' Struktur haben den Arbeitsweg nachvollziehen kann. Ein paar praktisch Sql-Beispiele und deren Ergebnise werden gezeigt ohne die `geodb_hierarchies` anzusprechen. Mein Ziel ist es langfristig eine Database aufzubauen mit der jetzige (und frühre) Berliner Straßenamen mit Positionsangaben (Längengrand/Breitengrad) ggf. mit Hausnummern um auf eine Karte diese Punkt anzuzeigen (bei historische Addressen ggf. auf historische Karten). Daher war mein erste Ziel eine Liste von eine Ort und Postleitzahl mit deren eindeutige Positionangabe zubekommen - falls keine Adresse gefunden wird - konnte den Gebiet angezeigt werden wo voraussichlich der gesuchte Adresse sich befindet. Praktische Beispiel in Goggle Maps : 'Fuggerstraße 2, 10777 Berlin' - laut Google Maps gibt es diese Addresse nicht (was nicht stimmt, 1 (als Haus) nicht - aber 2 schon) - Google Maps geht in die mitte der Fuggerstraße als ob man nach 'Fuggerstraße, 10777 Berlin' gesucht hätte. 'Buggerstraße 2, 10777 Berlin' - laut Google Maps gibt es diese Addresse nicht (was stimmt) - Google Maps meldet eine Fehler und das wars. - Ziel sollte sein '10777 Berlin' zu suchen, was bei Google Maps die Zustellamt von 10777 ist. Die 13.613 Datensätze (Eindutige Straßenname per Postleitzahl) für Berlin werde ich in der nächste Woche einspielen und ausprobieren. Manche Sql-Abfragen sehen zwar furchtbar aus (vorallen der letzte), aber die reaktionszeiten sind hervorragend. ---------------------------------------------------- Nachdem ich gestern den ganzen Tag mit der neue 'opengeodb-02513_2007- 10-02.sql.gz' beschäftigt habe, bin ich zur der Ansicht gekommen, das bei der Umstellung eine gravierende Fehler bei der Umstellung passiert ist. Bei der Abfrage : SELECT DISTINCT land.text_type AS "Type_Number" FROM geodb_textdata land bekommt man 12 Datensätze wie unter 'Type_Number' zu sehen ist. Bei der Abfrage : SELECT DISTINCT land.text_type AS "Type_Number", types.name AS "Type_Names" FROM geodb_textdata land, geodb_type_names WHERE land.text_type = types.type_id bekommt man 11 Datensätze wie unter 'Type_Number' und 'Type_Names' zu sehen ist, OHNE die Zeile '45.872 500100000 * Name' Bei der Abfragen : SELECT count(*) FROM geodb_textdata land WHERE (land.text_type = '400100000') habe ich folgen Tabelle aufgebaut um eine Überblick zu bekommen: Count(*) Type_Number Type_Names 41.806 400100000 Teil von 41.807 400200000 Ebene 38.937 400300000 Typ 45.872 500100000 * Name 41.795 500100002 Sortiername 13 500100003 ISO_3166_2 48.397 500300000 Postleitzahl 189 500300001 Postleitzahl Position 12.406 500400000 Telefonvorwahl 16.651 500500000 KFZ-Kennzeichen 38.121 500600000 Amtlicher Gemeindeschlüssel 12.120 500700000 Verwaltungszusammenschluss = 338.114 Bei der Abfrage : SELECT type_id, name FROM geodb_type_names ORDER BY type_id stellt man fest : - es gibt keine '500100000' [war in die 0.2.4 Version mit der name = 'Name'] - 45.872 Datensätze wurde mit diese (nicht existiernde nummer) eingefügt. - folgende Nummer werden nicht mit Inhalte in 'geodb_textdata' benützt [spätere Anmerkung : werden für die Einstellung von 'geodb_locations' benützt] 0 100100000 Erdteil 0 100200000 Staat/Land 0 100300000 Kanton 0 100300000 Bundesland 0 100400000 Regierungsbezirk 0 100500000 Landkreis 0 100600000 Politische Gliederung 0 100700000 Ortschaft 0 100800000 Postleitzahlgebiet Bei der Abfrage [500100002 = Sortierung] : SELECT land.loc_id AS "id_Land", land.text_type AS "Type_Land", land.text_val AS "Land" FROM geodb_textdata land WHERE ((land.text_val = 'Berlin') OR (land.text_val = 'Stuttgart')) AND (land.text_type <> 500100002) ORDER BY Land; id_Land Type_Land Land 109 500100000 Berlin 319 500100000 Berlin 14356 500100000 Berlin 162 500100000 Stuttgart 591 500100000 Stuttgart 24718 500100000 Stuttgart Wünchenswert wäre folgende Ergebnis : id_Land Type_Land Land 109 100300000 Berlin 319 100500000 Berlin 14356 100700000 Berlin Den begriff '500100000' kommt 45.873 in 'opengeodb-02513_2007-10-02.sql' mal vor - create table geodb_textdata wird es einmal verwendet - Überbleibsel von alte Version ? [Hier habe ich bemerkt wie diese System funktioniert. Wichtig ist der Verwendung von 'geodb_locations'] Bei der Abfrage; SELECT stadt.loc_id AS "id_Stadt", local.loc_type AS "Type_Location", form.text_val AS "Text_Stadt", stadt.text_val AS "Stadt" FROM geodb_textdata stadt, geodb_textdata form, geodb_locations local WHERE ((stadt.text_val='Berlin') OR (stadt.text_val = 'Stuttgart')) AND (stadt.text_type <> 500100002) AND (stadt.loc_id = local.loc_id) AND ((local.loc_type = 100300000) OR (local.loc_type = 100400000) OR (local.loc_type = 100500000) OR (local.loc_type = 100600000)) AND (stadt.loc_id = form.loc_id) AND (form.text_type = 400300000) ORDER BY Stadt; id_Stadt Type_Location Text_Stadt Stadt 109 100300000 Bundesland Berlin 319 100500000 Stadt Berlin 14356 100600000 Stadt Berlin 162 100400000 Regierungsbezirk Stuttgart 591 100500000 Landeshauptstadt Stuttgart 24718 100600000 Landeshauptstadt Stuttgart [Warum '100600000' und nicht '100700000'] Eine Abfrage mit dir dazu gehörige Postleitzahlen : SELECT stadt.loc_id AS "id_Stadt", local.loc_type AS "Type_Location", form.text_val AS "Text_Stadt", stadt.text_val AS "Stadt", code.text_val AS "PLZ" FROM geodb_textdata stadt, geodb_textdata form, geodb_locations local, geodb_textdata code WHERE ((stadt.text_val='Berlin') OR (stadt.text_val = 'Stuttgart')) AND (stadt.text_type <> 500100002) AND (stadt.loc_id = local.loc_id) AND ((local.loc_type = 100300000) OR (local.loc_type = 100400000) OR (local.loc_type = 100500000) OR (local.loc_type = 100600000)) AND (stadt.loc_id = form.loc_id) AND (form.text_type = 400300000) AND (code.loc_id = local.loc_id) AND (code.text_type = 500300000) ORDER BY Stadt; - Ergebnis : 226 insgesamt, die Abfrage dauerte 0.0100 sek. - da die Postleitzahlen erst ab der '100600000' ebende eingetragen sind brauchen wir die ander 4 nicht. SELECT stadt.loc_id AS "id_Stadt", local.loc_type AS "Type_Location", form.text_val AS "Text_Stadt", stadt.text_val AS "Stadt", code.text_val AS "PLZ" FROM geodb_textdata stadt, geodb_textdata form, geodb_locations local, geodb_textdata code WHERE (stadt.text_val='Berlin') AND (stadt.text_type <> 500100002) AND (stadt.loc_id = local.loc_id) AND (local.loc_type = 100600000) AND (stadt.loc_id = form.loc_id) AND (form.text_type = 400300000) AND (code.loc_id = local.loc_id) AND (code.text_type = 500300000) ORDER BY Stadt; - Ergebnis (nur Berlin) : 191 insgesamt, die Abfrage dauerte 0.0132 sek. Eine Abfrage mit dir dazu gehörige Postleitzahlen und Längengrad/Breitengrad : SELECT stadt.loc_id AS "id_Stadt", local.loc_type AS "Type_Location", form.text_val AS "Text_Stadt", stadt.text_val AS "Stadt", code.text_val AS "PLZ", coord.lat AS "Latitude", coord.lon AS "Longitude" FROM geodb_textdata stadt, geodb_textdata form, geodb_locations local, geodb_textdata code, geodb_coordinates coord WHERE (stadt.text_val = 'Berlin') AND (stadt.text_type <> 500100002) AND (stadt.loc_id = local.loc_id) AND (local.loc_type = 100600000) AND (stadt.loc_id = form.loc_id) AND (form.text_type = 400300000) AND (code.loc_id = local.loc_id) AND (code.text_type = 500300000) AND (coord.loc_id = code.loc_id) ORDER BY PLZ LIMIT 0,200; - Ergebnis (nur Berlin) : 191 insgesamt, die Abfrage dauerte 0.0227 sek Diese Ergebnis ist eigenlich sinnlos, da die Längengrad, Breitengrade immer gleich sind. - daher habe folgende neue 'type_names' hinzugefügt INSERT INTO geodb_type_names VALUES(500200000,'de','Street'); INSERT INTO geodb_type_names VALUES(500200001,'de','Street Position'); INSERT INTO geodb_type_names VALUES(500200010,'de','Street-Number'); INSERT INTO geodb_type_names VALUES(500200011,'de','Street-Number Position'); INSERT INTO geodb_type_names VALUES(500300001,'de','Postleitzahl Position'); und 189 Datensätze mit der Geocode Abfragen von 'Goggle Maps mit Berliner Postleitzahlen gefüllt. Eine Abfrage mit dir dazu gehörige Postleitzahlen und deren Längengrad/Breitengrad : SELECT stadt.loc_id AS "id_Stadt", local.loc_type AS "Type_Location", form.text_val AS "Text_Stadt", stadt.text_val AS "Stadt", code.text_val AS "PLZ", coord.lat AS "Latitude", coord.lon AS "Longitude" FROM geodb_textdata stadt, geodb_textdata form, geodb_locations local, geodb_textdata code, geodb_textdata plz_code, geodb_coordinates coord WHERE (stadt.text_val='Berlin') AND (stadt.text_type <> 500100002) AND (stadt.loc_id = local.loc_id) AND ((local.loc_type = 100300000) OR (local.loc_type = 100400000) OR (local.loc_type = 100500000) OR (local.loc_type = 100600000)) AND (stadt.loc_id = form.loc_id) AND (form.text_type = 400300000) AND (code.loc_id = local.loc_id) AND (code.text_type = 500300000) AND ((plz_code.text_val = code.text_val) AND (plz_code.text_type = 500300001)) AND (coord.loc_id = plz_code.loc_id) ORDER BY PLZ LIMIT 0,200; - Ergebnis (nur Berlin) : 189 insgesamt, die Abfrage dauerte 0.0798 sek.) - hier haben wir eine Abweichung von 2 Datensätze - 12529 - ist Berlin Mahlsdorf Süd und laut 'Goggle Maps' liegt in Land Brandenburg - 12623 - ist Flughafen Berlin-Schönefeld und liegt eindeutig in Land Brandenburg. Hier die Abfrage um diese beide PLZ rauszubekommen - 2 insgesamt, die Abfrage dauerte 0.0283 sek.) SELECT stadt.loc_id AS "id_Stadt", local.loc_type AS "Type_Location", form.text_val AS "Text_Stadt", stadt.text_val AS "Stadt", code.text_val AS "PLZ", coord.lat AS "Latitude", coord.lon AS "Longitude" FROM geodb_textdata stadt, geodb_textdata form, geodb_locations local, geodb_textdata code, geodb_coordinates coord WHERE (stadt.text_val = 'Berlin') AND (stadt.text_type <> 500100002) AND (stadt.loc_id = local.loc_id) AND (local.loc_type = 100600000) AND (stadt.loc_id = form.loc_id) AND (form.text_type = 400300000) AND (code.loc_id = local.loc_id) AND (code.text_type = 500300000) AND (coord.loc_id = code.loc_id) AND (code.text_val NOT IN ( SELECT plz_code.text_val FROM geodb_textdata stadt, geodb_textdata form, geodb_locations local, geodb_textdata code, geodb_textdata plz_code, geodb_coordinates coord WHERE (stadt.text_val='Berlin') AND (stadt.text_type <> 500100002) AND (stadt.loc_id = local.loc_id) AND (local.loc_type = 100600000) AND (stadt.loc_id = form.loc_id) AND (form.text_type = 400300000) AND (code.loc_id = local.loc_id) AND (code.text_type = 500300000) AND ((plz_code.text_val = code.text_val) AND (plz_code.text_type = 500300001)) AND (coord.loc_id = plz_code.loc_id) ) ) ORDER BY PLZ; Auch wen Sql-Abfragen furchtbar aussehen, die reaktionszeiten sind hervorragend und bringen die gewünschte Ergebnisse. Mark Johnson, 2007-10-07 -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20071007/641b2f7d/attachment-0001.html From georg at familieverweyen.de Mon Oct 8 06:56:37 2007 From: georg at familieverweyen.de (Georg Verweyen) Date: Mon, 08 Oct 2007 06:56:37 +0200 Subject: [opengeodb] Geodb_hierarchies Ersatz Message-ID: <4709B885.3060902@familieverweyen.de> Hallo zusammen, der Ersatz mit den Werten 400.100.000 und 400.200.000 scheint nicht die Möglichkeit zu beinhalten, dass man Werte auch historisch modifizieren kann (Stichwort: Gemeindeumstrukturierung). Alle Werte haben einen dauerhaften Gültigkeitszeitraum. Es fehlen übrigens Einträge für die loc_id 35698 (Bruxelles) und 18048 (Amt Heideblick, hier beide Werte). Die oberen Werte wie Europa sowie 0 und -1 natürlich ausgeschlossen. Da scheint mir ein erheblicher Informationsverlust statt gefunden zu haben. Die gilt übrigens auch für die Postleitzahlen: In Version 0.2.4d waren gut 2/3 alle Postleitzahlen gültig seit der deutschen Umstellung auf 5 stellige Postleitzahl, in Version 0.2.5a sind nur 49 von 48.397 Einträgen nicht dauerhaft gültig. MfG Georg V. From mj10777 at googlemail.com Mon Oct 8 07:39:22 2007 From: mj10777 at googlemail.com (Mark Johnson) Date: Mon, 8 Oct 2007 07:39:22 +0200 Subject: [opengeodb] Frage zur 'valid_since' und 'date_time_since' Message-ID: Wie rechnet man eine Datum auf die Integer Wert Datum um? z.b. für folgende Postleitzahlensysteme : Deutsches Reich : 1941-07-25 Bundesrepublik : 1962-03-23 bis 1993-06-30 DDR : 1965-01-01 bis 1993-06-30 Deutschland : 1993-07-01 Schweiz : 1964-10-01 Österreich : 1966-01-01 Niederlande : 1978-03-01 Frankreich : 1972-06-03 Belgien : nicht bekannt. konnte man die bestehende Postleitzahlenangaben dementsprechend einstellen? -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20071008/2d078b4d/attachment.html From probst at netconstructions.de Mon Oct 8 18:06:40 2007 From: probst at netconstructions.de (Michael Probst) Date: Mon, 8 Oct 2007 18:06:40 +0200 Subject: [opengeodb] Ein paar Fragen zu Ihrer OpenGeoDB-Version In-Reply-To: <4701EF44.1020806@gmx.de> References: <4701EF44.1020806@gmx.de> Message-ID: Hallo, ich habe über die letzten Wochen hinweg ein wenig die Nachrichten aus der Newsgroup verfolgt, die dem neuen OpenGeoDB Release gefolgt waren. Insgesamt scheinen alle zu wissen, worum es geht, aber ich habe diese Infos nicht finden können (bin aber auch noch nicht lange Abonennt in der NG) und wundere mich etwas, weswegen ich Ihnen jetzt einfach mal eine Mail schreibe: Ist die ADFC-Version (vom adfc-Server) ein neuer Branch der OpenGeoDb, die anscheinend ja tot ist (?) ? Sind denn auch neue und bessere GeoDaten in der ADFC-Version? Verbesserung der Daten der Länder A, CH? Gibt es über den changelog.html noch weitere Einsichten in die Änderung ggü. der Version von der OpenGeoDB Website? Und sollte man dann nicht mal die Leute von der OpenGeoDB anschreiben, ob sie nicht wenigsten einen Link auf den ADFC-Server stellen wollen? Ich glaube, viele Leute haben momentan nämlich eine gewisse Scheu ggü. der OpenGeoDB, weil sich so lange nichts mehr um das Projekt herum getan hat (zumindest sagt die Website dies aus). Ich denke, alle Entwickler und Anwender würden von mehr Publicity einer neuen Version, sofern sie Verbesserungen aufweist, profitieren. Ich habe auch das Interface zum Editieren von Daten gesehen. Fantastisch!, eben soetwas hatte ich selbst schon geplant, weil ich momentan große Verbesserungsmöglichkeiten bei Daten aus AT und CH sehe. Könnte man das nicht auch von der OpenGeoDB-Site aus verlinken? Warum kennt das ?kein Mensch? :-) ? Ich selbst bin Entwickler der Umkreissuche OpenGeoNearestNeighbours, http://www.mprobst.de/OpenGeoNearestNeighbours/ , die ebenfalls auf Daten der OpenGeoDB basiert. Mit schönen Grüßen Michael Probst From traut at gmx.de Mon Oct 8 18:26:31 2007 From: traut at gmx.de (Martin Trautmann) Date: Mon, 08 Oct 2007 18:26:31 +0200 Subject: [opengeodb] Ein paar Fragen zu Ihrer OpenGeoDB-Version Message-ID: <20071008162631.117060@gmx.net> > und wundere mich etwas, weswegen ich Ihnen jetzt einfach mal > eine Mail schreibe: Hallo Michael, wolltest du mir privat schreiben? Die Frage ueber die Liste geht voellig in Ordnung / vielleicht interessiert das auch andere (und nicht nur Steflas kaputten vacation bot). Ich bleibe daher auch einfach beim ueblichen Du. > Ist die ADFC-Version (vom adfc-Server) ein neuer Branch der > OpenGeoDb, die anscheinend ja tot ist (?) ? Es ist moeglicherweise die Fortsetzung des bisherigen Systems - aber auf einem eingeschraenkten Testvehikel. Dort laeuft keine echte, volle SQL-Datenbank sondern ein eher einfaches Perl-Script. Statt einer SQL-Datenbank werden einfache Text-Dateien verwendet, die von jedem einsehbar und direkt nutzbar sind. > Sind denn auch neue und bessere GeoDaten in der ADFC-Version? Ja > Verbesserung der Daten der Länder A, CH? Ja, vor allem dort - denn Deutschland selbst war bis zur Gemeindeebene schon recht vollsteaendig. > Gibt es über den changelog.html noch weitere Einsichten in > die Änderung ggü. der Version von der OpenGeoDB Website? http://fa-technik.adfc.de/code/opengeodb.pl?action=changes zeigt nur die Aenderungen innerhalb des aktuellen Datenbestands. Die Aenderungen aus dem Wechsel von 0.2.4d auf 0.2.5a sind nicht protokolliert. Bei Bedarf kann ich hier mal einen diff erstellen. > Und sollte man dann nicht mal die Leute von der OpenGeoDB > anschreiben, ob sie nicht wenigsten einen Link auf den > ADFC-Server stellen wollen? Die "Leute von der OpenGeoDB" kennen die Version, die beim ADFC geparkt ist. http://opengeodb.giswiki.org/wiki/OpenGeoDB verweist auch durchaus schon auf diesen Testbetrieb. Du erwartest vermutlich direkt eine Referenzierung auf http://opengeodb.de? Mal sehen, ob Manuel dazu mal Lust hat, ob er gleich mal Perl auf seinem Server installiert oder wie das am besten eingerichtet wird. Schoenen Gruss Martin -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger From traut at gmx.de Mon Oct 8 22:00:59 2007 From: traut at gmx.de (Martin Trautmann) Date: Mon, 08 Oct 2007 22:00:59 +0200 Subject: [opengeodb] Geodb_hierarchies Ersatz In-Reply-To: <4709B885.3060902@familieverweyen.de> References: <4709B885.3060902@familieverweyen.de> Message-ID: <470A8C7B.1030501@gmx.de> Georg Verweyen wrote: > Hallo zusammen, > > der Ersatz mit den Werten 400.100.000 und 400.200.000 scheint nicht die > Möglichkeit zu beinhalten, dass man Werte auch historisch modifizieren > kann (Stichwort: Gemeindeumstrukturierung). Alle Werte haben einen > dauerhaften Gültigkeitszeitraum. Hallo Georg, der dauerhafte Gültigkeitszeitraum ergibt sich aber nicht prinzipiell aus der 400100000, sondern aus den derzeit noch fehlenden Datumsangaben. Hier liegt bisher ein prinzipielles Problem vor, da hier eine schlichte Konvertierung einer Text-Datei in die SQL-Syntax erfolgt und dabei Dummy-Datumsangaben eingesetzt werden. Das ist insofern ok, da alle bisherigen mit Datum versehenen Angaben archiviert wurden und den konvertierten Daten hinzugefügt werden. Demzufolge sollte nichts fehlen, was inzwischen ausgeschieden ist. Hingegen haben wir derzeit ein Problem bei Einträgen, die mit bekanntem Datum hinzugefügt wurden und zu den Basisdaten hinzugehören: Solche Einträge können doppelt vorkommen, einmal mit Anfangsdatum und einmal ohne. > Es fehlen übrigens Einträge für die > loc_id 35698 (Bruxelles) und 18048 (Amt Heideblick, hier beide Werte). > Die oberen Werte wie Europa sowie 0 und -1 natürlich ausgeschlossen. Danke, Brüssel sollte natürlich dabei sein. Warum es fehlt, weiss ich derzeit nicht - in B.tab steht es eigentlich drin. Ich werde dem mal nachgehen. [deutlich später]... hm, 35698 ist doch drin, so wie es sich gehört? > Da scheint mir ein erheblicher Informationsverlust statt gefunden zu haben. Wie gesagt, würde ich das eher verneinen. Im Gegenteil habe ich hier ein Archiv der letzten paar Jahre mit Gemeindeauflösungen, die ich bei Gelegenheit noch einspielen will - dafür fehlt aber noch die Eingabemaske für Angaben mit Datumswert. > Die gilt übrigens auch für die Postleitzahlen: In Version 0.2.4d waren > gut 2/3 alle Postleitzahlen gültig seit der deutschen Umstellung auf 5 > stellige Postleitzahl, in Version 0.2.5a sind nur 49 von 48.397 > Einträgen nicht dauerhaft gültig. Sprich, dir fehlt das Datum "1993-07-01" als Startdatum der fünfstelligen PLZ? Stimmt, da haben nur die 49 späteren PLZ-Einträge ein solches Datum. Die von mir genutzte und ins Netz gestellte Version hat einige Einschränkungen und Vereinfachungen. Mit denen können wir entweder leben - oder jemand stellt eine echte SQL-Version mit Wikifizierung der Eingabemöglichkeiten ins Netz, so dass dort alles vorhanden bleibt. Mit dem hier genannten Subject hat das aber wenig zu tun - ich bin weiterhin der Auffassung, dass die geodb_hierarchies durch passende SQL-Befehle automatisch erzeugt werden können, notfalls selbst mit der von der vermissten Datumsangabe. Kurz nachgeschlagen: in den letzten Monaten habe ich die Änderungen noch nicht eingetragen. Sonst sind das 3200 Änderungen, von denen 1569 Orte erst in der opengeodb drin sind. Beispiel: 26160: Wildberg bei Neustadt, Dosse, bis 1997-12-30 (ehem. Gemeinde; AGS: 12068464) heute Teil von 24881 Schönen Gruß Martin From traut at gmx.de Thu Oct 11 13:26:35 2007 From: traut at gmx.de (Martin Trautmann) Date: Thu, 11 Oct 2007 13:26:35 +0200 Subject: [opengeodb] Daten von Geonames & Wikipedia Georeferenzierung Message-ID: <20071011112635.296280@gmx.net> Hallo, hat von euch schon jemand einmal die Wikipedia-Daten mit opengeodb abgeglichen? http://tools.wikimedia.de/~kolossos/wp-world/pub_CSV_test3.sql.gz bringt volle SQL-Dumps (Stand Juli 2007), http://download.geonames.org/export/dump/ (tagaktuell) bringt fuer Deutschland etwa 175 000 Einträge, davon fast 80 000 vom Typ "P" (city, village,...) und 18 000 vom Typ "A" (country, state, region,...) http://www.geonames.org/export/codes.html Koordinatenbereich von 47.3166667 bis 55.0167 (und ein falsch eingeordnetes Sande weiter noerdlich) und 5.8666667 bis 15.0333333 Beispiel: 2937969 Deschka Deschka Auenblick 51.2666667 15.0333333 P PPL DE DE 13 0 166 Europe/Berlin 1994-01-08 Die Koordinaten von geonames sehen so schlecht wie die von nima aus (vermutlich stammen sie von dort), die Schreibvarianten sind aber evtl. interessant. Geonames selbst hat sich z.B. bei den PLZ aus den opengeodb entwickelt, ist inzwischen aber wohl weit groesser geworden. Vor der Wiki-Oberflaeche dort ziehe ich meinen Hut (auch wenn ich noch nicht kapiere, wie sie bedient wird) -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From mail at torsten-weiler.de Thu Oct 11 17:03:55 2007 From: mail at torsten-weiler.de (Torsten Weiler) Date: Thu, 11 Oct 2007 17:03:55 +0200 Subject: [opengeodb] Daten von Geonames & Wikipedia Georeferenzierung In-Reply-To: <20071011112635.296280@gmx.net> Message-ID: <002501c80c17$f1c41600$02a8a8c0@torsten> Moin Listler, ich bin der neue und muss nun ehrlich sagen "Bahnhof" auch wenn die Streiken. Was um Himmelswillen sind den Einträge vom Typ P oder Typ A und warum spricht man hier Spanisch? :o) Macht mich total irre. Gibt es irgend wo ne Docu die ich mir einmal zu gemühte führen kann wie denn die Geodaten etc. aufgebaut sind. "Gute Links" oder ne schöne pdf-Datei ausdrucken würden auch schon reichen und wenn's geht so, das ein GeoDepp das auch verstehen kann. Als Nordlicht kann ich mit der Navigation (Koordinaten) etc. schon mal umgehen nur schnall ich die Datenstruktur der openGeoDB nicht. Eine brennende Frage hab ich da auf jeden Fall! Wie kommt Onkel GeoDepp denn an einen Ort wenn er die Postleitzahl hat oder umgekehrt? Und was ist nun der bessere Datenbestand openGeoDB oder Geonames? Ich möchte eine Umkreissuche in eine bestehende Webseite integrieren und würde gerne auf OGNN oder ähnliches verzichten. Die GeoClass ist soweit ich das verstehe mit der openGeoDB 2.5 Version auch nicht kompatible. Grüße der GeoDepp PS. Autoresponder ist ne super Idee weiß wenigsten jeder dass man nicht zu Hause ist! -- Torsten Weiler From traut at gmx.de Thu Oct 11 17:58:08 2007 From: traut at gmx.de (Martin Trautmann) Date: Thu, 11 Oct 2007 17:58:08 +0200 Subject: [opengeodb] Daten von Geonames & Wikipedia Georeferenzierung Message-ID: <20071011155808.238100@gmx.net> > Moin Listler, > ich bin der neue und muss nun ehrlich sagen "Bahnhof" auch > wenn die Streiken. > Was um Himmelswillen sind den Einträge vom Typ P oder Typ A > und warum spricht man hier Spanisch? > :o) Macht mich total irre. Hallo Torsten! Jo mei, die Links schreibe ich in den Text nur rein, weil Outlook die dann so hypsch automatisch blau faerbt :-) Typ P und Typ A ist nix, was du in der opengeodb kennen muesstest. Der Datenhamster der Daten von Geonames unterscheidet damit aber verschiedene Kategorien, wie "P"opulated Places oder "A"dministrativa - also irgendwelche "A"mtlichen Gliederungen (oder sollte ich dich mit "P"olitischen Gliederungen noch mehr verwirren koennen?). > Gibt es irgend wo ne Docu die ich mir einmal zu gemühte > führen kann wie denn die Geodaten etc. aufgebaut sind. Als ungeübter Anwender gehst du am einfachsten mal nach http://fa-technik.adfc.de/code/opengeodb.pl und gibst dort irgendwas ein, wie z.B. "Weiler". Dann schaust du dir mal die Ergebnisse an, wie z.B. den Ort "Weiler bei Bingen" http://fa-technik.adfc.de/code/opengeodb.pl?locid=25818;c=D > "Gute Links" oder ne schöne pdf-Datei ausdrucken würden auch > schon reichen und wenn's geht so, das ein GeoDepp das auch > verstehen kann. Als Nordlicht kann ich mit der Navigation > (Koordinaten) etc. schon mal umgehen nur schnall ich die > Datenstruktur der openGeoDB nicht. Die ist auch beliebig kompliziert, oder auch beliebig einfach. Du hast irgendwelche Daten (Postleitzahl, Einwohner, Amtlicher Gemeindeschluessel, den Ortsnamen auf arabisch usw.). Diese Daten gehoeren in irgendwelche Schubladen. Weil das ganz aber in verschiedene Datenbanken reingenudelt werden kann, und weil ein Austauschformat dafuer SQL ist, steht auf der Schublade der Postleitzahl nun eben nicht "PLZ", sondern 500300000 Diese Schubladenbeschriftung ist z.B. in http://sourceforge.net/project/downloading.php?group_id=132421&use_mirror=mesh&filename=Constants.txt&4344213 aufgedröselt und in http://sourceforge.net/docman/display_doc.php?docid=34099&group_id=132421 abgebildet. Jede Socke, die du in eine solche Schublade packst, kannst du auch noch mit einem Datum besticken, wann du sie das erste mal angezogen hast und wann du sie wegwerfen magst (Beginn und Ende der Gültigkeit, Genauigkeit dieser Datumsangabe) > Eine brennende Frage hab ich da auf jeden Fall! > Wie kommt Onkel GeoDepp denn an einen Ort wenn er die > Postleitzahl hat oder umgekehrt? Wenn du den Ort zu einer PLZ willst, dann gibst du z.B. in obigem Link zur opengeodb.pl einfach die PLZ ein und bekommst ALLES angezeigt, wo diese fünf Ziffern vorkommen - notfalls also auch wenn diese in der Telefonvorwahl auftauchen, in den Koordinaten, als Einwohner usw. Wenn du das sauberer machen willst, dann fragst du z.B. eine SQL-Datenbank ab: zeige mir alles, wo die Zahl "01234" (die du für eine PLZ hältst) in der Schublade der Postleitzahlen steckt (du erinnerst dich, auf der Schublade steht 500300000). Dann spuckt dir SQL eine Zahl aus, mit der du dir dann weitere Infos zu dieser Zahl abrufen kannst. Wenn du hingegen zu einem Ort die Postleitzahl wissen willst - dann gehst du am besten zur Post und fragt deren Postleitzahlverzeichnis ab. Scherz beiseite: du kannst dir auch zu jeden bekannten Ort die bekannten Postleitzahlen anzeigen lassen. Wenn ein Ort aber mehrere Postleitzahlen enthält, so bekommst du die alle zusammen hingeworfen,, ohne zu wissen, welche davon nun in welche Ecke der Stadt gehört. Es gibt ein kleines Spezialgebiet in der opengeodb, die sich genau jenen Postleitzahlen widmet: Dort wird für je eine Postleitzahl eine einzelne repräsentative Koordinate genannt, zusammen mit einem dafür repräsentativen Ort. In der Praxis kann die gleiche Postleitzahl für viele verschiedene Orte gemeinsam genutzt werden. In der Praxis kann es sogar vorkommen, dass ein einzelnes Haus noch zu einer Postleitzahl gehört, obwohl dieses Haus in einem ganz anderen Postleitzahlgebiet liegt: Der Briefträger (nennen wir ihn mal ganz altmodisch so) erreicht dieses Haus auf seiner Runde möglicherweise viel einfacher als der Kollege mitder Nachbar-Postleitzahl, von dessen Gebiet aus überhaupt kein Weg zu diesem Haus führen muss. Gerade solche Feinheiten weiss aber nur die Post selbst - und je nach postalischer Notwendigkeit verteilt die nach eigenem Ermessen eben, welche Adresse sie wie postalisch einordnen möchte. > Und was ist nun der bessere > Datenbestand openGeoDB oder Geonames? Was ist in deiner Definition "besser"? Viele verwenden von der opengeodb nur das kleine Spezialgebiet, dass zu einem PLZ-Gebiet eine bestimmte Koordinate gehört und machen damit eine Umkreissuche. Geonames ist da quasi genauso gut - denn Geonames hat seine Infos aus der opengeodb abgeleitet. opengeodb war bisher recht träge (seltene Updates) und kleiner - dafür aber sehr gut aufgeräumt, denn bis hinab zur Gemeindeebene haben wir alles quasi komplett abgedeckt. Geonames bietet viel mehr Masse - aber in teils recht fraglicher Qualität. Bei einer Stichprobe fand ich da z.B. an einer Stelle satte fünf Einträge, wo opengeodb überhaupt nichts hat (nebenbei alle vom Typ "P" - nicht gezählt z.B. alle vom Typ "S", also irgendwelche Sites wie z.B. Hoteladressen). Von diesen fünf war eine korrekt, eine zweite ein Duplikat dazu und die anderen drei gehören ganz wo anders hin. Quelle dieser Daten: unbekannt. Vieles davon geht immer wieder auf den gleichen Grundbestand zurück (NIMA) - leicht erkennbar an der Ortsauflösung im Zehn-Sekunden-Raster (du sagtest ja, Koordinaten wären dir vertraut?) > Ich möchte eine Umkreissuche in eine bestehende Webseite > integrieren und würde gerne auf OGNN oder ähnliches verzichten. > Die GeoClass ist soweit ich das verstehe mit der openGeoDB > 2.5 Version auch nicht kompatible. Ah, also wieder mal die klein-klein-Lösung einer Umkreissuche :-) Ich selbst verwende hier einfach eine Text-Datei mit < 500 KB, in der zu jeder PLZ die Koordinaten stehen - und die wesentlichen Infos kriegt man auch in eine noch kleinere Datei. Mit einem Perl-Script wird das dann abgefragt. Fuer deinen Zweck brauchst du weder die opengeodb, noch die geonames, sondern nur eben jene einfache Information. > Grüße der GeoDepp Jeder fängt mal klein an :-) Schönen Gruß Martin -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From taney at web.de Thu Oct 11 18:00:56 2007 From: taney at web.de (Taner Ayaydin) Date: Thu, 11 Oct 2007 18:00:56 +0200 Subject: [opengeodb] Daten von Geonames & Wikipedia Georeferenzierung In-Reply-To: <002501c80c17$f1c41600$02a8a8c0@torsten> Message-ID: Hallo, die Frage stelle ich mir auch. Bisher habe ich nur eine sehr alte GeoDB am Laufen, in der alle Daten (adm0, adm1, adm3, ort, ortsteil, plz usw.) in einer Tabelle gespeichert sind. Würde jedoch gerne die Tabelle updaten (0.25?), weiß aber leider nicht, was das ganze 5100000, 310000 usw. soll. Könnte mir jemand 2-3 ganz Simple Beispiele geben, wie ich mit einer PLZ folgende Daten komplett auslesen kann: Bundesland, Kennzeichen, Kreis, Stadtname und Land. Einmal anhand der PLZ nur den Stadtnamen. Und einmal evtl. ganz andere Sachen wie Einwohner und so ganz andere Dinger. Was ich mir auch überlegt hatte. Inwiefern ist es möglich, dass ein Benutzer eine PLZ angibt und sobald kein Treffer (kein Ortsname) gefunden werden sollte, dann ein paar Ortsnamen aus der näheren Umgebung als Vorschlag aufgelistet werden. Für Eure Bemühungen bedanke ich mich im Voraus. Viele Grüße > Moin Listler, > ich bin der neue und muss nun ehrlich sagen "Bahnhof" auch wenn die > Streiken. > Was um Himmelswillen sind den Einträge vom Typ P oder Typ A und warum > spricht man hier Spanisch? > :o) Macht mich total irre. > > Gibt es irgend wo ne Docu die ich mir einmal zu gemühte führen kann wie > denn die Geodaten etc. aufgebaut sind. > "Gute Links" oder ne schöne pdf-Datei ausdrucken würden auch schon > reichen und wenn's geht so, das ein GeoDepp das auch verstehen kann. Als > Nordlicht kann ich mit der Navigation (Koordinaten) etc. schon mal > umgehen nur schnall ich die Datenstruktur der openGeoDB nicht. > > Eine brennende Frage hab ich da auf jeden Fall! > Wie kommt Onkel GeoDepp denn an einen Ort wenn er die Postleitzahl hat > oder umgekehrt? Und was ist nun der bessere Datenbestand openGeoDB oder > Geonames? > > Ich möchte eine Umkreissuche in eine bestehende Webseite integrieren und > würde gerne auf OGNN oder ähnliches verzichten. > Die GeoClass ist soweit ich das verstehe mit der openGeoDB 2.5 Version > auch nicht kompatible. > > Grüße der GeoDepp > > PS. Autoresponder ist ne super Idee weiß wenigsten jeder dass man nicht > zu Hause ist! phpbar.de) From maillist at torsten-weiler.de Thu Oct 11 18:53:50 2007 From: maillist at torsten-weiler.de (Torsten Weiler) Date: Thu, 11 Oct 2007 18:53:50 +0200 Subject: [opengeodb] Daten von Geonames & Wikipedia Georeferenzierung In-Reply-To: <20071011155808.238100@gmx.net> Message-ID: <004001c80c27$4cd03330$02a8a8c0@torsten> Hallo Martin, ich geb dir'n afrikanischen! Die ersten beiden #0000FF da hab ich die 2.5 her Mal was neues wäre klasse und nun kommt der mit so alten Kamellen an. :-)) Ja der 2'te und 3'te #0000FF sind natürlich genial! Treffer versenkt! Genau so was hab ich gesucht. Der 4'te -> DB-Struktur zum gucken Klasse > Als ungeübter Anwender Na so schlimm ist doch nicht oder? > http://fa-technik.adfc.de/code/opengeodb.pl und gibst dort irgendwas > ein, wie z.B. "Weiler".... Ja ja mich gibt’s in der OGDB! :o) Das hab ich > Einöde natürlich selbst schon getestet. > Was ist in deiner Definition "besser"? > OK sorry die genauere (Qualität der Daten). Aber diese Frage hast ja auch schon beantwortet . > Ah, also wieder mal die klein-klein-Lösung einer Umkreissuche :-) > Naja so ein bisschen größer wird’s schon werden e00 mapfiles etc. Grüße das openGeoDeppchen ;-) From rainer.bruch at t-online.de Fri Oct 12 22:53:08 2007 From: rainer.bruch at t-online.de (Rainer Bruch) Date: Fri, 12 Oct 2007 22:53:08 +0200 Subject: [opengeodb] Beispieldaten werden nicht korrekt in die MySQL-Datenbank importiert Message-ID: <000501c80d11$e4d8aeb0$152aa8c0@cubeline> Hallo in die Runde. Ich bin "fabrikneu" in diesem Forum, und erhoffe mir Hilfe für nachfolgendes Problem beim Datenimport in meine MySQL-Geodatenbank. Keinen der folgenden SQL-Datensätze kann ich fehlerfrei in meine zuvor erstellte MySQL-Datenbank "geodb" einlesen: - opengeodb-0.2.4d-UTF8-mysql.sql - opengeodb-0.2.4a-UTF8-MyISAMmysql.sql (von "OpenGeoNearestNeigbours") - opengeodb-02513_2007-10-02.sql Mein verwendetes System ist: - Localhost auf Windows XP mit SP2 ###### ApacheFriends XAMPP (Basispaket) version 1.6.3a ###### - Apache 2.2.4 - MySQL 5.0.45 - PHP 5.2.3 + PHP 4.4.7 + PEAR (ich verwende nur PHP 5.2.3!) - phpMyAdmin 2.10.3 PhpMyAdmin empfiehlt bei Importproblemen die Standardwerte für "memory_limit", "post_max_size" und "upload_max_filesize" in der "php.ini" der Größe der Datenbank anzupassen! Ich habe diese Werte wie folgt angepasst: memory_limit = 50M, post_max_size = 50M, upload_max_filesize = 50M Meine "geodb" MySQL-Datenbank habe ich (wie gefordert) mit dem "utf8" Zeichensatz kodiert! PhpMyAdmin bricht troptzdem den Datenimport ab, und empfiehlt für große Datenimports "BigDump" zu verwenden. Auch das habe ich versucht. Leider bricht aber auch der "BigDump MySQL Importer v0.28b" den Import am Schluß mit folgender Fehlermeldung ab: <--- Anfang Fehlermeldung für "opengeodb-0.2.4d-UTF8-mysql.sql" --->>> Error at the line 19: ) TYPE=InnoDB CHARACTER SET utf8; Query: /* * Table structure for table 'geodb_type_names' */ create table geodb_type_names ( type_id integer not null, type_locale varchar(5) not null, name varchar(255) not null, /* varchar(500)? */ unique (type_id, type_locale) ) TYPE=InnoDB CHARACTER SET utf8; MySQL: Table 'geodb_type_names' already exists Stopped on error <<< --- Ende Fehlermeldung für "opengeodb-0.2.4d-UTF8-mysql.sql" --->>> Für "opengeodb-0.2.4d-UTF8-mysql.sql" zeigt "PhpMyAdmin 2.10.03" 8 Tabellen mit einer Gesamtröße von 26,7 MiB an <--- Anfang Fehlermeldung für "opengeodb-0.2.4a-UTF8-MyISAMmysql.sql" --->>> Error at the line 15: ) TYPE=MyISAM CHARACTER SET utf8; Query: /* * Table structure for table 'geodb_type_names' */ create table geodb_type_names ( type_id integer not null, type_locale varchar(5) not null, name varchar(255) not null, /* varchar(500)? */ unique (type_id, type_locale) ) TYPE=MyISAM CHARACTER SET utf8; MySQL: Table 'geodb_type_names' already exists Stopped on error <<< --- Ende Fehlermeldung für "opengeodb-0.2.4a-UTF8-MyISAMmysql.sql" --->>> Für "opengeodb-0.2.4a-UTF8-MyISAMmysql.sql" zeigt "PhpMyAdmin 2.10.03" 10 Tabellen mit einer Gesamtröße von 6,7 MiB an <<<--- Anfang Fehlermeldung für "opengeodb-02513_2007-10-02.sql" --->>> Error at the line 19: ) TYPE=InnoDB CHARACTER SET utf8; Query: /* * Table structure for table 'geodb_type_names' */ create table geodb_type_names ( type_id integer not null, type_locale varchar(5) not null, name varchar(255) not null, /* varchar(500)? */ unique (type_id, type_locale) ) TYPE=InnoDB CHARACTER SET utf8; MySQL: Table 'geodb_type_names' already exists Stopped on error <<< --- Ende Fehlermeldung für "opengeodb-02513_2007-10-02.sql" --->>> Für "opengeodb-02513_2007-10-02.sql" zeigt "PhpMyAdmin 2.10.03" 8 Tabellen mit einer Gesamtröße von 14,3 MiB an Zusammenfassung: alle 3 MySQL-Datensätze haben ein Problem mit der gleichen Tabelle ()! Obwohl alle 3 Datensätze fehlerhaft importiert werden, habe ich zumindest Datenzugriff über die Beispielformulare auf die Datensätze von: - opengeodb-0.2.4d-UTF8-mysql.sql - opengeodb-0.2.4a-UTF8-MyISAMmysql.sql - opengeodb-02513_2007-10-02.sql Da nicht alle Daten in die Tabellen importiert werden, sind die angebotenen Anzeigen natürlich fehlerhaft. Zumindest kann aber so nachgewiesen werden, dass der Datenbankzugriff OK ist! Ich hoffe, dass ich mein Problem verständlich erklären konnte. Daher meine abschließende Frage in die Expertenrunde: - warum kann ich alle 3 Datensätze NICHT korrekt in meine Datenbank importieren? - wie ist die LKösung meines Problems? Vielen Dank im voraus für die Hilfe. Gruß Rainer From maillist at torsten-weiler.de Sat Oct 13 10:38:26 2007 From: maillist at torsten-weiler.de (Torsten Weiler) Date: Sat, 13 Oct 2007 10:38:26 +0200 Subject: [opengeodb] Beispieldaten werden nicht korrekt in dieMySQL-Datenbank importiert In-Reply-To: <000501c80d11$e4d8aeb0$152aa8c0@cubeline> Message-ID: <00d801c80d74$6cc13d30$02a8a8c0@torsten> Hallo Rainer Xampp unter c:\ installiert und den/die Dumps unter c:\ liegen? Einfach auf der Commandline (Start->Ausführen->cmd) in mysql einloggen. C:\xampp\mysql\bin\mysql -u username -p datenbank Nach dem das Passwort abgefragt wurde am mysql prompt folgendes eingeben: mysql> \source C:\opengeodb-0.2.4d-UTF8-mysql.sql Alternativ die Version für Schreibfaule mysql> \. C:\opengeodb-0.2.4d-UTF8-mysql.sql mysql> quit exit Der SQL-Dump sollte nun vollständig in der Datenbank vorliegen. Viel Spaß! Gruß Torsten From rainer.bruch at t-online.de Sat Oct 13 15:25:14 2007 From: rainer.bruch at t-online.de (Rainer Bruch) Date: Sat, 13 Oct 2007 15:25:14 +0200 Subject: [opengeodb] Beispieldaten werden nicht korrekt indieMySQL-Datenbank importiert In-Reply-To: <00d801c80d74$6cc13d30$02a8a8c0@torsten> References: <000501c80d11$e4d8aeb0$152aa8c0@cubeline> <00d801c80d74$6cc13d30$02a8a8c0@torsten> Message-ID: <000001c80d9c$7d648ca0$152aa8c0@cubeline> Hallo Torsten, vielen Dank für Deine schnelle Hilfe. -> Einfach auf der Commandline (Start->Ausführen->cmd) in mysql einloggen. -> C:\xampp\mysql\bin\mysql -u username -p datenbank -> mysql> \. C:\opengeodb-0.2.4d-UTF8-mysql.sql -> Der SQL-Dump sollte nun vollständig in der Datenbank vorliegen. Die gute alte Konsole! Der Dump hat zwar ca. 15 Minuten gedauert (was ich [leider] aus Zeitgründen verhindern wollte), dafür aber einwandfrei geklappt. Hinweis: wegen der Wichtigkeit/Dringlichkeit (ich muß schnellstmöglichst im Kundenauftrag entscheiden, ob OpenGeoDB oder ein kommerzielles System eingesetzt wird), und weil Foren und Mailinglisten sehr oft unterschiedliche Antwortzeiten/Reaktionszeiten haben, hatte ich meine Frage auch im SourceForge Forum platziert. Dies wurde m. E. von Martin Trautmann unberechtigt "aggressiv" gerügt (s. Forum). Info an die Mailingliste: ich wollte keine "Doppelantworten" provozieren, sondern brauchte schnellstmöglichst Unterstützung! Daher Nochmals mein Dank an Torsten. Jetzt kann ich wenigstens mit den Projekttests anfangen. Gruß Rainer From leoleylan at gmx.net Wed Oct 24 10:33:34 2007 From: leoleylan at gmx.net (leoleylan) Date: Wed, 24 Oct 2007 10:33:34 +0200 Subject: [opengeodb] Hierarchies in der Version 0.2.5a Message-ID: <471F035E.1090703@gmx.net> Hallo zusammen! ich bin mir nicht ganz sicher: die OpenGeoDB in der Version 0.2.5a scheint keine Datensätze in der Tabelle hierarchies zu beinhalten. Soll das so sein? Ich möchte z.B. ganz einfach nur die verschiedenen Bundesländer in Deutschland auswählen. Bin bisher ohne hierarchies nur so weit gekommen: SELECT * FROM geodb_locations join geodb_textdata on geodb_locations.loc_id=geodb_textdata.loc_id join geodb_textdata l on l.loc_id = geodb_textdata.loc_id where loc_type = '100300000' and l.text_val = 3 Wie kann ich denn denn mit einer Abfrage ganz simpel die verschiedenen Bundesländer selektieren? Viele Grüße Leo From traut at gmx.de Wed Oct 24 10:55:43 2007 From: traut at gmx.de (Martin Trautmann) Date: Wed, 24 Oct 2007 10:55:43 +0200 Subject: [opengeodb] Hierarchies in der Version 0.2.5a In-Reply-To: <471F035E.1090703@gmx.net> References: <471F035E.1090703@gmx.net> Message-ID: <471F088F.1090408@gmx.de> leoleylan wrote: > Hallo zusammen! > > ich bin mir nicht ganz sicher: die OpenGeoDB in der Version 0.2.5a > > scheint keine Datensätze in der Tabelle hierarchies zu beinhalten. Hallo Leo, es ist richtig: in der aktuellen 0.2.5 sind keine hierarchies enthalten. Zum momentanen Zeitpunkt erscheint es mir unnötig, diese Informationen mit zu übergeben. Im Gegenteil sollten diese automatisch berechnet werden können. Wenn du beispielsweise nach "level" sortierst, kannst du damit direkt die Hierarchies der Ebene oben darüber übernehmen und mit dem eigenen Eintrag ergänzen. Ein einziger Durchlauf sollte genügen, um entsprechend alle hierarchies zu erzeugen. Wenn jemand dieses SQL-Script zur Verfügung stellt, kann ich es mit einbinden oder separat ergänzen. Leider scheint sich bisher niemand die entsprechende Mühe gemacht - entweder, weil es nicht geht, oder weil man darauf wartet, dass ein anderer die eigenen Probleme löst. Im Prinzip könnte ich diese Informationen recht einfach offline erzeugen. Der Aufwand für die aktuelle online-Losung, die NICHT auf SQL aufbaut, erscheint mir aber zu gross. Schönen Gruß Martin From leoleylan at gmx.net Wed Oct 24 11:01:58 2007 From: leoleylan at gmx.net (leoleylan) Date: Wed, 24 Oct 2007 11:01:58 +0200 Subject: [opengeodb] Hierarchies in der Version 0.2.5a In-Reply-To: <471F035E.1090703@gmx.net> References: <471F035E.1090703@gmx.net> Message-ID: <471F0A06.40508@gmx.net> Das ist auch schon gut: SELECT * FROM `geodb_locations` l join geodb_textdata t on l.loc_id=t.loc_id WHERE `loc_type` = 100300000 and text_type = 500100000 Nur wie beschränke ich das ganze noch auf deutsche Bundesländer? Danke und Gruß Leo leoleylan schrieb: > Hallo zusammen! > > ich bin mir nicht ganz sicher: die OpenGeoDB in der Version 0.2.5a > > scheint keine Datensätze in der Tabelle hierarchies zu beinhalten. > Soll das so sein? Ich möchte z.B. ganz einfach nur die verschiedenen > Bundesländer in Deutschland auswählen. > > Bin bisher ohne hierarchies nur so weit gekommen: > > SELECT * FROM geodb_locations join geodb_textdata on > geodb_locations.loc_id=geodb_textdata.loc_id join geodb_textdata l on > l.loc_id = geodb_textdata.loc_id where loc_type = '100300000' and > l.text_val = 3 > > Wie kann ich denn denn mit einer Abfrage ganz simpel die verschiedenen > Bundesländer selektieren? > > Viele Grüße > Leo > From leoleylan at gmx.net Fri Oct 26 00:15:07 2007 From: leoleylan at gmx.net (leoleylan) Date: Fri, 26 Oct 2007 00:15:07 +0200 Subject: [opengeodb] Hierarchies in der Version 0.2.5a In-Reply-To: <471F088F.1090408@gmx.de> References: <471F035E.1090703@gmx.net> <471F088F.1090408@gmx.de> Message-ID: <4721156B.5040903@gmx.net> Auf dieser Mailingliste sind doch sicher SQL-Freunde die wissen wie man aus OpenGeoDB einfach sämtliche _deutschen_ Bundesländernamen selektiert (?) Martin: hast Du einen Überblick darüber wieviele Leute z.Zt. auf dieser Liste sind? Danke & Gruß Leo > leoleylan wrote: > >> Hallo zusammen! >> >> ich bin mir nicht ganz sicher: die OpenGeoDB in der Version 0.2.5a >> >> scheint keine Datensätze in der Tabelle hierarchies zu beinhalten. >> > > Hallo Leo, > > es ist richtig: in der aktuellen 0.2.5 sind keine hierarchies enthalten. > > Zum momentanen Zeitpunkt erscheint es mir unnötig, diese Informationen > mit zu übergeben. Im Gegenteil sollten diese automatisch berechnet > werden können. > > Wenn du beispielsweise nach "level" sortierst, kannst du damit direkt > die Hierarchies der Ebene oben darüber übernehmen und mit dem eigenen > Eintrag ergänzen. Ein einziger Durchlauf sollte genügen, um entsprechend > alle hierarchies zu erzeugen. > > Wenn jemand dieses SQL-Script zur Verfügung stellt, kann ich es mit > einbinden oder separat ergänzen. Leider scheint sich bisher niemand die > entsprechende Mühe gemacht - entweder, weil es nicht geht, oder weil man > darauf wartet, dass ein anderer die eigenen Probleme löst. > > Im Prinzip könnte ich diese Informationen recht einfach offline > erzeugen. Der Aufwand für die aktuelle online-Losung, die NICHT auf SQL > aufbaut, erscheint mir aber zu gross. > > Schönen Gruß > Martin > From traut at gmx.de Fri Oct 26 00:20:00 2007 From: traut at gmx.de (Martin Trautmann) Date: Fri, 26 Oct 2007 00:20:00 +0200 Subject: [opengeodb] Hierarchies in der Version 0.2.5a In-Reply-To: <4721156B.5040903@gmx.net> References: <471F035E.1090703@gmx.net> <471F088F.1090408@gmx.de> <4721156B.5040903@gmx.net> Message-ID: <47211690.9010503@gmx.de> leoleylan wrote: > Martin: hast Du einen Überblick darüber wieviele Leute z.Zt. auf dieser > Liste sind? Nein From georg at familieverweyen.de Sun Oct 28 14:03:11 2007 From: georg at familieverweyen.de (Georg Verweyen) Date: Sun, 28 Oct 2007 14:03:11 +0100 Subject: [opengeodb] SQL-Statement Message-ID: <4724888F.5030305@familieverweyen.de> Hallo zusammen, ja es gibt SQL-Kenner in der Liste, aber nicht alle habe akut Zeit. Hier ist das gewünschte SQL-Statement SELECT * FROM geodb_locations l, geodb_textdata t, geodb_textdata t2 WHERE l.loc_id=t.loc_id AND l.loc_id=t2.loc_id AND loc_type = 100300000 AND t.text_type = 500100000 AND t2.text_type = 400100000 AND t2.text_val = 105; Es werden alle Texte gesucht, die zusätzlich als Vorgänger die Bundesrepublik Deutschland (loc_id=105) besitzen. MfG Georg V. -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20071028/716c003a/attachment.html From gemander at gmx.net Mon Oct 29 06:38:42 2007 From: gemander at gmx.net (Gemander, Ronny) Date: Mon, 29 Oct 2007 06:38:42 +0100 Subject: [opengeodb] SQL-Statement In-Reply-To: <4724888F.5030305@familieverweyen.de> References: <4724888F.5030305@familieverweyen.de> Message-ID: <472571E2.4020101@gmx.net> Mir liefert das query nach 0,0010 sek ein leeres Resultat. Aber kann sein, dass ich grad nicht die aktuelle Version besitze. Aber trotzdem danke für die Arbeit. Georg Verweyen schrieb: > Hallo zusammen, > > ja es gibt SQL-Kenner in der Liste, aber nicht alle habe akut Zeit. Hier > ist das gewünschte SQL-Statement > > SELECT * > FROM geodb_locations l, > geodb_textdata t, > geodb_textdata t2 > WHERE l.loc_id=t.loc_id > AND l.loc_id=t2.loc_id > AND loc_type = 100300000 > AND t.text_type = 500100000 > AND t2.text_type = 400100000 > AND t2.text_val = 105; > > Es werden alle Texte gesucht, die zusätzlich als Vorgänger die > Bundesrepublik Deutschland (loc_id=105) besitzen. > > MfG Georg V. > From prolog at jumbosoft.de Mon Oct 29 06:52:16 2007 From: prolog at jumbosoft.de (IMAPRH/privat) Date: Mon, 29 Oct 2007 06:52:16 +0100 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_f=FCr_MacOSX_Anwender=3F?= In-Reply-To: <472571E2.4020101@gmx.net> References: <4724888F.5030305@familieverweyen.de> <472571E2.4020101@gmx.net> Message-ID: Hallo, ich lese diese Liste schon eine ganze Weile und frage mich, ob es noch andere Aanwender gibt, die auf MacOSX arbeiten (Leopard oder Tiger). Wenn ja, mit welchen Mitteln greift man von MacOSX auf OpenGeoDB zu? Im Moment ist mir das schleierhaft. Grüsse, Ronald Hofmann --- From traut at gmx.de Mon Oct 29 07:46:34 2007 From: traut at gmx.de (Martin Trautmann) Date: Mon, 29 Oct 2007 07:46:34 +0100 Subject: [opengeodb] =?iso-8859-1?q?OpenGeoDB_f=FCr_MacOSX_Anwender=3F?= In-Reply-To: References: <4724888F.5030305@familieverweyen.de> <472571E2.4020101@gmx.net> Message-ID: <472581CA.7090906@gmx.de> IMAPRH/privat wrote: > Hallo, > ich lese diese Liste schon eine ganze Weile und frage mich, ob es noch > andere Aanwender gibt, die auf MacOSX arbeiten (Leopard oder Tiger). > Wenn ja, mit welchen Mitteln greift man von MacOSX auf OpenGeoDB zu? > Im Moment ist mir das schleierhaft. Du hast unter OSX ähnliche Möglichkeiten wie unter jedem anderen System. Entwickelt wurde fa-technik.adfc.de/code/opengeodb.pl auf dem Mac - da ist alles dafür nötige schon vorinstalliert (und das ist nicht der Grund, warm ich im Moment Umlaut-Probleme habe). Zum Datenabgleich bzw. als eigene Datenbank halte ich die opengeodb in FileMaker. MySQL ist aber auch für OSX verfügbar, wie all die meisten anderen Linux-Programme. Schönen Gruß Martin From leoleylan at gmx.net Mon Oct 29 10:45:28 2007 From: leoleylan at gmx.net (leoleylan) Date: Mon, 29 Oct 2007 10:45:28 +0100 Subject: [opengeodb] SQL-Statement In-Reply-To: <4724888F.5030305@familieverweyen.de> References: <4724888F.5030305@familieverweyen.de> Message-ID: <4725ABB8.9040202@gmx.net> Hallo Georg, vielen Dank für Deine Hilfe! @Gemander: Mit der neuen Version klappt das einwandfrei. Beste Grüße Leo Georg Verweyen schrieb: > Hallo zusammen, > > ja es gibt SQL-Kenner in der Liste, aber nicht alle habe akut Zeit. > Hier ist das gewünschte SQL-Statement > > SELECT * FROM geodb_locations l, > geodb_textdata t, > geodb_textdata t2 > WHERE l.loc_id=t.loc_id > AND l.loc_id=t2.loc_id > AND loc_type = 100300000 > AND t.text_type = 500100000 > AND t2.text_type = 400100000 > AND t2.text_val = 105; > > Es werden alle Texte gesucht, die zusätzlich als Vorgänger die > Bundesrepublik Deutschland (loc_id=105) besitzen. > > MfG Georg V. > From georg at familieverweyen.de Mon Oct 29 21:24:59 2007 From: georg at familieverweyen.de (Georg V.) Date: Mon, 29 Oct 2007 21:24:59 +0100 Subject: [opengeodb] Neu Version vom infoOGDB-Script Message-ID: Hallo zusammen, die neuste Version des Scriptes ist zu den Interessenten zum Testen rausgegangen. Allerdings zeigt diese Script auch direkt (weitere) Schwächen in der Datenlage: Europa besteht aus Belgique (ja diese "deutsche" Bezeichnung von Belgien hat auch den Default-Bezeichner erhalten), Bundesrepublik Deutschland und Liechtenstein (es fehlen Österreich, Schweiz und Liechtenstein [zumindestens sind diese auf dem nächsten Level vorhanden]). Ein kleiner Check zeigt, das bei den LOC_ID's -1, 0 (okay), 100, 101, 102, 103, 104 (Erdteile, man könnte ein Welt auf Level 0 definieren) und 18048, 35793 (klare Fehler) der Eintrag des Vorgängers fehlt. Des weiteren fehlt bei -1, 0 (s.o.), 100, 101, 102, 103, 104 (s.o.), 106, 107 und 35698 die Levelangabe. Oder ganz deutlich gefragt: Wann kommt denn die Version 0.2.5b heraus? Mit diesen Aufschlag kann man kaum einen zum Wechseln bewegen. MfG Georg V. From traut at gmx.de Tue Oct 30 12:30:46 2007 From: traut at gmx.de (genabbelt) Date: Tue, 30 Oct 2007 04:30:46 -0700 (PDT) Subject: [opengeodb] Neu Version vom infoOGDB-Script In-Reply-To: References: Message-ID: <13486707.post@talk.nabble.com> > Oder ganz deutlich gefragt: Wann kommt denn die Version 0.2.5b heraus? Mit diesen Aufschlag kann man kaum einen zum Wechseln bewegen. Hallo Georg, hast du denn online die Fehler schon korrigiert? Ich selbst beschaeftige mich derzeit eher damit, dass man auch die Extra-Angaben bearbeiten kann. Ich glaube, Fehlerkorrekturen an den Daten koennen die Benutzer am besten selbst vornehmen. um die Arbeit auf moeglichst viele Schultern zu verteilen. Schoenen Gruss Martin -- View this message in context: http://www.nabble.com/Neu-Version-vom-infoOGDB-Script-tf4717850.html#a13486707 Sent from the Php German - opengeodb mailing list archive at Nabble.com. -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20071030/62957ec6/attachment.html From traut at gmx.de Tue Oct 30 12:32:07 2007 From: traut at gmx.de (genabbelt) Date: Tue, 30 Oct 2007 04:32:07 -0700 (PDT) Subject: [opengeodb] Neu Version vom infoOGDB-Script In-Reply-To: References: Message-ID: <13486707.post@talk.nabble.com> (Wiederholung ohne HTML) > Oder ganz deutlich gefragt: Wann kommt denn die Version 0.2.5b heraus? Mit > diesen Aufschlag kann man kaum einen zum Wechseln bewegen. Hallo Georg, hast du denn online die Fehler schon korrigiert? Ich selbst beschaeftige mich derzeit eher damit, dass man auch die Extra-Angaben bearbeiten kann. Ich glaube, Fehlerkorrekturen an den Daten koennen die Benutzer am besten selbst vornehmen. um die Arbeit auf moeglichst viele Schultern zu verteilen. Schoenen Gruss Martin -- View this message in context: http://www.nabble.com/Neu-Version-vom-infoOGDB-Script-tf4717850.html#a13486707 Sent from the Php German - opengeodb mailing list archive at Nabble.com. From freegoldcart at web.de Tue Oct 30 13:57:50 2007 From: freegoldcart at web.de (goldkart) Date: Tue, 30 Oct 2007 13:57:50 +0100 Subject: [opengeodb] kostenlose Emailwerbung versenden Message-ID: Ja Sie haben richtig gelesen !! Völlig kostenlos Emails versenden ! Stellen Sie sich vor ein neuer Paidmailer geht Online und Sie könnten an unzählige Intressenten ein Mail mit Ihrem Reflink schicken. Woanders müsstest Sie für diese Art von Werbung viel Geld ausgeben ! http://www.werbemail.speedpage.de/ HOHE PROVISIONEN FÜR PARTNERPROGRAMMME BIS ZU 50% kostenllos und ohne viel Aufwand Geld im Internet mit der eigenen Hompage verdienen http://www.partnerprogramm.speedpage.de