OpenGeoDB: Unterschied zwischen den Versionen

OpenGeoDB & GISWiki - Das freie Portal für Geoinformatik (GIS)
Wechseln zu: Navigation, Suche
(2) DIE RELATIONEN IM DETAIL:)
 
(39 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Im Mittelpunkt des Projektes '''OpenGeoDB''' steht der Aufbau einer möglichst vollständigen Datenbank mit Geokoordinaten zu allen Orten und Postleitzahlen im deutschsprachigen Raum (D,A,CH).
+
__NOTOC__
  
Karten können direkt von [http://opengeodb.de http://opengeodb.de] bezogen werden. Einfach auf OpenGeoDB unter [http://opengeodb.hoppe-media.com/suche/index.php Ortsuche] den entsprechenden Ortsnamen eingeben und die dort angezeigte Karte (PNG-Format) abspeichern. Die Genehmigung zur Nutzung dieser Karten unter der [http://de.wikipedia.org/wiki/Wikipedia:Karten#OpenGeoDB GFDL]. Auch der [http://opengeodb.de/download/ Download] der Datenbank ist möglich.
 
  
== OpenGeoDB 0.2X Einführung in das Datenbank Layout==
+
<table width="100%"  border="0" cellspacing="6">
 
+
<!--
=== ÜBERBLICK ÜBER DIE RELATIONEN: ===
+
  <tr>
 
+
    <td colspan="2">
Die opengeodb Datenbank besteht z.Zt. vor allem aus den Relationen (Tabellen) <code>geodb_locations</code>, <code>geodb_hierarchies</code>, <code>geodb_coordinates</code> und <code>geodb_textdata</code>.
+
       <div style="margin: 0; margin-right:10px; border: 2px solid #dfdfdf; background-color:#FBD9F4;">{{Wartung}}</div>
 
+
  </td>
Die restlichen Relationen <code>geodb_floatdata</code>, <code>geodb_intdata</code>, <code>geodb_areas</code>, <code>geodb_polygons</code> und <code>geodb_type_names</code> spielen (noch) keine oder keine wesentliche Rolle.
+
  </tr>
 
+
-->
=== DIE RELATIONEN IM DETAIL: ===
+
  <tr align="left" valign="top">
 
+
    <td width="50%">
''geodb_locations:''<br />
+
<div style="margin: 0; margin-right:10px; border: 2px solid #dfdfdf; background-color:#FCF0E8;">{{Startseite OpenGeoDB}}</div>
 
+
    </td>
      create table geodb_locations (
+
    <td width="50%">
        loc_id              serial primary key,
+
<div style="margin: 0; margin-right:10px; border: 2px solid #dfdfdf; background-color:#E4FFE5;"> &nbsp; {{News OpenGeoDB}}</div>
        loc_type            integer not null
+
    </td>
          check (loc_type = CONTINENT or loc_type = STATE or
+
  </tr>
                  loc_type = NUTS_I or loc_type = NUTS_II or
+
</table>
                  loc_type = NUTS_III or loc_type = POL_DIVISION or
+
                  loc_type = POPULATED_AREA or loc_type = LOC_AREA_CODE)
+
      );
+
 
+
<blockquote> geodb_locations ist der eigentliche Aufhänger, der für jeden Ort einen einzigen Datensatz enthält. Hierin wird eine "loc_id" definiert, die diesen Ort auch in allen anderen Relationen (Tabellen) eindeutig identifiziert.
+
 
+
Weiter gibt es nur noch das Attribut <code>loc_type</code>, das aussagt, um was es hier eigentlich geht: Die Koordinaten / Geschichte / Daten usw. z.B. einer Ortschaft oder einer Postleitzahl usw..
+
 
+
</blockquote>
+
 
+
''geodb_hierarchies:''<br />
+
 
+
    create table geodb_hierarchies (
+
      loc_id              integer not null references geodb_locations,
+
      level                integer not null check (level>0 and level<=9),
+
      id_lvl1              integer not null,
+
      id_lvl2              integer,
+
      id_lvl3              integer,
+
      id_lvl4              integer,
+
      id_lvl5              integer,
+
      id_lvl6              integer,
+
      id_lvl7              integer,
+
      id_lvl8              integer,
+
      id_lvl9              integer,
+
      valid_since          date,
+
      date_type_since      integer,
+
      valid_until          date not null,
+
      date_type_until      integer not null
+
      check (
+
        (
+
          (level = 1 and /* loc_id = id_lvl1 and */
+
                          id_lvl2 is null and id_lvl3 is null and
+
                          id_lvl4 is null and id_lvl5 is null and
+
                          id_lvl6 is null and id_lvl7 is null and
+
                          id_lvl8 is null and id_lvl9 is null) or
+
          (level = 2 and /* loc_id = id_lvl2 and */
+
                          id_lvl1 is not null and id_lvl3 is null and
+
                          id_lvl4 is null and id_lvl5 is null and
+
                          id_lvl6 is null and id_lvl7 is null and
+
                          id_lvl8 is null and id_lvl9 is null) or
+
          (level = 3 and /* loc_id = id_lvl3 and */
+
                          id_lvl1 is not null and id_lvl2 is not null and
+
                          id_lvl4 is null and id_lvl5 is null and
+
                          id_lvl6 is null and id_lvl7 is null and
+
                          id_lvl8 is null and id_lvl9 is null) or
+
          (level = 4 and /* loc_id = id_lvl4 and */
+
                          id_lvl1 is not null and id_lvl2 is not null and
+
                          id_lvl3 is not null and id_lvl5 is null and
+
                          id_lvl6 is null and id_lvl7 is null and
+
                          id_lvl8 is null and id_lvl9 is null) or
+
          (level = 5 and /* loc_id = id_lvl5 and */
+
                          id_lvl1 is not null and id_lvl2 is not null and
+
                          id_lvl3 is not null and id_lvl4 is not null and
+
                          id_lvl6 is null and id_lvl7 is null and
+
                          id_lvl8 is null and id_lvl9 is null) or
+
          (level = 6 and /* loc_id = id_lvl6 and */
+
                          id_lvl1 is not null and id_lvl2 is not null and
+
                          id_lvl3 is not null and id_lvl4 is not null and
+
                          id_lvl5 is not null and id_lvl7 is null and
+
                          id_lvl8 is null and id_lvl9 is null) or
+
          (level = 7 and /* loc_id = id_lvl7 and */
+
                          id_lvl1 is not null and id_lvl2 is not null and
+
                          id_lvl3 is not null and id_lvl4 is not null and
+
                          id_lvl5 is not null and id_lvl6 is not null and
+
                          id_lvl8 is null and id_lvl9 is null) or
+
          (level = 8 and /* loc_id = id_lvl8 and */
+
                          id_lvl1 is not null and id_lvl2 is not null and
+
                          id_lvl3 is not null and id_lvl4 is not null and
+
                          id_lvl5 is not null and id_lvl6 is not null and
+
                          id_lvl7 is not null and id_lvl9 is null) or
+
          (level = 9 and /* loc_id = id_lvl9 and */
+
                          id_lvl1 is not null and id_lvl2 is not null and
+
                          id_lvl3 is not null and id_lvl4 is not null and
+
                          id_lvl5 is not null and id_lvl6 is not null and
+
                          id_lvl7 is not null and id_lvl8 is not null)
+
          ) and
+
          (
+
            (valid_since is null and date_type_since is null) or
+
            (valid_since is not null and date_type_since is not null)
+
          )
+
      )
+
    );
+
 
+
<blockquote> geodb_hierarchies enthält die hierarchischen Strukturen, in der ein Ort wiederzufinden ist. Dafür finden sich in ihr neun Attribute mit den Namen id_lvl1 bis id_lvl9, in der die loc_ids aller neun Ebenen aufzufinden sind. Beispiel für den Ort mit der loc_id 27431 (Karwitz):
+
 
+
       104 105 116 176 351 19122 27431 null null
+
 
+
  id_lvl1 (104):    Europa
+
  id_lvl2 (105):    Deutschland
+
  id_lvl3 (116):    Niedersachsen
+
  id_lvl4 (176):    Regierungsbezirk Lüneburg
+
  id_lvl5 (351):    Landkreis Lüchow-Dannenberg
+
  id_lvl6 (19122):  Samtgemeinde Dannenberg (Elbe)
+
  id_lvl7 (27431):  Karwitz
+
  id_lvl8 (null):  -
+
  id_lvl9 (null):  -
+
 
+
Das Attribut mit dem Namen "level" bezeichnet die Ebene, in der dieser Ort steht. Die Ebene 6 bezeichnet normale (eigenständige) Orte, die Ebene 7 Orts- oder Stadtteile. Ein Eintrag mit der Ebene 2 wäre ein ganz normaler Staat.
+
 
+
</blockquote>
+
 
+
''geodb_coordinates, geodb_textdata, geodb_floatdata, geodb_intdata:''<br />
+
 
+
    create table geodb_coordinates (
+
      loc_id              integer not null references geodb_locations,
+
      lon                  double precision,
+
      lat                  double precision,
+
      sin_lon              double precision,
+
      sin_lat              double precision,
+
      cos_lon              double precision,
+
      cos_lat              double precision,
+
      coord_type          integer not null check (coord_type=WGS84),
+
      coord_subtype        integer,
+
      valid_since          date,
+
      date_type_since      integer,
+
      valid_until          date not null,
+
      date_type_until      integer not null
+
    );
+
 
+
    create table geodb_textdata (
+
      loc_id              integer not null references geodb_locations,
+
      text_val            varchar(255) not null, /* varchar(2000)? */
+
      text_type            integer not null,
+
      text_locale          varchar(5), /* ISO 639-1 */
+
      is_native_lang      smallint(1),
+
      is_default_name      smallint(1),
+
      valid_since          date,
+
      date_type_since      integer,
+
      valid_until          date not null,
+
      date_type_until      integer not null,
+
        check (
+
          (
+
            (
+
              (text_type = NAME    or text_type = NAME_7BITLC    or
+
                text_type = NAME_VG or text_type = NAME_VG_7BITLC or
+
                text_type = SOURCE  or text_type = COMMENT
+
              ) and
+
              text_locale like '__%' and
+
              is_native_lang is not null and
+
              is_default_name is not null
+
            ) or
+
            (
+
              (text_type = ISO_3166_1_ALPHA_2 or text_type = ISO_3166_2 or
+
                text_type = AREA_CODE          or text_type = CAR_LICENSE_CODE or
+
                text_type = CAR_LIC_CODE_NAME
+
              ) and
+
              text_locale is null and
+
              is_native_lang is null and
+
              is_default_name is null
+
            )
+
          ) and
+
            (
+
              (valid_since is null and date_type_since is null) or
+
              (valid_since is not null and date_type_since is not null)
+
            )
+
        )
+
    );
+
 
+
    create table geodb_intdata (
+
      loc_id              integer not null references geodb_locations,
+
      int_val              bigint not null,
+
      int_type            integer not null,
+
      int_subtype          integer,
+
      valid_since          date,
+
      date_type_since      integer,
+
      valid_until          date not null,
+
      date_type_until      integer not null
+
    );
+
 
+
    create table geodb_floatdata (
+
      loc_id              integer not null references geodb_locations,
+
      float_val            double precision not null,
+
      float_type          integer not null,
+
      float_subtype        integer,
+
      valid_since          date,
+
      date_type_since      integer,
+
      valid_until          date not null,
+
      date_type_until      integer not null
+
    );
+
 
+
<blockquote> In diesen Relationen finden sich die eigentlichen Daten eines Ortes.
+
 
+
Während geodb_coordinates nicht wesentlich mehr als nur die Längen- und Breitengrade eines Ortes enthält, sind die anderen drei Relationen "Universalbehälter", in die man alle Daten packen kann, die in das jeweilige Format (Text / Fließkommazahl / Ganzzahl) passen.
+
 
+
Der tatsächliche Inhalt eines Datensatzes bestimmt sich über den jeweiligen "Typ" im Attribut text_type bzw. float_type oder int_type.
+
 
+
Wenn man also z.B. den Namen eines Ortes auslesen möchte, dann braucht man eine Abfrage in der Form:
+
 
+
    SELECT text_val
+
    FROM geodb_textdata
+
    WHERE text_type=500100000 /* NAME */ AND
+
          loc_id=27431;
+
 
+
geodb_textdata enthält z.Zt. die Typen Name, Name in 7 Bit ASCII und Kleinschrift (zum Sortieren), Name eines Verwaltungszusammenschlusses und das gleiche wieder in 7 Bit usw., dann ISO Codes für die Länder und Provinzen (Bundesländer, Kantone usw. usf.), Postleitzahl, Autokennzeichen, Amtlicher Gemeindeschlüssel und testhalber Datenursprung (Source) und Kommentare.
+
 
+
geodb_floatdata enthält noch keine Daten, könnte aber z.B. die Flächengrößen o.ä. mit aufnehmen.
+
 
+
geodb_intdata enthält bislang nur Testdaten, und zwar ein paar Einwohnerzahlen. Auch hier sind andere Daten wie z.B. Höhenangaben möglich.
+
 
+
</blockquote>
+
 
+
''geodb_type_names:''<br />
+
 
+
    create table geodb_type_names (
+
      type_id              integer not null,
+
      type_locale          varchar(5) not null,
+
      name                varchar(255) not null,
+
    unique (type_id, type_locale)
+
    );
+
 
+
<blockquote> Diese Relation sollte Bezeichner für die Typen in den "Universalrelationen" geodb_textdata etc. enthalten. In wieweit das sinnvoll, ist mir noch nicht ganz klar. Mehr als ein paar (nicht gepflegte) Testdaten enthält sie aber noch nicht.
+
 
+
</blockquote>
+
 
+
''geodb_areas, geodb_polygons:''<br />
+
 
+
<blockquote> Auch diese Relationen enthalten noch keine Daten. Vermutlich werden auch die Attribute dieser Relationen noch geändert bis dort Daten erscheinen werden. Es geht im Endeffekt darum, dort Vektordaten ablegen zu können, also vor allen die Grenzen von Ländern oder Gemeinden oder Ortschaften oder Postleitzahlen: was auch immer.
+
 
+
</blockquote>
+
----
+
 
+
=== 3) DIE SQL PRAXIS: ===
+
 
+
==== 3.1) EINFÜHRUNG: Alle Ortsnamen mit Postleitzahl ====
+
 
