From traut at gmx.de Thu Jan 3 11:18:09 2008 From: traut at gmx.de (Martin Trautmann) Date: Thu, 03 Jan 2008 11:18:09 +0100 Subject: [opengeodb] =?iso-8859-1?q?Ortsteile_von_Baden-W=FCrttemberg?= Message-ID: <20080103101809.86640@gmx.net> Hallo, als ersten Versuchsballon habe ich einmal eine Fuelle von Ortsteilen von Baden-Wuerttemberg aufgenommen. Das dient der Vorbereitung zu den zugehoerigen Strassennamen, abgeleitet aus der openstreetmap Es sind damit etwa 6000 Ortsteilbezeichnungen hinzugekommen - abrufbar ueber http://fa-technik.adfc.de/code/opengeodb/ D.tab oder D.sql In Kuerze werden sich noch 18 000 Strassen hinzugesellen - also fast ein Zehntel der Strassen aus BW. Dass in der ASCII-Schreibweise der Umlaut Ä / AE verlorenging, ist bekannt und wird im naechsten Update behoben. Ansonsten funktionieren dank Detlefs Unterstuetzung nun die UTF8-Sonderzeichen endlich so, wie sie sollen... Ich waere fuer ein paar erste Tests und Pruefungen dankbar, um zu wissen, was wir noch zur release-Wuerdigkeit verbessern muessen. Schoenen Gruss Martin -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10 -- 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 traut at gmx.de Thu Jan 3 22:07:39 2008 From: traut at gmx.de (Martin Trautmann) Date: Thu, 03 Jan 2008 22:07:39 +0100 Subject: [opengeodb] =?iso-8859-1?q?Stra=DFen_von_Baden-W=FCrttemberg?= In-Reply-To: <20080103101809.86640@gmx.net> References: <20080103101809.86640@gmx.net> Message-ID: <477D4E9B.4020703@gmx.de> Martin Trautmann wrote: > Hallo, > > als ersten Versuchsballon habe ich einmal eine Fuelle von Ortsteilen > von Baden-Wuerttemberg aufgenommen. Das dient der Vorbereitung zu den > zugehoerigen Strassennamen, abgeleitet aus der openstreetmap Nun habe ich erstmalig die Strassen hinzugefügt. Der SQL-Dump wächst damit für Deutschland allein auf 42 MB an - und das bei bisher 18 000 Straßen aus Baden-Württemberg, was einem Zehntel des aktuellen Bestandes von BW und einem Hunderstel von D entspricht. Leute, ist das für euch noch interessant und handhabbar? Bitte probiert es einmal aus: http://fa-technik.adfc.de/code/opengeodb/dump/D.sql.bz2 (komprimiert: 1.6 MB) Schönen Gruß Martin From gemander at gmx.net Fri Jan 4 09:49:37 2008 From: gemander at gmx.net (Gemander, Ronny) Date: Fri, 04 Jan 2008 09:49:37 +0100 Subject: [opengeodb] =?iso-8859-1?q?Stra=DFen_von_Baden-W=FCrttemberg?= In-Reply-To: <477D4E9B.4020703@gmx.de> References: <20080103101809.86640@gmx.net> <477D4E9B.4020703@gmx.de> Message-ID: <477DF321.6000508@gmx.net> Martin Trautmann schrieb: > Martin Trautmann wrote: >> Hallo, Hallo Martin, >> >> als ersten Versuchsballon habe ich einmal eine Fuelle von Ortsteilen >> von Baden-Wuerttemberg aufgenommen. Das dient der Vorbereitung zu den >> zugehoerigen Strassennamen, abgeleitet aus der openstreetmap > > Nun habe ich erstmalig die Strassen hinzugefügt. > > Der SQL-Dump wächst damit für Deutschland allein auf 42 MB an - und das > bei bisher 18 000 Straßen aus Baden-Württemberg, was einem Zehntel des > aktuellen Bestandes von BW und einem Hunderstel von D entspricht. > > Leute, ist das für euch noch interessant und handhabbar? Ich denke, interessant ist es für das eine oder andere Projekt schon, vor allem, wenn vielleicht mal deutschlandweit eine bestimmter Prozentsatz an Daten vorhanden ist. Für die meisten Projekte reicht imho allerdings die PLZ Ebene aus. Vielleicht kann man die Daten ja dahingehend splitten, dass die Strassen eine eigene sql/tab Datei darstellen. > > Bitte probiert es einmal aus: > > http://fa-technik.adfc.de/code/opengeodb/dump/D.sql.bz2 (komprimiert: > 1.6 MB) > > Schönen Gruß > Martin Gruß, Ronny From sn at heise.de Fri Jan 4 10:09:27 2008 From: sn at heise.de (Sven Neuhaus) Date: Fri, 04 Jan 2008 10:09:27 +0100 Subject: [opengeodb] =?iso-8859-1?q?Stra=DFen_von_Baden-W=FCrttemberg?= In-Reply-To: <477D4E9B.4020703@gmx.de> References: <20080103101809.86640@gmx.net> <477D4E9B.4020703@gmx.de> Message-ID: <477DF7C7.9060702@heise.de> Martin Trautmann schrieb: >> als ersten Versuchsballon habe ich einmal eine Fuelle von Ortsteilen >> von Baden-Wuerttemberg aufgenommen. Das dient der Vorbereitung zu den >> zugehoerigen Strassennamen, abgeleitet aus der openstreetmap > > Nun habe ich erstmalig die Strassen hinzugefügt. [...] > Leute, ist das für euch noch interessant und handhabbar? Unter welcher Lizenz gibt es die Strassendaten bei openstreetmap? Vermutlich nicht public domain wie opengeodb? Eine Version von opengeodb, die diese Daten enthält, müsste dann auch nur unter anderer Lizenz verbreitet werden. Abgesehen davon halte ich Strassendaten für eine spannende Erweiterung. Gruss, -Sven From traut at gmx.de Fri Jan 4 10:39:21 2008 From: traut at gmx.de (Martin Trautmann) Date: Fri, 4 Jan 2008 01:39:21 -0800 (PST) Subject: [opengeodb] =?utf-8?q?Stra=C3=9Fen_von_Baden-W=C3=BCrttemberg?= In-Reply-To: <477DF7C7.9060702@heise.de> References: <20080103101809.86640@gmx.net> <477D4E9B.4020703@gmx.de> <477DF7C7.9060702@heise.de> Message-ID: <14613263.post@talk.nabble.com> Sven Neuhaus wrote: > > Unter welcher Lizenz gibt es die Strassendaten bei openstreetmap? > Vermutlich > nicht public domain wie opengeodb? Eine Version von opengeodb, die diese > Daten enthält, müsste dann auch nur unter anderer Lizenz verbreitet > werden. > Richtig, die Daten aus der OpenStreetMap stehen unter einer Creative Commons Attribution-ShareAlike 2.0. http://wiki.openstreetmap.org/index.php/Legal_FAQ Im Moment verwende ich noch keine Daten aus der OSM direkt - juristisch ist es sicherlich eine Gratwanderung. Faktisch waere es extrem schwierig, bei jeder einzelnen Strasse, die ich direkt uebernehmen wuerde, hinzuzufuegen, wer der owner/Autor ist bzw. dessen Zustimmung zur Freigabe in der opengeodb zu erhalten. Ich kann mir nicht vorstellen, dass die opengeodb komplett OSM-Daten unter der bisherigen Lizenz einbinden duerfte - auf dem Umweg wuerde ja der Lizenzschutz der OSM-Daten aufgehoben werden. Ich kann mir vorstellen, dass wir als irgendwie geartete derived work einen besonderen Partnerstatus bekommen koennten, wo die abgeleiteten Daten Verwendung finden koennten. Ich kann mir auch vorstellen, dass ich die Strassen-Daten in einen anderen Teil-Dump einbringen wuerde, der der CC-BySa untergeordnet wuerde. Das erscheint mir derzeit am angemessensten. Schoenen Gruss Martin -- View this message in context: http://www.nabble.com/Ortsteile-von-Baden-W%C3%BCrttemberg-tp14594641p14613263.html Sent from the Php German - opengeodb mailing list archive at Nabble.com. From 922492 at gmx.de Wed Jan 9 16:15:26 2008 From: 922492 at gmx.de (Sascha Mantscheff) Date: Wed, 09 Jan 2008 16:15:26 +0100 Subject: [opengeodb] Welche Version ist die richtige? Message-ID: <4784E50E.1090405@gmx.de> Guten Tag, soeben habe ich eine Version der OpenGeoDB von sourceforge geladen, bin dann auf einige Mängel und Ungereimtheiten gestossen und dann auf eine Fassung auf dem ADFC-Server (auf die mich aber lediglich ein Hinweis in der Mailing-Liste führte). So habe ich folgende Fragen: - Gibt es eine aktuellere Version als die von ADFC? - Gibt es eine "offizielle" Fassung, die weiter entwickelt und gepflegt wird? Im Übrigen besten Dank an die Autoren und Datensammler für diese Arbeit. s.m. From traut at gmx.de Wed Jan 9 17:21:04 2008 From: traut at gmx.de (Martin Trautmann) Date: Wed, 9 Jan 2008 08:21:04 -0800 (PST) Subject: [opengeodb] Welche Version ist die richtige? In-Reply-To: <4784E50E.1090405@gmx.de> References: <4784E50E.1090405@gmx.de> Message-ID: <14715285.post@talk.nabble.com> Sascha Mantscheff wrote: > > Guten Tag, > > soeben habe ich eine Version der OpenGeoDB von sourceforge geladen, bin > dann auf einige Mängel und Ungereimtheiten gestossen und dann auf eine > Fassung auf dem ADFC-Server (auf die mich aber lediglich ein Hinweis in > der Mailing-Liste führte). So habe ich folgende Fragen: > - Gibt es eine aktuellere Version als die von ADFC? > jede davon abgeleitete, wie z.B. deine eigene kann aktueller sein. Im Moment ist aber die ADFC-Version die Referenz. > - Gibt es eine "offizielle" Fassung, die weiter entwickelt und gepflegt > wird? > genau jene ist die "offizielle" von der immer wieder releases fuer sourceforge abgeleitet werden. Schoenen Gruss Martin -- View this message in context: http://www.nabble.com/Welche-Version-ist-die-richtige--tp14713998p14715285.html Sent from the Php German - opengeodb mailing list archive at Nabble.com. From 922492 at gmx.de Wed Jan 9 18:27:34 2008 From: 922492 at gmx.de (Sascha Mantscheff) Date: Wed, 09 Jan 2008 18:27:34 +0100 Subject: [opengeodb] Welche Version ist die richtige? In-Reply-To: <14715285.post@talk.nabble.com> References: <4784E50E.1090405@gmx.de> <14715285.post@talk.nabble.com> Message-ID: <47850406.6060201@gmx.de> Besten Dank für die Auskunft. Zusatzfragen: 1) In der ADFC-Fassung fehlen die type_names. Hat das einen tieferen Sinn? 2) In der offenbar älteren sourceforge-Fassung sind zwar type_names, hier fehlt aber loc_type=500100000. Gibt es dafür einen einleuchtenden Grund? 3) In der sourceforge-Fassung werden die Tabellen zwar vom Typ InnoDB deklariert, es werden jedoch keine foreign keys deklariert, die solche Fehler wie fehlende Typnamen vermeiden helfen würden. Was ist die Überlegung dahinter? Im übrigen werde ich meine DB, wenn die genannten Mängel korrigiert sind, gerne zur Verfügung stellen. Gibt es dafür ein Procedere? s.m. Martin Trautmann schrieb: > Sascha Mantscheff wrote: > >> Guten Tag, >> >> soeben habe ich eine Version der OpenGeoDB von sourceforge geladen, bin >> dann auf einige Mängel und Ungereimtheiten gestossen und dann auf eine >> Fassung auf dem ADFC-Server (auf die mich aber lediglich ein Hinweis in >> der Mailing-Liste führte). So habe ich folgende Fragen: >> - Gibt es eine aktuellere Version als die von ADFC? >> >> > > jede davon abgeleitete, wie z.B. deine eigene kann aktueller sein. Im Moment > ist aber die ADFC-Version die Referenz. > > > > >> - Gibt es eine "offizielle" Fassung, die weiter entwickelt und gepflegt >> wird? >> >> > > genau jene ist die "offizielle" von der immer wieder releases fuer > sourceforge abgeleitet werden. > > Schoenen Gruss > Martin > From k.weinert at gmx.net Wed Jan 9 18:30:23 2008 From: k.weinert at gmx.net (Karsten Weinert) Date: Wed, 9 Jan 2008 18:30:23 +0100 Subject: [opengeodb] [ANN:] kwLuftlinie: Entfernung zwischen 2 Postleitzahlgebieten In-Reply-To: References: Message-ID: Hallo! kwLuftlinie ist ein Excel-Add-In. Es stellt Ihnen eine Zusatz-Funktion LUFTLINIE zur Verfügung, mit dessen Hilfe Sie schnell Entfernungsdaten zwischen zwei Postleitzahlgebieten (in Deutschland) ermitteln können. Anwendungsfälle sind Entfernungstabellen, Umkreissuche, Lieferkostenkalkulation, Tourenplanung u.v.A. Das Add-in ist freie Software (GPL). http://kwluftlinie.sf.net Freundliche Grüße, Karsten. From andi at saerdnaer.de Wed Jan 9 18:37:54 2008 From: andi at saerdnaer.de (Andreas Hubel) Date: Wed, 9 Jan 2008 18:37:54 +0100 Subject: [opengeodb] Welche Version ist die richtige? In-Reply-To: <47850406.6060201@gmx.de> References: <4784E50E.1090405@gmx.de> <14715285.post@talk.nabble.com> <47850406.6060201@gmx.de> Message-ID: Naja, die Sache mit den type und layer ist momentan irgendwie Redundant. Ich wäre dafür das layer und type irgendwie vereinigt wird. MfG Andreas Hubel From 922492 at gmx.de Wed Jan 9 19:26:18 2008 From: 922492 at gmx.de (Sascha Mantscheff) Date: Wed, 09 Jan 2008 19:26:18 +0100 Subject: [opengeodb] DB-Versionen, geodb_hierarchies, geodb_type_names und Ungereimtheiten Message-ID: <478511CA.3070104@gmx.de> Da ich gerade erst anfange, mich mit dieser DB zu beschäftigen, stosse ich auf einige Unklarheiten. Ich bitte, dumme Fragen zu entschuldigen, aber trotzdem zu beantworten. An DB-Versionen liegen mir vor eine Fassung von sourceforge (opengeodb-0.2.5a-UTF8-sql, "SF") und eine Fassung des ADFC (D.sql, "ADFC"). "ADFC" scheint vollständiger und umfangreicher. Hier fehlen jedoch die Inhalte der Tabellen hierarchies und type_names. "SF" enthält type_names mit Inhalten und die Tabellenstruktur für hierarchies, jedoch keine Werte dafür. type_names ist unvollständig (d.h. es fehlen Werte, die in im Feld loc_type vorkommen). In der Dokumentation auf sourceforge (Stand 2005) wird behauptet, type_names sei einstweilen unwichtig. Nach den mir vorliegenden Daten scheint das Gegenteil der Fall. Oder gibt es auch einen öffentlich zugänglichen Datenbestand, in dem die Tabelle hierarchies gefüllt ist und der weiter gepflegt wird? s.m. From traut at gmx.de Wed Jan 9 21:16:26 2008 From: traut at gmx.de (Martin Trautmann) Date: Wed, 09 Jan 2008 21:16:26 +0100 Subject: [opengeodb] Welche Version ist die richtige? In-Reply-To: <47850406.6060201@gmx.de> References: <4784E50E.1090405@gmx.de> <14715285.post@talk.nabble.com> <47850406.6060201@gmx.de> Message-ID: <47852B9A.7020001@gmx.de> Sascha Mantscheff wrote: > Besten Dank für die Auskunft. Zusatzfragen: > > 1) In der ADFC-Fassung fehlen die type_names. Hat das einen tieferen Sinn? Welche Version hast du angesehen? In den SQL-Daten sind sie enthalten. Wenn sie bei dir fehlen, ging vielleicht irgendwas davor schief? > 2) In der offenbar älteren sourceforge-Fassung sind zwar type_names, > hier fehlt aber loc_type=500100000. Gibt es dafür einen einleuchtenden > Grund? Du sprichst von 0.2.5? Nein, es gibt keinen Grund, warum 500100000 fehlen sollte. > 3) In der sourceforge-Fassung werden die Tabellen zwar vom Typ InnoDB > deklariert, es werden jedoch keine foreign keys deklariert, die solche > Fehler wie fehlende Typnamen vermeiden helfen würden. Was ist die > Überlegung dahinter? Das sollten SQL-Experten beantworten, ich selbst brauche das nicht. > Im übrigen werde ich meine DB, wenn die genannten Mängel korrigiert > sind, gerne zur Verfügung stellen. Gibt es dafür ein Procedere? Wenn du Daten bereitstellen kannst, solltest du sie z.B. auf fa-technik wieder einspielen. Wenn du Änderungen an der Datenstruktur hast, solltest du sie hier diskutieren. Wenn du Fehler in der SQL-Syntax findest, solltest du sie hier oder mir schreiben, damit sie beim nächsten dump behoben werden können. Schönen Gruß Martin From traut at gmx.de Wed Jan 9 21:23:23 2008 From: traut at gmx.de (Martin Trautmann) Date: Wed, 09 Jan 2008 21:23:23 +0100 Subject: [opengeodb] DB-Versionen, geodb_hierarchies, geodb_type_names und Ungereimtheiten In-Reply-To: <478511CA.3070104@gmx.de> References: <478511CA.3070104@gmx.de> Message-ID: <47852D3B.2020704@gmx.de> Sascha Mantscheff wrote: > Da ich gerade erst anfange, mich mit dieser DB zu beschäftigen, stosse > ich auf einige Unklarheiten. Ich bitte, dumme Fragen zu entschuldigen, > aber trotzdem zu beantworten. > > An DB-Versionen liegen mir vor eine Fassung von sourceforge > (opengeodb-0.2.5a-UTF8-sql, "SF") und eine Fassung des ADFC (D.sql, "ADFC"). > > "ADFC" scheint vollständiger und umfangreicher. Hier fehlen jedoch die > Inhalte der Tabellen hierarchies und type_names. hierarchies sind derzeit nicht mehr enthalten, weil IMHO nicht erforderlich und aufwändig zu pflegen. Ich vermisse hier aber noch immer einen SQL-Ansatz, wie diese automatisch abgeleitet werden könnten. Daher habe ich für den Dump auch mal eingerichtet, dass die hiearchies neu erstellt werden und habe http://fa-technik.adfc.de/code/opengeodb/Dhier.sql usw. erzeugt. Bisher habe ich aber keine Rückmeldung, ob das irgendwie brauchbar ist. > "SF" enthält type_names mit Inhalten und die Tabellenstruktur für > hierarchies, jedoch keine Werte dafür. type_names ist unvollständig > (d.h. es fehlen Werte, die in im Feld loc_type vorkommen). Mit genauen Angaben lässt sich korrigieren, was so unklar im Raum steht. > In der Dokumentation auf sourceforge (Stand 2005) wird behauptet, > type_names sei einstweilen unwichtig. > Oder gibt es auch einen öffentlich > zugänglichen Datenbestand, in dem die Tabelle hierarchies gefüllt ist > und der weiter gepflegt wird? s.o. - die hierarchies sind aber nur abgeleitete, redundante Daten, die automatisch erstellt werden sollten. Schönen Gruß Martin From 922492 at gmx.de Thu Jan 10 09:52:49 2008 From: 922492 at gmx.de (Sascha Mantscheff) Date: Thu, 10 Jan 2008 09:52:49 +0100 Subject: [opengeodb] DB-Versionen, geodb_hierarchies, geodb_type_names und Ungereimtheiten In-Reply-To: <47852D3B.2020704@gmx.de> References: <478511CA.3070104@gmx.de> <47852D3B.2020704@gmx.de> Message-ID: <4785DCE1.3080608@gmx.de> Besten Dank. Martin Trautmann schrieb: > Sascha Mantscheff wrote: > >> Da ich gerade erst anfange, mich mit dieser DB zu beschäftigen, stosse >> ich auf einige Unklarheiten. Ich bitte, dumme Fragen zu entschuldigen, >> aber trotzdem zu beantworten. >> >> An DB-Versionen liegen mir vor eine Fassung von sourceforge >> (opengeodb-0.2.5a-UTF8-sql, "SF") und eine Fassung des ADFC (D.sql, "ADFC"). >> >> "ADFC" scheint vollständiger und umfangreicher. Hier fehlen jedoch die >> Inhalte der Tabellen hierarchies und type_names. >> > > hierarchies sind derzeit nicht mehr enthalten, weil IMHO nicht > erforderlich und aufwändig zu pflegen. > > Ich vermisse hier aber noch immer einen SQL-Ansatz, wie diese > automatisch abgeleitet werden könnten. > Dazu wären die Skripte bzw. das Verfahren hilfreich, nach dem die von Dir genannte Hiearchietabelle erzeugt wurde. > Daher habe ich für den Dump auch mal eingerichtet, dass die hiearchies > neu erstellt werden und habe > http://fa-technik.adfc.de/code/opengeodb/Dhier.sql usw. > erzeugt. Bisher habe ich aber keine Rückmeldung, ob das irgendwie > brauchbar ist. > Was heisst usw.? Gibt es da noch mehr? - Im übrigen ist natürlich richtig, dass der Grunddatenbestand keine abgeleiteten Daten enthalten sollte. >> "SF" enthält type_names mit Inhalten und die Tabellenstruktur für >> hierarchies, jedoch keine Werte dafür. type_names ist unvollständig >> (d.h. es fehlen Werte, die in im Feld loc_type vorkommen). >> > > Mit genauen Angaben lässt sich korrigieren, was so unklar im Raum steht. > Es fehlen die type_names: +-----------+ | loc_type | +-----------+ | 100900000 | | 610000000 | | 500100000 | +-----------+ Gefunden mit: select distinct (loc_type) from geodb_locations l left join geodb_type_names t on l.loc_type=t.type_id where t.type_id is null union select distinct (coord_type) from geodb_coordinates c left join geodb_type_names t on c.coord_type=t.type_id where t.type_id is null union select distinct (float_type) from geodb_floatdata f left join geodb_type_names t on f.float_type=t.type_id where t.type_id is null union select distinct (int_type) from geodb_intdata f left join geodb_type_names t on f.int_type=t.type_id where t.type_id is null union select distinct (text_type) from geodb_textdata f left join geodb_type_names t on f.text_type=t.type_id where t.type_id is null >> > 3) In der sourceforge-Fassung werden die Tabellen zwar vom Typ InnoDB >> > deklariert, es werden jedoch keine foreign keys deklariert, die solche >> > Fehler wie fehlende Typnamen vermeiden helfen würden. Was ist die >> > Überlegung dahinter? >> > > Das sollten SQL-Experten beantworten, ich selbst brauche das nicht. > Es würde zwar bei Inserts und Updates die Performance beeinträchtigen, aber die Datenintegrität erhöhen. Wo immer es möglich ist, empfehle ich, Relationen zwischen Tabellen mit Foreign-Key-Constraints abzusichern. > >> > Im übrigen werde ich meine DB, wenn die genannten Mängel korrigiert >> > sind, gerne zur Verfügung stellen. Gibt es dafür ein Procedere? >> > > Wenn du Daten bereitstellen kannst, solltest du sie z.B. auf fa-technik > wieder einspielen. > > Wenn du Änderungen an der Datenstruktur hast, solltest du sie hier > diskutieren. > Neben der oben empfohlenen Einführung von Foreign Keys schlage ich vor, alle Feldbezeichnungen so zu vereinheitlichen, dass Referenzen auf identische Felder identische Namen haben. Zur Zeit gibt es (siehe Union-Abfrage oben) diverse Felder namens ..._type, die alle dasselbe meinen, nämlich eine Referenz auf die Tabelle type_names. Im übrigen verstehe ich zwar einerseits die Anlage der Wertetabellen für atomare Typen wie float, int, text und die Flexibilität, die damit erzielt wird. Andererseits kommt mir die Struktur, die offenbar bis etwa 2005 gepflegt wurde, wesentlich einleuchtender vor. Die künstliche Trennung von Primärschlüssel (loc_id) und Attributen und deren Aufspaltung in typorientierte Tabellen kommt mir unter den Aspekten der Datenpflege und der Programmierung eher kontraproduktiv vor. Was war denn ausschlaggebend für diese Umstrukturierung? Gruss s.m. From traut at gmx.de Thu Jan 10 10:40:39 2008 From: traut at gmx.de (Martin Trautmann) Date: Thu, 10 Jan 2008 01:40:39 -0800 (PST) Subject: [opengeodb] DB-Versionen, geodb_hierarchies, geodb_type_names und Ungereimtheiten In-Reply-To: <4785DCE1.3080608@gmx.de> References: <478511CA.3070104@gmx.de> <47852D3B.2020704@gmx.de> <4785DCE1.3080608@gmx.de> Message-ID: <14730649.post@talk.nabble.com> On 2008-01-10 09:52, Sascha Mantscheff wrote: >> Ich vermisse hier aber noch immer einen SQL-Ansatz, wie diese >> automatisch abgeleitet werden könnten. >> > Dazu wären die Skripte bzw. das Verfahren hilfreich, nach dem die von > Dir genannte Hiearchietabelle erzeugt wurde. Bist du sicher, dass die dir helfen würden? sub create_hierarchies { my ($country) = @_; my $dpath = "opengeodb"; my $dfile = $dpath."/".$country.".tab"; my $hfile = $dpath."/".$country."hier.sql"; my $i=0; my $hid; my $hlevel; my $hof; my $mylevel=1; my $hier0="0\t104"."\t0" x 8; my %hier; my ($key,$value); while ($mylevel < 9) { print "pass: ".($mylevel+1); open (KEYD, "<:encoding(latin1)", $dfile) or die "can not open $dfile\n"; while(){ ($hid,$hlevel,$hof)=/^(\d+)\t(?:[^\t]*\t){12} *(\d+)\t*(\d+)(?:\t.*$)?/; if($mylevel == $hlevel-1) { print "$i.$mylevel:$hid:$hlevel/$hof;\n" if $check; $hier{$hid} = $hier{$hof}?$hier{$hof}:$hier0; $hier{$hid} =~ s/^\d+((\t\d+){$mylevel})\t0/$hlevel$1\t$hid/; print "->$hier{$hid}\n" if $check; $i++; } } close (KEYD); $mylevel++; } open (KEYH, ">:encoding(utf8)", $hfile) or die "can not open $hfile\n"; while (($key,$value)= each %hier) { $value =~ s/\t0/\tnull/g; $value =~ s/\t/,/g; print KEYH "INSERT INTO geodb_hierarchies ($key,$value,null,null,null,3000-01-01); /* $country */\n"; } } >> Daher habe ich für den Dump auch mal eingerichtet, dass die hiearchies >> neu erstellt werden und habe >> http://fa-technik.adfc.de/code/opengeodb/Dhier.sql usw. >> erzeugt. Bisher habe ich aber keine Rückmeldung, ob das irgendwie >> brauchbar ist. >> > Was heisst usw.? Gibt es da noch mehr? Schau einfach mal in das Verzeichnis. Die Hierarchie-Tabellen wurden laenderweise erzeugt. Daher gibt es auch AThier.sql, Bhier.sql usw. >>> "SF" enthält type_names mit Inhalten und die Tabellenstruktur für >>> hierarchies, jedoch keine Werte dafür. type_names ist unvollständig >>> (d.h. es fehlen Werte, die in im Feld loc_type vorkommen). >>> >> >> Mit genauen Angaben lässt sich korrigieren, was so unklar im Raum steht. >> > Es fehlen die type_names: > +-----------+ > | loc_type | > +-----------+ > | 100900000 | > | 610000000 | > | 500100000 | > +-----------+ seltsam - der dump wird typischerweise erzeugt aus der Verkettung von opengeodb-begin.sql, den Landes-SQL, extra.sql und opengeodb-end.sql In http://fa-technik.adfc.de/code/opengeodb/opengeodb-end.sql steht INSERT INTO geodb_type_names VALUES(100900000,'de','Ortsteil'); INSERT INTO geodb_type_names VALUES(500100000,'de','Name'); INSERT INTO geodb_type_names VALUES(610000000,'de','Fläche'); Oder wie muesste der Befehl heissen, den du vermisst? >>> > 3) In der sourceforge-Fassung werden die Tabellen zwar vom Typ InnoDB >>> > deklariert, es werden jedoch keine foreign keys deklariert, die solche >>> > Fehler wie fehlende Typnamen vermeiden helfen würden. Was ist die >>> > Überlegung dahinter? >>> >> >> Das sollten SQL-Experten beantworten, ich selbst brauche das nicht. >> > Es würde zwar bei Inserts und Updates die Performance beeinträchtigen, > aber die Datenintegrität erhöhen. Wo immer es möglich ist, empfehle ich, > Relationen zwischen Tabellen mit Foreign-Key-Constraints abzusichern. Wenn du mir beschreiben kannst, wie das Endergebnis fuer die sql-Datei aussehen muss, dann kann ich das vielleicht hinzufuegen. > Neben der oben empfohlenen Einführung von Foreign Keys schlage ich vor, > alle Feldbezeichnungen so zu vereinheitlichen, dass Referenzen auf > identische Felder identische Namen haben. Zur Zeit gibt es (siehe > Union-Abfrage oben) diverse Felder namens ..._type, die alle dasselbe > meinen, nämlich eine Referenz auf die Tabelle type_names. ok, ich warte dann auf einen Vorschlag von dir, der moeglichst endgueltig sein muesste. Da wir damit erneut die Datenstruktur aendern wuerden, wuerde das in eine 0.2.7 einfliessen. > Im übrigen verstehe ich zwar einerseits die Anlage der Wertetabellen für > atomare Typen wie float, int, text und die Flexibilität, die damit > erzielt wird. Andererseits kommt mir die Struktur, die offenbar bis etwa > 2005 gepflegt wurde, wesentlich einleuchtender vor. Die künstliche > Trennung von Primärschlüssel (loc_id) und Attributen und deren > Aufspaltung in typorientierte Tabellen kommt mir unter den Aspekten der > Datenpflege und der Programmierung eher kontraproduktiv vor. Was war > denn ausschlaggebend für diese Umstrukturierung? Du musst mir weiterhelfen, was hier fuer dich der Unterschied zwischen 2005 und heute ist. Auf welche SQL-Daten beziehst du dich dabei? Schoenen Gruss Martin Trautmann -- View this message in context: http://www.nabble.com/DB-Versionen%2C-geodb_hierarchies%2C-geodb_type_names-und-Ungereimtheiten-tp14718223p14730649.html Sent from the Php German - opengeodb mailing list archive at Nabble.com. From Christian at TheTwinS74.de Thu Jan 10 11:00:05 2008 From: Christian at TheTwinS74.de (=?iso-8859-1?Q?Christian_Sch=FCtt?=) Date: Thu, 10 Jan 2008 11:00:05 +0100 Subject: [opengeodb] PHP5 Message-ID: <019A730ABFB74E27AD5BFFDDCD997EC5@ChrissNotebook> Hallo OpenGeo-Gemeinde, Über die Seite http://www.opgendeodb.de findet man die Downloadseite http://sourceforge.net/project/showfiles.php?group_id=132421 über die man die OpenGeoDB Daten und Test-Skripts downloaden kann. Diese ganzen Dinge sind ja nicht gerade neu. Nun habe ich das Problem, dass diese Sachen alle nur unter PHP 4.x laufen, unter PHP 5 funktioniert es nicht mehr. Gibt es da schon Varianten, die an PHP 5 angepasst wurden? Gruß, Chriss -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20080110/6ec65049/attachment.html From 922492 at gmx.de Thu Jan 10 12:16:31 2008 From: 922492 at gmx.de (Sascha Mantscheff) Date: Thu, 10 Jan 2008 12:16:31 +0100 Subject: [opengeodb] DB-Versionen, geodb_hierarchies, geodb_type_names und Ungereimtheiten In-Reply-To: <14730649.post@talk.nabble.com> References: <478511CA.3070104@gmx.de> <47852D3B.2020704@gmx.de> <4785DCE1.3080608@gmx.de> <14730649.post@talk.nabble.com> Message-ID: <4785FE8F.4090606@gmx.de> Martin Trautmann schrieb: > On 2008-01-10 09:52, Sascha Mantscheff wrote: > >>> Ich vermisse hier aber noch immer einen SQL-Ansatz, wie diese >>> automatisch abgeleitet werden könnten. >>> >>> >> Dazu wären die Skripte bzw. das Verfahren hilfreich, nach dem die von >> Dir genannte Hiearchietabelle erzeugt wurde. >> > > Bist du sicher, dass die dir helfen würden? > Deine Skepsis ist berechtigt. Wenn ich es richtig verstehe, werden hier *.tab-Dateien nach SQL gewandelt. Dann muss ich fragen, woher denn die *.tab-Dateien kommen? Werden die aus dem Datenbestand abgeleitet, oder sind es Grunddaten, die gepflegt werden? > seltsam - der dump wird typischerweise erzeugt aus der Verkettung von > opengeodb-begin.sql, den Landes-SQL, extra.sql und opengeodb-end.sql > > In http://fa-technik.adfc.de/code/opengeodb/opengeodb-end.sql steht > > INSERT INTO geodb_type_names VALUES(100900000,'de','Ortsteil'); > INSERT INTO geodb_type_names VALUES(500100000,'de','Name'); > INSERT INTO geodb_type_names VALUES(610000000,'de','Fläche'); > Das sind schon die richtigen Befehle, und damit wird es auch stimmig. Aber im Dump D.sql sind offenbar opengeodb-(begin|end).sql nicht enthalten. > Wenn du mir beschreiben kannst, wie das Endergebnis fuer die sql-Datei > aussehen muss, dann kann ich das vielleicht hinzufuegen. > Ich gebe mich die nächsten Tage mal dran. > Du musst mir weiterhelfen, was hier fuer dich der Unterschied zwischen > 2005 und heute ist. Auf welche SQL-Daten beziehst du dich dabei? > Wenn ich das so genau wüsste. Quelldaten liegen keine vor, nur MySQL-Tabellen, die wohl aus früheren einem GeoDB-Import und Nachbearbeitung entstanden sind. Die locations-Tabelle beispielsweise sieht aus wie unten gezeigt. Gruss s.m. +----------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------+--------------+------+-----+---------+----------------+ | id | int(12) | NO | PRI | NULL | auto_increment | | typ | int(12) | YES | | NULL | | | name | varchar(250) | YES | | NULL | | | name_int | varchar(250) | YES | | NULL | | | gs | varchar(8) | YES | | NULL | | | adm0 | char(2) | YES | MUL | NULL | | | adm1 | char(2) | YES | MUL | NULL | | | adm2 | varchar(250) | YES | MUL | NULL | | | adm3 | varchar(250) | YES | MUL | NULL | | | adm4 | varchar(250) | YES | | NULL | | | ort | varchar(250) | YES | MUL | NULL | | | ortsteil | varchar(250) | YES | | NULL | | | gemteil | varchar(250) | YES | | NULL | | | breite | float | YES | | NULL | | | laenge | float | YES | | NULL | | | kfz | char(3) | YES | | NULL | | | plz | text | YES | | NULL | | +----------+--------------+------+-----+---------+----------------+ From wendorff at uni-paderborn.de Thu Jan 10 12:23:39 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Thu, 10 Jan 2008 12:23:39 +0100 Subject: [opengeodb] DB-Versionen, geodb_hierarchies, geodb_type_names und Ungereimtheiten In-Reply-To: <4785F9AD.6090405@gmx.de> References: <478511CA.3070104@gmx.de> <47852D3B.2020704@gmx.de> <4785DCE1.3080608@gmx.de> <4785F9AD.6090405@gmx.de> Message-ID: <4786003B.4050205@uni-paderborn.de> Ich habe grade mal versucht, herauszufinden, ob es eine Regelung gibt, wie DBMS ohne Fremdschlüssel-Umsetzung mit den Angaben im SQL-Script umgehen sollen, die Fremdschlüsselbeziehungen definieren. Leider habe ich nichts generelles dazu gefunden. Die MYSQL-Website besagt aber, dass in mysql, wo bisher nur InnoDB-Tabellen Fremdschlüssel anwenden, in anderen Tabellenformaten die Fremdschlüsselbeziehung einfach ignoriert (bzw. gelesen und in die Tabellen-Metainformation für Exportzwecke gespeichert, aber die Integrität nicht geprüft) wird. Insofern sollte das Script hoffentlich auch in anderen DBMS funktionieren - nur eben ohne der Integritätsprüfung. Gruß Peter Wendorff Sascha Mantscheff schrieb: > In den nächsten Tagen werde ich erst mal mit der DB arbeiten und ein > MySQL-Skript erstellen, das die von mir gewünschten Änderungen einbaut. > Wenn das funktioniert, werde ich es hier zur Verfügung stellen. Es wird > aber nur funktionieren in Datenbanken, die Foreign Key Constraints > unterstützen, und testen werde ich es mit MySQL 5/InnoDB. > > s.m From wendorff at uni-paderborn.de Thu Jan 10 13:48:12 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Thu, 10 Jan 2008 13:48:12 +0100 Subject: [opengeodb] DB-Versionen, geodb_hierarchies, geodb_type_names und Ungereimtheiten In-Reply-To: References: <478511CA.3070104@gmx.de> <47852D3B.2020704@gmx.de> <4785DCE1.3080608@gmx.de> <4785F9AD.6090405@gmx.de> <4786003B.4050205@uni-paderborn.de> Message-ID: <4786140C.6020500@uni-paderborn.de> Die Frage, die ich mir stelle ist aber: Wie sieht das generell aus mit anderen DBMS-Systemen? Wir haben schließlich nicht nur mysql-Nutzer - sondern abgesehen von Text-Dateien auch diverse andere SQL-Systeme (postgre sql bin ich mir ziemlich sicher, ms xml vermute ich....) Deshalb stellt sich hier eher die Frage: Gibt es einen Standard, wie mit so etwas umgegangen wird? Gruß Peter > > Das ist korrekt. Wenn du myisam verwendest, werden Fremdschlüssel > einfach ignoriert. Wenn du die engine auf innodb änderst, werden die > Foreign Keys wieder automatisch geprüft (sofern nicht explizit > deaktiviert). Ein Nachteil entsteht also für <=mysql4-Benutzer nicht. > > Michael > From 922492 at gmx.de Thu Jan 10 14:02:06 2008 From: 922492 at gmx.de (Sascha Mantscheff) Date: Thu, 10 Jan 2008 14:02:06 +0100 Subject: [opengeodb] DB-Versionen, geodb_hierarchies, geodb_type_names und Ungereimtheiten In-Reply-To: <4786140C.6020500@uni-paderborn.de> References: <478511CA.3070104@gmx.de> <47852D3B.2020704@gmx.de> <4785DCE1.3080608@gmx.de> <4785F9AD.6090405@gmx.de> <4786003B.4050205@uni-paderborn.de> <4786140C.6020500@uni-paderborn.de> Message-ID: <4786174E.8050909@gmx.de> Foreign Key Constraints gehören zum SQL92-Standard. Jede zu diesem Standard kompatible DB kann die Statements zumindest parsen. Wenn die Constraints nicht von der DB erzwungen werden, ist das nur ein Problem für die Anwendungsprogrammierung, aber nicht für die Datenhaltung. "ms xml" soll MS-SQL heissen, nehme ich an? Ist angeblich auch kompatibel. s.m. Peter Wendorff schrieb: > Die Frage, die ich mir stelle ist aber: Wie sieht das generell aus mit > anderen DBMS-Systemen? > Wir haben schließlich nicht nur mysql-Nutzer - sondern abgesehen von > Text-Dateien auch diverse andere SQL-Systeme (postgre sql bin ich mir > ziemlich sicher, ms xml vermute ich....) > Deshalb stellt sich hier eher die Frage: Gibt es einen Standard, wie mit > so etwas umgegangen wird? > > Gruß > Peter > >> Das ist korrekt. Wenn du myisam verwendest, werden Fremdschlüssel >> einfach ignoriert. Wenn du die engine auf innodb änderst, werden die >> Foreign Keys wieder automatisch geprüft (sofern nicht explizit >> deaktiviert). Ein Nachteil entsteht also für <=mysql4-Benutzer nicht. >> >> Michael >> >> > > From wendorff at uni-paderborn.de Thu Jan 10 15:35:02 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Thu, 10 Jan 2008 15:35:02 +0100 Subject: [opengeodb] DB-Versionen, geodb_hierarchies, geodb_type_names und Ungereimtheiten In-Reply-To: <4786174E.8050909@gmx.de> References: <478511CA.3070104@gmx.de> <47852D3B.2020704@gmx.de> <4785DCE1.3080608@gmx.de> <4785F9AD.6090405@gmx.de> <4786003B.4050205@uni-paderborn.de> <4786140C.6020500@uni-paderborn.de> <4786174E.8050909@gmx.de> Message-ID: <47862D16.4020209@uni-paderborn.de> Sascha Mantscheff schrieb: > "ms xml" soll MS-SQL heissen, nehme ich an? Ist angeblich auch kompatibel. > Ja - klar ;) sorry. From andi at saerdnaer.de Mon Jan 14 01:11:09 2008 From: andi at saerdnaer.de (Andreas Hubel) Date: Mon, 14 Jan 2008 01:11:09 +0100 Subject: [opengeodb] =?iso-8859-1?q?Readme_f=FCr_http=3A//fa-technik=2Eadf?= =?iso-8859-1?q?c=2Ede/code/opengeodb/?= Message-ID: <7AC85DA8-1C2F-4EBD-A271-19B3DFA7616C@saerdnaer.de> Hi, irgendwie fehlt unter http://fa-technik.adfc.de/code/opengeodb/ eine Art Readme Datei, die kurz erklärt was die Dateien die es dort gibt eigendlich sind. MfG Andreas Hubel From traut at gmx.de Mon Jan 14 20:14:01 2008 From: traut at gmx.de (Martin Trautmann) Date: Mon, 14 Jan 2008 20:14:01 +0100 Subject: [opengeodb] =?iso-8859-1?q?Readme_f=FCr_http=3A//fa-technik=2Eadf?= =?iso-8859-1?q?c=2Ede/code/opengeodb/?= In-Reply-To: <7AC85DA8-1C2F-4EBD-A271-19B3DFA7616C@saerdnaer.de> References: <7AC85DA8-1C2F-4EBD-A271-19B3DFA7616C@saerdnaer.de> Message-ID: <478BB479.1080600@gmx.de> Andreas Hubel wrote: > Hi, > > irgendwie fehlt unter http://fa-technik.adfc.de/code/opengeodb/ eine > Art Readme Datei, die kurz erklärt was die Dateien die es dort gibt > eigendlich sind. Hallo Andreas, Detlef hatte eine solche Datei schon einmal begonnen, die Arbeit aber noch nicht fortgesetzt. Wenn du magst, kannst du eine schreiben, ich schiebe sie dann dorthin. Eine Idee war z.B. ################################################################################ # # opengeodb readme.txt # # v. 0.1 fÜr opengeodb 0.2.6 von ???, 2008-01-14 ################################################################################ # .sql # .tab # # # Dateien # Dateien # Erklärung # ################################################################################ # loc_id # locid # eindeutige, fortlaufende Zuordnungsnummer, Primärschlüssel # # # # # # # 500600000 # ags # Deutschland: 'Amtlicher Gemeindeschlüssel', # # # Össterreich: 'Gemeindeschlüssel' # # # Schweiz: amtliche Nummer ergänzt um # # # nicht amtliche Kennung K/B/G # # # für Kanton/Bezirk/Gemeinde usw., vgl. http://downloads.sourceforge.net/opengeodb/Constants.txt Einige Ergänzungen kann ich dann nachtragen, vgl. speziell http://fa-technik.adfc.de/code/opengeodb/opengeodb-end.sql (400100000,'de','Teil von'); (400200000,'de','Ebene'); (400300000,'de','Typ'); und evtl. auch die Hilfstypen (200200000,'de','lat'); (200300000,'de','lon'); Schönen Gruß Martin From traut at gmx.de Mon Jan 14 20:17:27 2008 From: traut at gmx.de (Martin Trautmann) Date: Mon, 14 Jan 2008 20:17:27 +0100 Subject: [opengeodb] =?iso-8859-1?q?L=E4nderk=FCrzel_D-=3EDE=2C_A-=3EAT=2C?= =?iso-8859-1?q?_=2E=2E=2E?= Message-ID: <478BB547.10700@gmx.de> Hallo, auf fa-technik.adfc.de/code/opengeodb wurden die Dateien umbenannt auf zweistellige ISO-Kürzel D -> DE A -> AT B -> BE NL, LI, CH blieben unverändert. Links in z.B. http://fa-technik.adfc.de/code/opengeodb.pl?action=changes wurden nachgebessert. Sonst ist mir hoffentlich nichts entgangen. Entsprechende frühere Beispiel-Links wie verlieren damit ihre Gültigkeit und müssen entsprechend korrigiert werden: Schönen Gruß Martin From christoph.reithmair at web.de Tue Jan 15 13:43:27 2008 From: christoph.reithmair at web.de (Christoph Reithmair) Date: Tue, 15 Jan 2008 13:43:27 +0100 Subject: [opengeodb] =?iso-8859-15?q?DB-Abfrage_f=FCr_Umkreissuche?= Message-ID: <923311738@web.de> Hallo, ich will auf der opengeoD eine Umkreissuche ausführen. Dabei habe ich die geografische Position einer PLZ (hier 93354) und eine Liste an verfügbaren PLZ's (hier: '93326', '93333', '93309', '71083', '85055'), die in korrektem Abstand gebracht werden müssen. Leider liefert mir meine Abfrage falsche Ergebnisse zurück: SELECT DISTINCT ( text_val ) AS plz, ( 6380.0 * acos( sin( lat ) * sin( 48.8 ) + cos( lat ) * cos( 48.8 ) * cos( lon - 11.8667 ) ) ) AS distance FROM geodb_textdata AS text, geodb_coordinates AS coord WHERE text.loc_id = coord.loc_id AND text_type =500300000 AND length( text_val ) =5 AND lat BETWEEN ( 48.8 - 4.49157642572998 ) AND ( 48.8 + 4.49157642572998 ) AND lon BETWEEN ( 11.8667 - 4.49157642572998 ) AND ( 11.8667 + 4.49157642572998 ) AND text_val IN ( '93326', '93333', '93309', '71083', '85055' ) ORDER BY ( 6380.0 * acos( sin( lat ) * sin( 48.8 ) + cos( lat ) * cos( 48.8 ) * cos( lon - 11.8667 ) ) ) Hat jmd. eine Idee an was das liegen könnte? Viele Grüße _______________________________________________________________________ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220 From traut at gmx.de Tue Jan 15 15:44:42 2008 From: traut at gmx.de (Martin Trautmann) Date: Tue, 15 Jan 2008 06:44:42 -0800 (PST) Subject: [opengeodb] =?utf-8?b?TMOkbmRlcmvDvHJ6ZWwgRC0+REUsIEEtPkFULCAu?= =?utf-8?b?Li4=?= In-Reply-To: References: <478BB547.10700@gmx.de> Message-ID: <14841224.post@talk.nabble.com> > Gibt es auch eine Auflösung > > DE -> Deutschland > FR -> Frankreich Selbstverstaendlich. Oder auch nicht. http://sourceforge.net/docman/display_doc.php?docid=27435&group_id=132421 nennt unsere ISO country codes. Allerdings bin ich mir unsicher, welchen ISO-Standards wir folgen sollen. Vorab spontan von euch geraten: Wie lautet der richtige Code für Liechtenstein? ISO639-1 bezeichnet eigentlich verschiedene Sprachen - und weil die zweistelligen Schluessel hier nicht ausreichen, gibt es dreistellige, nach ISO639-2 oder ISO639-3. Bisher verwenden wir bei names nur die zweistelligen Kennzeichnungen fuer die Sprache. Liechtenstein hat keine eigene Sprache - offiziell spricht man dort deutsch, also Sprachkürzel "de" Die Internet-Toplevel-Domain lautet ".li" - was als Sprache seit 2002 für limburgisch steht. Ländercodes nach ISO3166-1 lauten LI und LIE für Liechtenstein. Die Variante mit zwei Buchstaben wird grundsätzlich für die toplevel domains verwendt. .li wird seit 1993 offiziell für Liechtenstein verwendet. Aber auch Long Island nutzt .li! Das internationale Landeskennzeichen ist seit 1923 für das Fürstentum Liechtenstein das "FL". Was also wollen wir für Liechtenstein nehmen? Derzeit verwende ich LI, gemäss ISO3166-1. Nehmen wir für die Sprache also ISO639-1 und für die Länder ISO3166-1? Schoenen Gruss Martin -- View this message in context: http://www.nabble.com/L%C3%A4nderk%C3%BCrzel-D-%3EDE%2C-A-%3EAT%2C-...-tp14810446p14841224.html Sent from the Php German - opengeodb mailing list archive at Nabble.com. From sn at heise.de Tue Jan 15 15:52:52 2008 From: sn at heise.de (Sven Neuhaus) Date: Tue, 15 Jan 2008 15:52:52 +0100 Subject: [opengeodb] =?iso-8859-1?q?L=E4nderk=FCrzel_D-=3EDE=2C_A-=3EAT=2C?= =?iso-8859-1?q?_=2E=2E=2E?= In-Reply-To: <14841224.post@talk.nabble.com> References: <478BB547.10700@gmx.de> <14841224.post@talk.nabble.com> Message-ID: <478CC8C4.30501@heise.de> Hallo, Martin Trautmann schrieb: > Allerdings bin ich mir unsicher, welchen ISO-Standards wir folgen sollen. > > Vorab spontan von euch geraten: Wie lautet der richtige Code für > Liechtenstein? > > ISO639-1 bezeichnet eigentlich verschiedene Sprachen - und weil die > zweistelligen Schluessel hier nicht ausreichen, gibt es dreistellige, nach > ISO639-2 oder ISO639-3. Bisher verwenden wir bei names nur die zweistelligen > Kennzeichnungen fuer die Sprache. > > Liechtenstein hat keine eigene Sprache - offiziell spricht man dort deutsch, > also Sprachkürzel "de" > > Die Internet-Toplevel-Domain lautet ".li" - was als Sprache seit 2002 für > limburgisch steht. > > Ländercodes nach ISO3166-1 lauten LI und LIE für Liechtenstein. Die Variante > mit zwei Buchstaben wird grundsätzlich für die toplevel domains verwendt. > .li wird seit 1993 offiziell für Liechtenstein verwendet. Aber auch Long > Island nutzt .li! ...und Aktiengesellschaften benutzen die TLD .ag. Das ist ja kein Grund gegen ISO3166. > Das internationale Landeskennzeichen ist seit 1923 für das Fürstentum > Liechtenstein das "FL". > > Was also wollen wir für Liechtenstein nehmen? Derzeit verwende ich LI, > gemäss ISO3166-1. > > Nehmen wir für die Sprache also ISO639-1 und für die Länder ISO3166-1? Da wäre ich für, diese Kürzel sind im Internet besser bekannt als die Länderkennzeichen. Gruss, -Sven From list at lab.at Tue Jan 15 16:22:36 2008 From: list at lab.at (Andreas Labres) Date: Tue, 15 Jan 2008 16:22:36 +0100 Subject: [opengeodb] =?iso-8859-1?q?L=E4nderk=FCrzel_D-=3EDE=2C_A-=3EAT=2C?= =?iso-8859-1?q?_=2E=2E=2E?= In-Reply-To: <14841224.post@talk.nabble.com> References: <478BB547.10700@gmx.de> <14841224.post@talk.nabble.com> Message-ID: <478CCFBC.2090904@al.lab.at> Martin Trautmann wrote: > ISO639-1 bezeichnet eigentlich verschiedene Sprachen - und weil die > zweistelligen Schluessel hier nicht ausreichen, gibt es dreistellige, nach > ISO639-2 oder ISO639-3. Bisher verwenden wir bei names nur die zweistelligen > Kennzeichnungen fuer die Sprache. Man sollte Sprach- und Ländercodes unterscheiden... ISO 3166 sind die Ländercodes, und die gibt's für jedes Land dieser Welt 2 und 3stellig. http://www.iso.org/iso/country_codes.htm http://de.wikipedia.org/wiki/ISO_3166 ISO 639 sind Sprach-Codes, die braucht man dann, wenn man ein und denselben Begriff in verschiedenen Sprachen (Kulturkreisen) ausdrücken will. http://de.wikipedia.org/wiki/ISO_639 ccTLDs sind angelehnt an ISO 3166, aber nicht immer gleich (resp. erweitert). http://www.iana.org/root-whois/index.html Dann gibt's noch die Auto-Ländercodes (1-3stellig). Und um Deine Frage zu beantworten: LI. Nur mal so als Beispiel, das Land mit seiner Hauptstadt: AT "Land" de Österreich AT "Land" en Austria AT "Land" fr Autriche AT "Hauptstadt" de Wien AT "Hauptstadt" en Vienna AT "Hauptstadt" fr Vienne Will sagen, für Ortsbegriffe braucht es immer beides, einen Länderbezug UND eine Sprache. /al From list at lab.at Tue Jan 15 16:32:58 2008 From: list at lab.at (Andreas Labres) Date: Tue, 15 Jan 2008 16:32:58 +0100 Subject: [opengeodb] =?iso-8859-1?q?L=E4nderk=FCrzel_D-=3EDE=2C_A-=3EAT=2C?= =?iso-8859-1?q?_=2E=2E=2E?= In-Reply-To: <14841224.post@talk.nabble.com> References: <478BB547.10700@gmx.de> <14841224.post@talk.nabble.com> Message-ID: <478CD22A.1020301@al.lab.at> (irgendwie habe ich das nicht zu Ende gelesen... :( ) Martin Trautmann wrote: > Nehmen wir für die Sprache also ISO639-1 und für die Länder ISO3166-1? Ja, natürlich. 'DE' ist das Land und 'de' die Sprache. /al From traut at gmx.de Tue Jan 15 16:50:46 2008 From: traut at gmx.de (Martin Trautmann) Date: Tue, 15 Jan 2008 07:50:46 -0800 (PST) Subject: [opengeodb] =?utf-8?b?TMOkbmRlcmvDvHJ6ZWwgRC0+REUsIEEtPkFULCAu?= =?utf-8?b?Li4=?= In-Reply-To: <14841224.post@talk.nabble.com> References: <478BB547.10700@gmx.de> <14841224.post@talk.nabble.com> Message-ID: <14841549.post@talk.nabble.com> Andreas hatte kurzfristig geschafft, mich zu verwirren ;-) Anscheinend sind wir aber alle gleichermassen der Meinung, LI für Liechtenstein zu nehmen. Entsprechend habe ich folgende Dokumente aktualisiert und erweitert: http://sourceforge.net/docman/display_doc.php?docid=27435&group_id=132421 03. ISO country codes and ISO codes of federal states http://sourceforge.net/docman/display_doc.php?docid=27436&group_id=132421 03. ISO Kürzel der Länder und Bundesländer / Kantone Im Vorgriff habe ich auch mal NL hinzugefügt. BB habe ich mit Kommentar auf DE-BR geaendert, ND auf DE-NI (und insgesamt nun expliziter Hinweis auf ISO 3166-1 und 3166-2). Hinweis auf die Sprachen laut ISO 639-1 muss ich noch einfuegen. -- View this message in context: http://www.nabble.com/L%C3%A4nderk%C3%BCrzel-D-%3EDE%2C-A-%3EAT%2C-...-tp14810446p14841549.html Sent from the Php German - opengeodb mailing list archive at Nabble.com. From sven at anders-hamburg.de Wed Jan 16 12:47:04 2008 From: sven at anders-hamburg.de (Sven Anders) Date: Wed, 16 Jan 2008 12:47:04 +0100 Subject: [opengeodb] Dump der Datenbank Message-ID: <200801161247.04423.sven@anders-hamburg.de> Hi, kann mal jemand wieder einen Dump der gesamt DB in das Verzeichnis: http://fa-technik.adfc.de/code/opengeodb/dump/ triggern? Danke Sven From traut at gmx.de Wed Jan 16 14:24:41 2008 From: traut at gmx.de (Martin Trautmann) Date: Wed, 16 Jan 2008 05:24:41 -0800 (PST) Subject: [opengeodb] Dump der Datenbank In-Reply-To: <200801161247.04423.sven@anders-hamburg.de> References: <200801161247.04423.sven@anders-hamburg.de> Message-ID: <14880651.post@talk.nabble.com> Hallo Sven, im Prinzip kann ich jederzeit einen neuen Dump erstellen. Im Moment zoegere ich aber, weil ich OSM-Daten fuer die Strassen hinzugefuegt habe. Diese stehen aber moeglicherweise unter speziellen Lizenzbestimmungen. Ich muss daher die Strassendaten wieder herausloesen und unter einer eigenen Lizenz bereitstellen bzw. einem aktuellen Dump erst noch einen Lizenzdisclaimer hinzufuegen, dass dieser spezielle dump wegen der enthaltenen Teilmenge unter der entsprechenden OpenStreetMap-Lizenz steht. Was brauchst du speziell? Schoenen Gruss Martin -- View this message in context: http://www.nabble.com/Dump-der-Datenbank-tp14879434p14880651.html Sent from the Php German - opengeodb mailing list archive at Nabble.com. From sven at anders-hamburg.de Wed Jan 16 15:25:37 2008 From: sven at anders-hamburg.de (Sven Anders) Date: Wed, 16 Jan 2008 15:25:37 +0100 Subject: [opengeodb] Dump der Datenbank In-Reply-To: <14880651.post@talk.nabble.com> References: <200801161247.04423.sven@anders-hamburg.de> <14880651.post@talk.nabble.com> Message-ID: <200801161525.37760.sven@anders-hamburg.de> Am Mittwoch, 16. Januar 2008 14:24 schrieb Martin Trautmann: > Hallo Sven, > > im Prinzip kann ich jederzeit einen neuen Dump erstellen. Im Moment zoegere > ich aber, weil ich OSM-Daten fuer die Strassen hinzugefuegt habe. Diese > stehen aber moeglicherweise unter speziellen Lizenzbestimmungen. Ich muss > daher die Strassendaten wieder herausloesen und unter einer eigenen Lizenz > bereitstellen bzw. einem aktuellen Dump erst noch einen Lizenzdisclaimer > hinzufuegen, dass dieser spezielle dump wegen der enthaltenen Teilmenge > unter der entsprechenden OpenStreetMap-Lizenz steht. > > Was brauchst du speziell? Alles! Wobei ich alles wieder in OSM importieren möchte, in sofern macht es mir nichts aus, wenn der gesamten Dump unter CC by SA 2.0 Lizenz steht. Im Zweifel reicht mir natürlich auch eine Version ohne die Straßen. Gruß Sven From sven at anders-hamburg.de Sat Jan 19 21:59:11 2008 From: sven at anders-hamburg.de (Sven Anders) Date: Sat, 19 Jan 2008 21:59:11 +0100 Subject: [opengeodb] Erster OpenGeoDB Import in OpenStreetMap ist durchgelaufen. Message-ID: <200801192159.11509.sven@anders-hamburg.de> Moin, Ich habe mich dazu entschieden, gemäß den Open Source Regeln "Release Early, Release Often " den Import von OpenGeoDB in OpenStreetMap an zu werden. Er wurde heute um 18:16 Uhr gestartet und war um ca. 21:53 Uhr beendet. Leider ist der Import von Relationen zum Teil fehlgeschlagen. Grund dafür ist vermutlich ein Bug im Zusammenspiel zwischen Josm und dem Import-Bot (oder ein Bug bei Josm). Ich habe mich deshalb dafür entschieden alle noch nicht hochgeladen Relationen (=fast alle!!) aus dem Import zu entfernen und später zu ergänzen. Bitte schaut Euch die daraus neu entstanden Orte an. Ich hoffe es ist nichts kaputt gegangen, ansonsten bitte möglichst schnell melden, damit ich sehen kann, wie wir es wieder gerade biegen.... (ich habe ein Backup aller places vor dem Lauf) Kommentare (ich hoffe das es im Großen und Ganzen gefällt) dazu könnt Ihr auf die Webseite: http://wiki.openstreetmap.org/index.php/User:OpenGeoDB abgegeben. Ich plane später weitere Abgleiche zwischen OpenGeoDB und OpenStreetmap, dazu muss aber erst das Skript angepasst werden. Gruß Sven From traut at gmx.de Sun Jan 20 09:12:52 2008 From: traut at gmx.de (Martin Trautmann) Date: Sun, 20 Jan 2008 09:12:52 +0100 Subject: [opengeodb] =?iso-8859-1?q?Korrekturvorschl=E4ge_Ortsteilkoordina?= =?iso-8859-1?q?ten?= Message-ID: <47930284.2010404@gmx.de> Hallo, ich bin in nächster Zeit weniger online und würde daher gerne einige Korrekturaufgaben auf mehr Schultern verteilen. Die neuesten opengeodb-Daten enthalten sowohl viele Ortsteile als auch zunehmend Straßenkoordinaten aus der openstreetmap. Mit dieser breiteren Datenbasis lassen sich die Angaben nun gegenseitig prüfen und vergleichen. Ein solcher Vergleich ergab erhebliche Differenzen zwischen den bisherigen Koordinaten und dem Zielbereich, wo sie eigentlich liegen müssten. Hier mal die schlimmsten Ausreisser (> 20 km). Mein Wunsch wäre: prüft diese Daten mit anderen Quellen (wikipedia, google-maps usw.) und ersetzt die falschen Koordinaten durch die richtigen. Die Zuordnung erfolgten ursprünglich durch den bestmöglichen Treffer zu den NIMA Geonames. Es ist möglich, dass an der betreffenden Stelle also tatsächlich ein korrekter Ort mit diesem Namen zu finden sein mag. Statt aber diesen der richtigen Gemeinde zuzuordnen, bitte ich um das Heraussuchen, wo sich der in der opengeodb schon einer Gemeinde zugeordnete Ort tatsächlich befindet - denn diesem Ortsteil sind dann bereits seine Straßen zugeordnet. -> Änderung der Koordinaten alt->neu Die Ausreisser mögen beliebig schlimm aussehen. Zum Vergleich, was wir damit gewannen: 1293 liegen in einem Radius von 5 km, 103 bis 10 km, 52 bei 10 bis 20 km und nur 22 über 20 km. Falls jemand Vorschläge für eine andere Art der Darstellung vorschlagen mag (z.B. Unterbringung auf Wiki-Seiten oder Vor-Formatierung der Koordinaten als URLs zu Google, OpenStreetMap usw., werde ich das gerne umsetzen. Schönen Gruß Martin Bisheriges Format: Obengeodb-loc_id, Amtlicher Gemeindeschlüssel, ergänzt um eine nicht amtliche Teilnummerierung, Postleitzahl/en, Name, alte Koordinaten (Breiten-/Längengrad), Vorschlag für neue Koordinaten (Breiten-/Längengrad), Längendifferenz alt/neu Link zur opengeodb-Seite zum Bearbeiten * 82141: 08115003002; 71034 Dagersheim; 48.7/8.116667 -> 48.686463/8.950097 (92.8 km) * 81062: 08116019021; 73730 Sirnau; 48.716667/9.333333 -> 48.902852/9.403008 (21.9 km) * 81066: 08116019028; 73730 Zell; 48.733333/9.366667 -> 48.813316/9.15058 (25.6 km) * 81082: 08116077007; 70794 Sielmingen; 48.666667/9.233333 -> 48.801344/9.392792 (23.1 km) * 81129: 08118010001; 74357 Bönnigheim; 49.040556/9.092778 -> 48.483958/9.467184 (74 km) * 81332: 08127052005; 74535 Bubenorbis; 49.083056/9.615 -> 48.931171/9.470171 (23.2 km) * 81350: 08128126017; 97990 Weikersheim; 49.480556/9.905 -> 49.577997/9.71895 (23.3 km) * 82144: 0821200012; 76135/76189 Oberreut; 47.716667/11.583333 -> 48.985297/8.365894 (384.3 km) * 82145: 0821200016; 76131/76139 Waldstadt; 48.35/13.283333 -> 49.035619/8.442928 (544.2 km) * 81446: 0821200026; 76149 Neureut; 48.6/13.45 -> 49.046842/8.385476 (566.1 km) * 81457: 08215009004; 76646 Heidelsheim; 49.101111/8.645 -> 49.043616/8.457967 (21.8 km) * 81715: 08237028016; 72250 Wittlensweiler; 48.466667/8.45 -> 48.576491/8.174094 (33 km) * 81742: 08311000540; 79108/79110 Landwasser; 48.216667/8.15 -> 48.018859/7.815528 (43.2 km) * 81743: 08311000550; 79108/79110/79111 Lehen; 47.766667/11.716667 -> 48.017545/7.800963 (436.9 km) * 81744: 08311000610; 79100/79111/79114/79115 Haslach; 48.283333/8.083333 -> 47.98915/7.816619 (44 km) * 82146: 08311000660; 79111/79114/79115 Weingarten; 49.056111/8.524722 -> 47.997965/7.812669 (141 km) * 81751: 08315015003; 79206 Gündlingen; 48.016667/7.633333 -> 48.019395/7.821328 (20.9 km) * 81863: 08336084004; 79585 Höllstein; 47.638097/7.745104 -> 47.820305/7.938546 (29.5 km) * 82127: 08437065006; 72505 Krauchenwies; 48.033333/9.25 -> 48.149846/9.484757 (29.1 km) From traut at gmx.de Mon Jan 21 08:26:39 2008 From: traut at gmx.de (Martin Trautmann) Date: Mon, 21 Jan 2008 08:26:39 +0100 Subject: [opengeodb] dump 02612: Ortsteile, Sachsen-Anhalt Message-ID: <4794492F.6050402@gmx.de> Hallo, der heutige opengeodb-dump enthält nun eine Fülle von Neuzugängen aus Deutschland. Ebenso wurde die große Kreisgebietsreform in Sachsen-Anhalt eingespielt. Daneben habe ich eine Reihe von Fehlern ausgemerzt. Sämtliche Änderungen sind in den Changes.html dokumentiert. Dies sind aber inzwischen mehrere tausend. Deshalb werden nun nur noch die letzten 100 Änderungen angezeigt. Ebenso zeigt jeder Einzeleintrag alle zugehörigen Änderungen. Nächste Aufgabe wäre, dass Fehler bei den Koordinaten schrittweise ausgemerzt würden. Bitte gebt mir Bescheid, sobald jemand die SQL-Daten geprüft hat, um wieder eine sourceforge-release zu machen. Die Straßendaten aus der OpenStreetMap sind NICHT in diesem Dump enthalten. Schönen Gruß Martin From traut at gmx.de Mon Jan 21 08:33:58 2008 From: traut at gmx.de (Martin Trautmann) Date: Mon, 21 Jan 2008 08:33:58 +0100 Subject: [opengeodb] dump 02612: Ortsteile, Sachsen-Anhalt In-Reply-To: <4794492F.6050402@gmx.de> References: <4794492F.6050402@gmx.de> Message-ID: <47944AE6.9070309@gmx.de> Martin Trautmann wrote: > Die Straßendaten aus der OpenStreetMap sind NICHT in diesem Dump enthalten. Daten aus der OpenStreetMap stehen unter der Creative Commons Attribution-ShareAlike 2.0 license http://creativecommons.org/licenses/by-sa/2.0/ Diese Daten werden bisher noch nicht in die Suche eingebunden. Wer aber schon einen ersten Eindruck von diesen Daten bekommen möchte, kann sich den URL schon selbst zusammenbasteln, indem er "DE" durch "DE9" ersetzt: Beispiele: Suche nach Straßen mit "freiburg" http://fa-technik.adfc.de/code/opengeodb.pl?ort=freiburg;c=DE9 Suche nach Straßen in Freiburg (locid 16633) http://fa-technik.adfc.de/code/opengeodb.pl?parts=16633;c=DE9 ... was Straßen zeigt, die noch keinem Ortsteil zugeordnet sind. Straßen in der Freiburger Altstadt (locid 81727) bekommt man mit http://fa-technik.adfc.de/code/opengeodb.pl?parts=81727;c=DE9 Schönen Gruß Martin From traut at gmx.de Mon Jan 21 12:37:18 2008 From: traut at gmx.de (Martin Trautmann) Date: Mon, 21 Jan 2008 03:37:18 -0800 (PST) Subject: [opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002) Message-ID: <14995797.post@talk.nabble.com> Hallo, die Struktur der opengeodb sieht derzeit vielerlei Schreibvarianten vor, speziell: INSERT INTO geodb_type_names VALUES(500100000,'de','Name'); INSERT INTO geodb_type_names VALUES(500100001,'de','ISO 3166 Alpha-2'); INSERT INTO geodb_type_names VALUES(500100002,'de','Sortiername'); INSERT INTO geodb_type_names VALUES(500100003,'de','ISO_3166_2'); http://surfnet.dl.sourceforge.net/sourceforge/opengeodb/Constants.txt beschreibt dazu: NAME 500100000 ISO_3166_1_ALPHA_2 500100001 NAME_7BITLC 500100002 // 7 Bit, Lower case ISO_3166_2 500100003 Ich vermute, meine derzeitige Implementierung ist hier falsch, denn ich verwende fuer 500100002 nicht lower case, sondern upper case. Was ist euch lieber, was ist besser? Ich selbst finde upper-case gewohnter, kann aber gerne auf lower case umstellen. Wofuer dient ein solcher Sortiername? Bei mir ist er vor allem auch ein Suchmerkmal, das schneller funktioniert, als ueber Gross-/Kleinschreibung, mit und ohne Umlaute. Mein naechster Fehler ist aber, dass ich hier die Schreibweise noch recht unberuehrt lasse. Daher kann der gleiche Ort dennoch in unterschiedlichen Schreibvarianten zu Problem fuehren. Was ist richtig? * ALT RUPPIN * ALT-RUPPIN * ALTRUPPIN Bisher belasse ich es hier bei der Originalschreibweise. Mein Vorschlag: alle Trennzeichen fallen in Zukunft heraus: Leerzeichen und Bindestriche. Was gehoert in den Sortiernamen aber hinein? Im Augenblick ist das ganz pragmatisch: Der Name (500100000) enthaelt eine uebliche Langversion des Namens (Beispiel: "Kehl am Rhein" oder "Kehl (Rhein)" zur Unterscheidung von "Kehl in Bayern"). Der Sortiername enthaelt nur die Kurzversion ("KEHL"), unterscheidet also in der Sortierung nicht ueber Namens-Zusaetze (was gerade bei der Sortierung nach mehr als einem Merkmal deutlich unterschiedliche Resultate ergibt). Ist das fuer euch ok? Die lange Schreibweise ist manchmal in der Gemeinde selbst nicht unbedingt gelaeufig: Bei Gemeindedaten entstammt diese Schreibvariante jenem Amt, das den amtlichen Gemeindeschluessel erstellt und dabei bei Bedarf durch Zusaetze verhindert, dass in diesem Verzeichnis gleichnamige Gemeinden aufgefuehrt werden. Was ist mit dem SQL-dump? Ist es ueberhaupt sinnvoll, die Datenmenge zum Austausch, Archivierung, Versionierung mit diesen Daten aufzublaehen, statt hier einen passenden SQL-Befehl aufzunehmen, der ueberall dort durch eine moeglichst einfache Regel den Typ 500100002 aus 500100000 berechnet, wo dies moeglich ist? Im SQL-Dump wuerden dann nur jene Daten uebergeben, wo nicht automatisch der Wert von 500100002 sich aus lower(500100000) ergeben wuerde? Und nach welchen aufwaendigeren Regeln sollte der Typ 500100002 bestimmt werden? Beispiele: * Amt Neuhaus -> "NEUHAUS" oder "AMTNEUHAUS" * Verwaltungsgemeinschaft Neuhaus -> "NEUHAUS" oder "VERWALTUNGSGEMEINSCHAFTNEUHAUS" * VG Neuhaus -> "NEUHAUS" oder "VGNEUHAUS" ... ich verwende hier bisher "NEUHAUS" * St. Peter-Ording -> "STPETER", "SANKTPETER", "SANKTPETERORDING", "STPETERORDING", ... * Schloss-Str. -> "SCHLOSSSTRASSE", "SCHLOSSTRASSE", "SCHLOSSSTR", "SCHLOSSSTR.", ... Was ist hier am sinnvollsten? Schoenen Gruss Martin -- View this message in context: http://www.nabble.com/ASCII-Schreibweise%3A-upper-lower%2C-mit-ohne-Trennzeichen%2C-kurz-lang-%28500100002%29-tp14995797p14995797.html Sent from the Php German - opengeodb mailing list archive at Nabble.com. From 922492 at gmx.de Mon Jan 21 16:43:06 2008 From: 922492 at gmx.de (Sascha Mantscheff) Date: Mon, 21 Jan 2008 16:43:06 +0100 Subject: [opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002) In-Reply-To: <14995797.post@talk.nabble.com> References: <14995797.post@talk.nabble.com> Message-ID: <4794BD8A.7080109@gmx.de> > Was ist mit dem SQL-dump? Ist es ueberhaupt sinnvoll, die Datenmenge zum > Austausch, Archivierung, Versionierung mit diesen Daten aufzublaehen, statt > hier einen passenden SQL-Befehl aufzunehmen, der ueberall dort durch eine > moeglichst einfache Regel den Typ 500100002 aus 500100000 berechnet, wo dies > moeglich ist? Im SQL-Dump wuerden dann nur jene Daten uebergeben, wo nicht > automatisch der Wert von 500100002 sich aus lower(500100000) ergeben wuerde? > Abgeleitete Daten gehören nicht in den Grunddatenbestand. Wenn der Typ 500100002 aus ...0 berechnet werden kann, sollte die Berechnungsvorschrift im Export enhalten sein. In MySQL kann man einen entsprechenden Trigger formulieren, der auch bei Updates für Datenintegrität sorgt. > Und nach welchen aufwaendigeren Regeln sollte der Typ 500100002 bestimmt > werden? > > Beispiele: > * Amt Neuhaus -> "NEUHAUS" oder "AMTNEUHAUS" > * Verwaltungsgemeinschaft Neuhaus -> "NEUHAUS" oder > "VERWALTUNGSGEMEINSCHAFTNEUHAUS" > * VG Neuhaus -> "NEUHAUS" oder "VGNEUHAUS" > > ... ich verwende hier bisher "NEUHAUS" > > * St. Peter-Ording -> "STPETER", "SANKTPETER", "SANKTPETERORDING", > "STPETERORDING", ... > * Schloss-Str. -> "SCHLOSSSTRASSE", "SCHLOSSTRASSE", "SCHLOSSSTR", > "SCHLOSSSTR.", ... > > Was ist hier am sinnvollsten? > Für sinnvoll halte ich: - mit Punkt abgekürzte Bestandteile ausschreiben - diakritische Zeichen normalisieren - alle nicht-alphabetischen Zeichen entfernen Ortsnamenszusätze nachstellen (NEUHAUSVERWALTUNGSGEMEINSCHAFT) Aber da es sich um abgeleitete Daten handelt, kann das ja sowieso jeder halten, wie er es am ehesten braucht. Nur wäre es eben schön, eine explizite Regel zu haben, die auch die sicherlich vorkommenden Sonderfälle berücksichtigt. In welcher Weise die DB-Nutzer diese Regel dann einbauen, ist eine Implementierungsfrage und sollte bei der Grunddatenpflege keine Rolle spielen. s.m. From list at lab.at Tue Jan 22 23:30:56 2008 From: list at lab.at (Andreas Labres) Date: Tue, 22 Jan 2008 23:30:56 +0100 Subject: [opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002) In-Reply-To: <14995797.post@talk.nabble.com> References: <14995797.post@talk.nabble.com> Message-ID: <47966EA0.7000700@al.lab.at> Martin Trautmann wrote: > Was ist euch lieber, was ist besser? Ich selbst finde upper-case gewohnter, > kann aber gerne auf lower case umstellen. Ländercodes (geografisch, ISO 3166): upper case Sprachcodes (sprachlich, ISO 639): lower case z.B. 'BE' ist Belgien, 'be' aber weißrussisch (auf http://de.wikipedia.org/wiki/ISO_3166 stehen weitere Beispiele) > Sortiernamen > Was ist hier am sinnvollsten? Ein paar Beispiele aus AT: "Gmünd" gibt es 4 Orte in Österreich (Bez. Gmünd in NÖ, Bez. Spittal an der Drau in K, Bez. Schwaz in T und Bez. Bregenz in V). Zwei haben eigene Postleitzahlen: 3950 Gmünd, Niederösterreich und 9853 Gmünd, Kärnten (so nennt die Post sie). Trotzdem sollte der Sortiername von allen "GMÜND" (wie immer der Umlaut zu kodieren ist) sein. Bei anderen Ortsnamen ist die nähere Ortsbestimmung aber Teil des Namens, z.B. "Neusiedl am See", "Neusiedl am Walde", "Neusiedl an der Zaya", "Neusiedl bei Güssing" oder "Matrei am Brenner", "Matrei in Osttirol" (z.B: Neusiedl *a*n der Zaya kommt vor Neusiedl *b*ei Güssing). St. sollte zum Sortieren SANKT bedeuten (dann Space, dann der weitere Name). /al From traut at gmx.de Tue Jan 22 23:41:57 2008 From: traut at gmx.de (Martin Trautmann) Date: Tue, 22 Jan 2008 23:41:57 +0100 Subject: [opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002) In-Reply-To: <47966EA0.7000700@al.lab.at> References: <14995797.post@talk.nabble.com> <47966EA0.7000700@al.lab.at> Message-ID: <47967135.2020507@gmx.de> Andreas Labres wrote: > Martin Trautmann wrote: >> Was ist euch lieber, was ist besser? Ich selbst finde upper-case gewohnter, >> kann aber gerne auf lower case umstellen. > > Ländercodes (geografisch, ISO 3166): upper case > Sprachcodes (sprachlich, ISO 639): lower case > > z.B. 'BE' ist Belgien, 'be' aber weißrussisch > (auf http://de.wikipedia.org/wiki/ISO_3166 stehen weitere Beispiele) Hallo Andreas, sprechen wir vom gleichen? > > Sortiernamen > > Was ist hier am sinnvollsten? > > Ein paar Beispiele aus AT: > > "Gmünd" gibt es 4 Orte in Österreich (Bez. Gmünd in NÖ, Bez. Spittal an der Drau > in K, Bez. Schwaz in T und Bez. Bregenz in V). Zwei haben eigene Postleitzahlen: > 3950 Gmünd, Niederösterreich und 9853 Gmünd, Kärnten (so nennt die Post sie). > Trotzdem sollte der Sortiername von allen "GMÜND" (wie immer der Umlaut zu > kodieren ist) sein. Die Hauptfrage ist, ob der Sortiername upper oder lower case sein sollte. Dass der Umlaut ausgeschrieben wird, ist ohnehin schon Voraussetzung. Es geht also darum, ob der Sortiername wie bis 0.2.4 "gmuend" oder wie seit 0.2.5 "GMUEND" sein sollte. Ich habe keine Ahnung, warum hier einmal die Kleinschreibung favorisiert wurde - ob das ein SQL-Standard wäre oder reine Willkür. Von der Verdeutlichung als ASCII halte ich Großbuchstaben für sinnvoll. Als Vorteil der Kleinbuchstaben fällt mir nur ein, dass man kein Shift oder Caps Lock drücken müsse... Schönen Gruß Marrtin From wendorff at uni-paderborn.de Tue Jan 22 23:51:03 2008 From: wendorff at uni-paderborn.de (Peter Wendorff) Date: Tue, 22 Jan 2008 23:51:03 +0100 Subject: [opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002) In-Reply-To: <47967135.2020507@gmx.de> References: <14995797.post@talk.nabble.com> <47966EA0.7000700@al.lab.at> <47967135.2020507@gmx.de> Message-ID: <47967357.5070904@uni-paderborn.de> Martin Trautmann schrieb: > Ich habe keine Ahnung, warum hier einmal die Kleinschreibung favorisiert > wurde - ob das ein SQL-Standard wäre oder reine Willkür. > Von der Verdeutlichung als ASCII halte ich Großbuchstaben für sinnvoll. > Als Vorteil der Kleinbuchstaben fällt mir nur ein, dass man kein Shift > oder Caps Lock drücken müsse... > Wenn sämtliche Sonderzeichen rausfallen, gebe ich Dir recht; allerdings verweise ich auf die Problematik mit ss und ß, die ja gerade in unserem Bereich, den deutschsprachigen Orts- und damit Eigennamen vorkommen. Bei Kleinbuchstaben dagegen existieren alle Zeichen (soweit ich weiß). Viele Grüße Peter From traut at gmx.de Wed Jan 23 00:00:27 2008 From: traut at gmx.de (Martin Trautmann) Date: Wed, 23 Jan 2008 00:00:27 +0100 Subject: [opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002) In-Reply-To: <47967357.5070904@uni-paderborn.de> References: <14995797.post@talk.nabble.com> <47966EA0.7000700@al.lab.at> <47967135.2020507@gmx.de> <47967357.5070904@uni-paderborn.de> Message-ID: <4796758B.5090400@gmx.de> Peter Wendorff wrote: > Wenn sämtliche Sonderzeichen rausfallen, gebe ich Dir recht Es fallen sämtliche Sonderzeichen raus - 7bit ASCII. Ich würde sogar so weit gehen, das ganze einzuschränken auf A-Z Allerdings würde damit aus einer "Straße der 1822er" eine "STRASSEDERER" > allerdings > verweise ich auf die Problematik mit ss und ß, die ja gerade in unserem > Bereich, den deutschsprachigen Orts- und damit Eigennamen vorkommen. ß wird zu SS, nicht etwa zu SZ. Es bleibt die Frage, was man aus einer Schloss-Straße macht. Doppel- oder Dreifach-S? "SCHLOSSTRASSE" Ich reduziere hier derzeit alle dreifach-S auf zweifach-S, unterlasse das aber bei anderen Buchstaben. > Bei Kleinbuchstaben dagegen existieren alle Zeichen (soweit ich weiß). Nicht in ASCII - und vermutlich gibt's auch irgend eine Sprache, wo manches nur gross oder klein vorkommt. Schönen Gruß Martin From iloetzsch at asci-systemhaus.de Wed Jan 23 09:50:07 2008 From: iloetzsch at asci-systemhaus.de (=?ISO-8859-1?Q?Ingmar_L=F6tzsch?=) Date: Wed, 23 Jan 2008 09:50:07 +0100 Subject: [opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002) In-Reply-To: <47966EA0.7000700@al.lab.at> References: <14995797.post@talk.nabble.com> <47966EA0.7000700@al.lab.at> Message-ID: <4796FFBF.2010005@asci-systemhaus.de> Egal, was rauskommt, ich empfehle etwas festzulegen, was auf einfachste Weise von einem Computer berechenbar ist - am besten ausschließlich mit SQL - und möglichst wenig Ausnahmen macht. - keine Buchstaben weglassen, etwa sss-> SS - keine Buchstaben hinzufügen, etwa St. -> SANKT Beim letzten Beispiel handelt es sich entweder um eine Abkürzung des offiziellen Namens - dann sollte dieser unabgekürzt gespeichert werden, etwa "Sankt" statt "St." - oder die offizielle Bezeichnung ist "St. ...". Dann wäre es wünschenswert, wenn man es bei St. -> ST belassen könnte. Es könnte sein, dass manche Gemeinden die Abkürzung als offizielle Bezeichnung festlegen, andere nicht. Dann könnte man die Forderung aufstellen, dass so sortiert wird, als würde überall dieselbe Varainte verwendet. Das ist durchaus plausibel, birgt aber die Gefahr, dass die Zahl dieser Ausnahmen anwächst und irgendwann unübersichtlich wird. From traut at gmx.de Wed Jan 23 13:55:19 2008 From: traut at gmx.de (Martin Trautmann) Date: Wed, 23 Jan 2008 13:55:19 +0100 Subject: [opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002) In-Reply-To: <4796FFBF.2010005@asci-systemhaus.de> References: <14995797.post@talk.nabble.com> <47966EA0.7000700@al.lab.at> <4796FFBF.2010005@asci-systemhaus.de> Message-ID: <47973937.1020701@gmx.de> Ingmar Lötzsch wrote: > Egal, was rauskommt, ich empfehle etwas festzulegen, was auf einfachste > Weise von einem Computer berechenbar ist - am besten ausschließlich mit > SQL - und möglichst wenig Ausnahmen macht. > > - keine Buchstaben weglassen, etwa sss-> SS > - keine Buchstaben hinzufügen, etwa St. -> SANKT Ja und nein - ein Dreh- und Angelpunkt ist, ob man den sortname überhaupt mitgeben muss. Ich würde sagen: nein. Ich gehe aber davon aus, dass man den sortname mitgeben kann - gerade in den Fällen, wo er nicht durch eine ganz einfache Regeln reproduziert werden kann wie Zeichensatz -> Großschrift Umlaute -> ausschreiben Bindestriche, Leerzeichen -> Löschen In allen komplizierteren Fällen ist der Sortname im export dump enthalten, nur in den einfachen sollte er automatisch generiert werden. Bei der Neuerstellung von Einträgen wird ein solcher sortname automatisch angelegt. Jeder hat die Freiheit, diesen nachzubessern. Auch solche Änderungen sind natürlich zulässig und mitzugeben. > Beim letzten Beispiel handelt es sich entweder um eine Abkürzung des > offiziellen Namens - dann sollte dieser unabgekürzt gespeichert werden, > etwa "Sankt" statt "St." - oder die offizielle Bezeichnung ist "St. > ...". Dann wäre es wünschenswert, wenn man es bei St. -> ST belassen könnte. Da unklar ist, ob und wann es offiziell ist, tendiere ich zum generellen ausschreiben, sprich Umwandlung in die Form, in der es auch ausgesprochen wird. Ich habe noch nie "ess-te-Bindestrich-Georg-Bindestrich-schtra-sse" gehört und würde das als Sortname "SANKTGEORGSTRASSE" verwenden wollen. > Es könnte sein, dass manche Gemeinden die Abkürzung als offizielle > Bezeichnung festlegen, andere nicht. Kannst du das den Daten selbst ansehen? Ortsnamen sind immerhin halbwegs bekannt und offiziell - aber schon bei den Zusätzen wird es beliebig willkürlich. Heisst es "Xyz / Westerwald", "Xyz im Westerwald", "Xyz am Westerwald", "Xyz (Westerwald)", "Xyz/WW", "Xyz WW." oder wie? Und das sind nur einige der Variationen um ein einziges Wort herum. Von den Straßen her habe ich einen rechtt großen Erfahrungsschatz, was offiziell beliebig falsch gehen kann. Solche Leute wie Gerhard/t Hauptmann haben es der Stadt noch zusätzlich schwer gemacht ;-) Was ist dann die Referenz? Der Stadtplan der Stadt, der Gemeindebeschluss zur (fehlerhaften) Benennung, die korrekte Schreibweise? Nur mal als Hausnummer: Ich habe mehr als 100 000 Ortseinträge. Bei einem Drittel davon habe ich lange Namensvarianten. Bei 1895 habe ich weitere Namensvarianten, z.B. gerade nach Namensänderungen wie Zugewinn des Status als Bad: Lobenstein, Thüringen Lobenstein, Moorbad Bad Lobenstein Lobenstein > Dann könnte man die Forderung > aufstellen, dass so sortiert wird, als würde überall dieselbe Varainte > verwendet. Das ist durchaus plausibel, birgt aber die Gefahr, dass die > Zahl dieser Ausnahmen anwächst und irgendwann unübersichtlich wird. So läuft's derzeit aber, wenn du mal sortname und name vergleichen möchtest. Bei manchen Einträgen bin ich mir nicht wirklich sicher - kannst du auf Anhieb beantworten, wie Hann. Münden ausgesprochen wird? Schönen Gruß Martin From list at lab.at Thu Jan 24 00:32:34 2008 From: list at lab.at (Andreas Labres) Date: Thu, 24 Jan 2008 00:32:34 +0100 Subject: [opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002) In-Reply-To: <4796758B.5090400@gmx.de> References: <14995797.post@talk.nabble.com> <47966EA0.7000700@al.lab.at> <47967135.2020507@gmx.de> <47967357.5070904@uni-paderborn.de> <4796758B.5090400@gmx.de> Message-ID: <4797CE92.7080707@al.lab.at> Martin Trautmann wrote: > Dass der Umlaut ausgeschrieben wird, ist ohnehin schon > Voraussetzung. Ok, also DIN-2. > Es geht also darum, ob der Sortiername wie bis 0.2.4 > "gmuend" oder wie seit 0.2.5 "GMUEND" sein sollte. IMO letzteres. > Ich würde sogar so weit gehen, das ganze einzuschränken auf A-Z > > Allerdings würde damit aus einer "Straße der 1822er" eine > "STRASSEDERER" Dann stimmt aber die Sortierreihenfolge (und um die geht's hier ja doch?) nimmer, z.B.: ... SCHLOSS WOLFSBERG SCHLOSS ZELLHOF kommt vor SCHLOSSAECKER SCHLOSSAU ... Ad Wortzeichen in der Sortierung: Von mir aus kann man überlegen, Bindestrich durch Leerzeichen zu ersetzen. Apostroph (so es vorkommt) müßte man weglassen. Der Abkürzungspunkt sollte wohl nur bei 'St.' vorkommen (ist als SANKT zu sortieren), sonstige Wort- oder Interpunktionszeichen dürften wohl nicht vorkommen. NB: SSS zu SS zu machen ist nicht korrekt (insbesondere [aber nicht nur] nicht nach der neuen Rechtschreibung): Schloßleiten SCHLOSSLEITEN vor Schloßsee SCHLOSSSEE Jedenfalls sollte man die Summe aller Regeln, wie man vom Begriff zum Sortierbegriff kommt, irgendwo gesammelt dokumentieren (und festschreiben). /al From list at lab.at Thu Jan 24 00:37:38 2008 From: list at lab.at (Andreas Labres) Date: Thu, 24 Jan 2008 00:37:38 +0100 Subject: [opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002) In-Reply-To: <47973937.1020701@gmx.de> References: <14995797.post@talk.nabble.com> <47966EA0.7000700@al.lab.at> <4796FFBF.2010005@asci-systemhaus.de> <47973937.1020701@gmx.de> Message-ID: <4797CFC2.5070508@al.lab.at> Martin Trautmann wrote: > Ja und nein - ein Dreh- und Angelpunkt ist, ob man den sortname > überhaupt mitgeben muss. Ich würde sagen: nein. ACK. /al From robert.boeck at googlemail.com Thu Jan 24 03:21:06 2008 From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=) Date: Thu, 24 Jan 2008 03:21:06 +0100 Subject: [opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002) In-Reply-To: <47973937.1020701@gmx.de> References: <14995797.post@talk.nabble.com> <47966EA0.7000700@al.lab.at> <4796FFBF.2010005@asci-systemhaus.de> <47973937.1020701@gmx.de> Message-ID: Martin Trautmann wrote: > Ja und nein - ein Dreh- und Angelpunkt ist, ob man den sortname > überhaupt mitgeben muss. Ich würde sagen: nein. Aber natürlich gehört er in den Dump mit rein. Ansonsten müsste man nach einem DB-Import den sortname erst umständlich mit einem Script bauen. Denn UPPER() bzw. LOWER() Ziel führen leider nicht zum Ziel mit den ganzen Sonderzeichen ... Im Übrigen finde ich die Diskussion, ob nun GROSSBUCHSTABEN oder kleinbuchstaben für den sortname verwendet werden sollen, müßig, weil es für die Sortiererei völlig wurscht ist. cu, Robo :)