+
Das obige SQL Beispiel zeigt eine sehr limitierte Anfrage, die in vielen Fällen nicht ausreichend ist.
+
 
+
Lassen wir uns zum Anfang mal alle Ortsnamen mit ihren Postleitzahlen ausgeben:
+
 
+
    SELECT plz.text_val as "PLZ", name.text_val as "Ort"
+
    FROM geodb_textdata plz, geodb_textdata name
+
    WHERE name.loc_id=plz.loc_id AND
+
          plz.text_type=500300000 /* PLZ */ AND
+
          name.text_type=500100000 /* NAME */
+
    ORDER by 2;
+
 
+
Erst einmal benötigen wir ZWEI ''VERSCHIEDENE'' Datensätze aus der geodb_textdata, nämlich einmal einen Datensatz, der die ''Postleitzahl'' enthält, ein anderes Mal den Datensatz, der den ''Namen'' des Ortes enthält. Aus diesem Grunde brauchen wir geodb_textdata ZWEIMAL in der FROM Klausel. Zur (notwendigen) Unterscheidung bennenen wir sie, hier der Übersicht halber mit "plz" und "name".
+
 
+
Aus der ersten geodb_textdata lesen wir die Postleitzahl aus, deshalb:
+
 
+
    SELECT plz.text_val as "plz" [...] FROM geodb_textdata plz
+
 
+
Aus der zweiten geodb_textdata lesen wir den Namen des Ortes aus, also:
+
 
+
    SELECT [...], name.text_val as "name" FROM [...], geodb_textdata name
+
 
+
Natürlich sollen die Postleitzahl und der Name sich auf den gleichen Ort beziehen, der ja - wie oben kurz beschrieben - eindeutig durch eine loc_id gekennzeichnet ist. Also kommt in die WHERE Klausel:
+
 
+
  ... WHERE name.loc_id=plz.loc_id [...]
+
 
+
Dann soll die als "plz" benannte Relation natürlich NUR Postleitzahlen auslesen, die wir über den text_type erkennen. Also geht es weiter mit:
+
 
+
  ... WHERE [...] AND plz.text_type=500300000 /* PLZ */ [...]
+
 
+
In der gleichen Weise soll aus der zweiten geodb_textdata Relation nur der NAME des Ortes ausgelesen werden, also heißt es:
+
 
+
  ... WHERE [...] AND name.text_type=500100000 /* NAME */
+
 
+
==== 3.2) FÜR FORTGESCHRITTENE: Postleitzahlen und Orte von Liechtenstein ====
+
 
+
Na gut, das waren jetzt vielleicht doch etwas viele Orte, wie wäre es, wenn wir uns auf alle Orte in Liechtenstein beschränken?
+
 
+
Hier müssen wir in die geodb_hierarchies schauen, weil nur dort erkennbar ist, in welcher politischen Hierarchie dieser Ort steht.
+
 
+
Erst einmal benötigen wir die id_lvl2 aus der geodb_hierarchies, denn das bezeichnet die <code>loc_id</code> des Staates aller Orte:
+
 
+
  ... WHERE id_lvl2=???
+
 
+
Ja gut, aber welchen Wert soll id_lvl2 haben? Oder anders gefragt: Was ist die loc_id des Ortes, das z.B. den ISO Code "FL" (== Fürstentum Liechtenstein) hat? Kein Problem:
+
 
+
    SELECT [...] geodb_textdata.loc_id
+
    FROM geodb_textdata
+
    WHERE text_val='FL' AND
+
              text_type=500100001 /* ISO Code */
+
 
+
Oder zusammengebastelt:
+
 
+
    SELECT ...
+
    FROM geodb_hierarchies hi, geodb_textdata land
+
    WHERE hi.id_lvl2=land.loc_id AND
+
          land.text_val='FL' AND
+
          land.text_type=500100001 /* ISO 3166 */
+
 
+
Jetzt wollen wir aber noch den Namen des Ortes (aus geodb_textdata) auslesen, den wir aber nicht in der geodb_textdata land finden. Also müssen wir nochmal eine geodb_textdata spendieren, diesmal soll der text_type der ''Name'' sein und ''irgendwo'' in der Hierarchie stehen, die als Bedingung hatte, daß der Staat 'FL' sei:
+
 
+
  ... WHERE [...] ort.loc_id = hi.loc_id AND
+
          ort.text_type = 500100000 /* NAME */
+
 
+
Und jetzt alles zusammen:
+
 
+
    SELECT ort.text_val
+
    FROM geodb_hierarchies hi, geodb_textdata land, geodb_textdata ort
+
    WHERE hi.id_lvl2=land.loc_id AND
+
          land.text_val='FL' AND
+
          land.text_type=500100001 /* ISO 3166 */ AND
+
          ort.loc_id = hi.loc_id AND
+
          ort.text_type = 500100000 /* NAME */
+
 
+
Jetzt fehlt uns noch die Postleitzahl, die noch einen weiteren geodb_textdata Datensatz erfordert, dann sieht das alles zusammen etwa so aus:
+
 
+
    SELECT plz.text_val, ort.text_val
+
    FROM geodb_hierarchies hi,
+
          geodb_textdata land,
+
          geodb_textdata ort,
+
          geodb_textdata plz
+
    WHERE hi.id_lvl2=land.loc_id AND
+
          land.text_val='FL' AND
+
          land.text_type=500100001 /* ISO 3166 */ AND
+
          ort.loc_id = hi.loc_id AND
+
          ort.text_type = 500100000 /* NAME */ AND
+
          plz.loc_id = ort.loc_id AND
+
          plz.text_type = 500300000 /* PLZ */
+
 
+
"Verhübschen" wir es noch etwas:
+
 
+
    SELECT plz.text_val as "PLZ",
+
            concat(concat(land.text_val,'-'),ort.text_val) as "Name"
+
    FROM geodb_hierarchies hi,
+
          geodb_textdata land,
+
          geodb_textdata ort,
+
          geodb_textdata plz
+
    WHERE hi.id_lvl2=land.loc_id AND
+
          land.text_val='FL' AND
+
          land.text_type=500100001 /* ISO 3166 */ AND
+
          ort.loc_id = hi.loc_id AND
+
          ort.text_type = 500100000 /* NAME */ AND
+
          plz.loc_id = ort.loc_id AND
+
          plz.text_type = 500300000 /* PLZ */
+
    ORDER BY 2
+
 
+
(Postgres Nutzer ersetzen die Vorkommen von concat durch textcat)
+
 
+
Schwierig? Ich tendiere eher zu einem ''"komplex!"''...
+
 
+
==== 3.3) VIEL ZU EINFACH: Alle Kantone der Schweiz ====
+
 
+
''Ja, aber??? Das hatten wir doch gerade?'' -- Stimmt!
+
 
+
Nur diesmal wollen wir das ISO Kürzel anstelle der Postleitzahlen ausgeben, suchen zur Abwechselung nach dem Begriff "Suisse" (also text_type = Name, d.h. 500100000):
+
 
+
    SELECT iso.text_val as "ISO",
+
            name.text_val as "Name"
+
    FROM geodb_hierarchies hi,
+
          geodb_textdata land,
+
          geodb_textdata name,
+
          geodb_textdata iso
+
    WHERE hi.id_lvl2=land.loc_id AND
+
          land.text_val='Suisse' AND
+
          land.text_type=500100000 /* NAME */ AND
+
          name.loc_id = hi.loc_id AND
+
          name.text_type = 500100000 /* NAME */ AND
+
          iso.loc_id = name.loc_id AND
+
          iso.text_type = 500100001 /* ISO 3166 */
+
 
+
Nanu, nanu: wir haben nicht nur die Kantone, sondern auch die Schweiz selber? Das können wir zusätzlich ausschließen, wenn wir sagen, daß die Ebene der von geodb_hierarchies gelieferten Daten ausschließlich drei sein soll (drei == Kantone / Bundesländer etc.), also:
+
 
+
    WHERE ... AND level = 3 ...
+
 
+
Einfacher und direkter geht es aber, wenn wir nicht nach <code>name.loc_id = hi.loc_id</code> schauen (was uns unabhängig von der Ebene ALLE Lokalitäten ausgibt), sondern nach <code>name.loc_id = hi.''id_lvl3''</code><nowiki>: </nowiki>
+
 
+
    SELECT iso.text_val as "ISO",
+
            name.text_val as "Name"
+
    FROM geodb_hierarchies hi,
+
          geodb_textdata land,
+
          geodb_textdata name,
+
          geodb_textdata iso
+
    WHERE hi.id_lvl2=land.loc_id AND
+
          land.text_val='Suisse' AND
+
          land.text_type=500100000 /* NAME */ AND
+
          name.loc_id = hi.id_lvl3 AND
+
          name.text_type = 500100000 /* NAME */ AND
+
          iso.loc_id = name.loc_id AND
+
          iso.text_type = 500100001 /* ISO 3166 */
+
 
+
=== 4) SPEZIALFÄLLE UND ANDERE ANMERKUNGEN: ===
+
 
+
==== 4.1) Datum der Gültigkeit: ====
+
 
+
Alle Daten sind mit einem Gültigkeitsdatum versehen. Diese sind in den Attributen valid_since, date_type_since, valid_until und date_type_until in fast allen Relationen vorhanden.
+
 
+
date_type_since / date_type_until enthalten die Angabe, wie genau das angegebene Datum zu interpretieren ist, also als exakt oder z.B. als "In dem Jahr ..." usw.. Öfter wird man auf den Typ UNKNOWN_FUTURE_DATE (300500000) treffen, der angibt, daß die Gültigkeit noch nicht abgelaufen ist.
+
 
+
UNKNOWN_FUTURE_DATE geht immer einher mit dem Datum 1.1.3000, so daß man bei Fragen nach aktuellen Daten immer die Frage stellen kann:
+
 
+
  ... WHERE valid_until >= [heute]
+
 
+
Eine Ausnahme bilden die Fragen nach den Einwohnerzahlen, weil sie sich ja auf Zeit-PUNKTE beziehen und nicht auf Zeiträume. Wie die Datumsangaben dort einzutragen sind, ist für mich noch nicht endgültig geklärt, zumal es bislang noch keine wesentlichen Daten dazu gibt.
+
 
+
==== 4.2) Besondere Atribute in geodb_textdata: ====
+
 
+
Um es zu ermöglichen, mehrere Namen für einen Ort angeben zu können, z.B. München / Munich oder België / Belgique, gibt es in geodb_textdata ein Attribut mit dem Namen text_locale.
+
 
+
Da es meistens sinnvoller ist, nicht ALLE möglichen Namen auszugeben, sondern nur die Namen, die an dem Ort auch in Gebrauch sind, wurde ein weiteres Attribut eingeführt: is_native_lang gibt an, ob diese Sprache auch am Ort üblich ist.
+
 
+
Mehrere Namen erzeugen aber noch ganz andere Probleme. Oftmals (meistens) möchte man nur einen einzigen eindeutigen Namen erhalten. Die Rückgabe mehrerer Namen kann Anwendungen extrem verkomplizieren. Deshalb gibt es noch ein Attribut in geodb_textdata mit dem Namen 'is_default_name'. Es ist garantiert, dass dieses Attribut entweder null ist oder aber eindeutig für einen bestimmten Ort und einem bestimmten text_type.
+
 
+
Auf diese Weise kann man mit der Klausel:
+
 
+
  ... AND is_default_name = 1
+
 
+
beim text_type=NAME etc. garantieren, daß man nur einen, und zwar den sinnvollsten Namen zurückbekommt.
+
 
+
Da es ein paar Situationen gibt, bei denen man keinen wirklich perfekten Namen finden kann, z.B. bei Europa, wird im Zweifelsfall vorzugsweise auf den englischen Namen ausgewichen. So würde man bei Europa und der Abfrage auf '... is_default_name = 1' 'Europe' als Antwort bekommen, was möglicherweise nicht gewünscht ist, wenn man z.B. eine deutsche WWW-Seite betreibt.
+
 
+
In diesem Fall müsste man formal gesehen auf eine "Exklusiv-Oder" Bedingungen ausweichen, die es einem ermöglichten, die deutsche Sprache zu wählen, WENN es einen Eintrag in deutscher Sprache gibt UND WENN es eine Sprache an diesem Ort ist (is_native_lang = 1) ODER WENN das nicht der Fall ist, dann den default_name zu nehmen.
+
 
+
Da Exklusiv-Oder Bedingungen aber nicht zu einem frühen SQL-Standard gehören, kann es sein, daß man diese Konstruktion per Anwendungsprogramm nachbilden müßte: das wäre sehr aufwendig.
+
 
+
==== 4.3) geodb_coordinates ist Beta: ====
+
 
+
4.3.1) Diese Relation ist z.Zt. sehr aufgebläht mit abgeleiteten Werten wie sin_lon usw. usf.. Der Sinn war, Anfragen z.B. nach Entfernungen zu anderen Orten zu beschleunigen, indem man diese vorgefertigten Sinus und Cosinus Werte nutzen konnte.
+
 
+
Es sieht allerdings in der Praxis nicht so aus, als würde der Nachteil der stark aufgeblähten Relation den Vorteil möglicherweise etwas schnellerer Anfragen aufwiegen.
+
 
+
Das ist ein Grund dafür, weshalb ich erwäge, dieses vier Attribute aus geodb_coordinates wieder zu entfernen.
+
 
+
4.3.2) Das Attribut coord_type enthält den Typ der Koordinaten, also in unseren Fall WGS84. Das macht nur dann Sinn, wenn man andere Koordinatentypen zulassen wollte, z.B. UTM oder welche Projektionsart auch immer. Auf der anderen Seite wären diese anderen Koordinatentypen auch wieder nur abgeleitete Daten, die vor allem die Datenbank aufblasen, ohne einen wesentlichen Informationszugewinn zu bringen.
+
 
+
Deshalb denke ich darüber nach, coord_type ebenfalls aus dieser Relation zu entfernen (und coord_subtype in coord_type umzubenennen
+
 
+
 
+
[[Kategorie:freie Geodaten]]
+

Aktuelle Version vom 19. Dezember 2015, 11:35 Uhr


Bearbeiten

Beschreibung des Projekts

Im Mittelpunkt des Projektes OpenGeoDB steht der Aufbau einer möglichst vollständigen Datenbank mit Geokoordinaten zu allen Orten und Postleitzahlen (bisher: A,B,CH,D und FL). Dies soll vor allem durch die Beteiligung von möglichst vielen Personen geschehen, die diese zentrale Datenbank pflegen.

Lizenz

Die Datensammlung darf im Rahmen der Gemeinfreiheit [1] benutzt werden. Jeder der Daten zu dieser Datenbank beiträgt, stellt diese ebenfalls unter den genannten Bedingungen frei.

→ Die Daten können also "einfach so" benutzt werden. Über Spenden in Form von aktualisierten und neuen Datensätzen freuen wir uns sehr.

Status/Fortschritt des Projekts

Die Daten werden immer weiter vervollständigt. Eine Garantie für ein komplettes Verzeichnis aller Postleitzahlen, Städte und Gemeinden ist stets das Ziel, ist aber derzeit noch nicht überall gegeben. Für den normalen Gebrauch sind die Daten für Deutschland aber ausreichend. Wer umfangreiche Datenbestände importieren möchte, wende sich am Besten an die Mailingliste.

Suchen und bearbeiten der Datenbestände: http://fa-technik.adfc.de/code/opengeodb.pl

Mitmachen

Wenn Sie selbst etwas zu diesem Projekt beitragen (Datenpflege und/oder Software-Entwicklung) oder sich einfach nur über die aktuelle Entwicklung auf dem Laufenden halten möchten, melden Sie sich bitte bei unserer Mailingliste an [2]. Auf diese Liste kann auch mit einem Newsreader über das Gmane-Gateway lesend und schreibend zugegriffen werden [3].

Rückmeldung

Wir würden gerne erfahren, ob und in welchen Projekten OpenGeoDB bzw. GeoClass bereits genutzt wird. Über entsprechende Mitteilungen per E-Mail freuen wir uns. Bitte teilen Sie uns dabei auch mit, ob das Projekt auf dieser Seite veröffentlicht werden darf, oder fügen Sie es der Liste hier selbst hinzu.

Aktuelle Diskussion(en)

In der Mailing-Liste wird aktuell über die endgültige Einführung eines WIKIs sowie über ein Admin-Tool für Geodaten diskutiert. Um die Diskussionsfortschritte zusammenzufassen, benutzen Sie bitte die entsprechenden Seiten und deren Diskussionsbereich.
  Bearbeiten

Aktuelles

19.11.2015

Update des Mediawikis auf Version 1.25

14.03.2012 - Code-Beispiele

Per E-Mail erreichten mich heute ein paar Code-Beiträge : getProvinceByZipCode(), getCityByZipCode(), getProvinces(). Herzlichen Dank an Herrn Figge.

04.01.2012 - Benutzerberechtigungen

ConfirmEdit Erweiterung für die Spamabwehr sowie E-Mail-Authentifizierung bei Neuameldungen implementiert.

03.01.2012 - Weiterführung des OpenGeoDB Wikis

  • Für die Finanzierung des Projektes konnte eine wesentlich günstigere Lösung gefunden werden.
  • Update der Software MediaWiki von Version 1.11 auf 1.18.

11.2011 - Einstellung des OpenGeoDB Wikis

07-11-2009 opengeodb.hoppe-media.com-Wiki zieht auf dieses Wiki

Bitte habt etwas Geduld: die Inhalte werden soweit wie möglich auf diesem Wiki zusammen gezogen, da das dortige alte Wiki anscheinend ein Sicherheitsleck hatte.

18-06-2007 opengeodb-wiki

Seit einigen Wochen läuft auf fa-technik.adfc.de/code der Testbetrieb mit einem einfachen opengeodb-wiki. Dort sind jederzeit Änderungen möglich und aktuelle Datenbestände abrufbar. Die Datenstruktur wurde zur Version opengeodb 0.2.5.0 erweitert (z.B. neue Datenypen "Teil von" und "Typ").

01-12-2006 Wiki-Datenbankräumung

Die OpenGeoDB-Wiki-Datenbank wurde aufgeräumt. Ein Großteil der Artikel, die aus dem GISWiki mit übernommen wurden, sind gelöscht worden.

19-03-2006 infoOGDB – Ein Browser für OpenGeoDB

infoOGDB ist eine Sammlung von PHP-Scripten zum Sichten der Daten und deren grafischen Darstellung.

... mehr

14-03-2006

Die 0.2.4d Version ist draußen

  • Zusammenlegungen DE-Sachsen-Anhalt komplettiert

01-03-2006 OpenGeoNearestNeighbours – Eine Umkreissuche für OpenGeoDB

OpenGeoNearestNeighbours ist eine Sammlung von PHP-Klassen und einer Beispielanwendung mit deren Hilfe eine Umkreissuche realisiert werden kann.

... mehr

28-02-2006 Logowettbewerb

Dem Projekt OpenGeoDB fehlt derzeit ein Logo, unter dem man es sofort erkennen kann. Manuel, der Initiator von OpenGeoDB ruft alle "Designer" dazu auf, Vorschläge zu erarbeiten und diese bis zum 15. März an ihn zu schicken. In einer Wahl wird dann das endgültige Logo gewählt

E-Mail an Manuel

13-02-2006

Die 0.2.4c Version ist draußen

  • bessere Datenkonsistenz,
  • Sachsen-Anhalt Eingemeindungen und Verwaltungsgemeinschaften,

08-02-2006 - Mobiles GIS

OpenGeoDB goes Mobile mit OpenGeoDB Mobile.

08-02-2006

Die 0.2.4b Version ist draußen

  • neue Daten (Landkreis Hildburghausen),
  • Ergänzungen von Einwohnerzahlen in Deutschland (ca. 5675 Stück)
  • Ergänzungen und Korrekturen im Rahmen der Gemeindereformen Sachsen-Anhalt
  • sowie Korrekturen und Ergänzungen im Rahmen von Konsistenzprüfungen.

07-02-2006 - Diskussionen zur Erweiterung der Datenbank

Aktuell wird wieder einmal die Erweiterung der OpenGeoDB-Datenbank diskutiert.

07-02-2006 - Spenden

Sollen Arbeiten an der OpenGeoDB über Spenden finanziert werden?

07-02-2006 - Brainstorming Admintool zur Geodatenpflege

Das Brainstorming soll dazu dienen, alle gewünschten Funktionalitäten zu sammeln. Auf dieser Basis kann eine Art Lastenheft erstellen werden.