Ok, die Diskussion hat ja einen ziemlich Umfang angenommen. Ich schreibe mal
was zu ein
paar Punkten.
a) Wo bekommt man freie Daten her wie Gemarkungen usw.?
Grundsätzlich sind Erstveröffentlichungen solcher Daten frei von
Urheberrechten. Das gilt
nicht für Daten, die von dem Eigner mit einem "gewissen Aufwand" und einer
gewissen
Eigenkreativität erstellt worden sind (Thema Schöpfungshöhe oder so ähnlich).
Für mich wäre es interessant zu erfahren, wo solche Daten erstveröffentlicht
werden, vielleicht
könnte opengeo solche Erstveröffentlichungen abonnieren. Das gilt z.B. auch für
Gemeinde=
restrukturierungen, wie Zusammenlegungen oder Mitgliedschaften in
Verwaltungsgemeinschaften
usw..
b) Eindeutige Schlüssel
Ich würde mich dagegen aussprechen, IRGENDEIN der ermittelten Attribute als
eindeutigen Schlüssel zu benutzen. Es wird immer irgendwelche Ausnahmen oder
Entwicklungen geben, die dagegensprechen. Schluessel sollten immer so etwas
wie integer oder auch char Felder sein, die nichts mit den abgefragten Werten zu
tun haben. Das sagt mir auch meine (wenige) Praxis...
c) Welche Daten sollen in DB enthalten sein?
- Koordinaten von "Lokalitäten"
- Die Bezeichnungen dieser "Lokalitaeten"
- Alternativbezeichnungen einschließlich Art dieser Alternative
- Typ der Lokalitaeten
- Die Beziehungen der Lokalitaeten untereinander
- Polygone von Lokalitaeten, wenn es Sinn macht
- Metainfos
Als "Lokalitaeten" kann eigentlich alles eingefügt werden, was man sich so
vorstellen
kann, usprünglich halt Orte und Ortsteile, dann PLZ, nationaltypische
Kennzeichen, wie
z.B. KFZ-Kennzeichen, dann z.B. auch Bundesländer oder Landkreise oder halt auch
Gemeindeschlüssel oder Gemarkungsnummern. Oder auch Berggipfel oder AV-Hütten,
was z.B. in Österreich Sinn machen könnte.
Die Lokalitäten können zusätzliche Attribute enthalten, wie z.B.
Gemeindeschlüssel /
Gemarkungsnummer (könnte man auch über Alternativnamen regeln oder), oder KFZ-
Kennzeichen oder PLZen, wenn diese nicht als eigene Lokalitäten erscheinen.
Höhenangaben,
Einwohnerzahlen etc. sind weitere mögliche Attribute, die man aufnehmen könnte
/sollte.
Wobei man bei Höhenangaben noch weitere Infos bräuchte, worauf sie sich
beziehen,
was vor allem in gebirgigeren Gegenden nötig ist. Auch andere Attribute dürften
Zusatzinfos gut gebrauchen können.
d) Anfragen und Ausrichtung der DB
Ich hatte die Datensammlung ursprünglich mal als ein reines Ortsverzeichnis
gedacht,
um über einen Ortsnamen die Koordinaten dieses Ortes herauszufinden.
Mittlerweile
scheint die ganze Aufmerksamkeit auf die PLZen abgedriftet zu sein, die ich
ursprünglich nur deshalb mit aufgenommen hatte, um Mehrdeutigkeiten nicht zu
hilflos ausgeliefert zu sein.
Die Zentrierung der Aufmerksamkeit auf die PLZen mag gerade modern sein, aber
ich
möchte ich die ursprüngliche Ausrichtung als KoordinatenDB von Orten nicht
verlieren.
e) Fehler und Mängel
Hmmm, es ist halt so, als wenn jemand fragt, wieviele Fehler hat Dein Programm?
Ich würde mal antworten: "Ich garantiere Dir, daß Fehler drin sind." Ich habe
mal
versucht auf etwa 100 gröbere Fehler in der DB geschätzt, erst gestern hatte ich
zufällig noch einen PLZ-Fehler gefunden (04880 statt 04895). Die Daten sind
"grob"
getestet, also liegen Orte in BW nicht irgendwo in SWH und in eine PLZ 78456
taucht
nicht in NDS auf. Aber die Grenzregionen und Schnittstellen haben noch immer
eine
gewisse Anfälligkeit für Fehler, was sich auch im obigen PLZ Beispiel zeigt:
ich habe
geschaut, ob 0488* PLZen einen zusammenhängenden Bereich bilden und 0489*
PLZen, und das haben sie wohl getan, aber trotzdem gab es diesen Fehler. Er war
so spontan nicht erkennbar. Auch kann es durchaus vorkommen, daß Orte fehlen -
einen solchen Fehler hatte ich neulich auch mal aufgedeckt. Oder daß Orte
schlicht
und einfach falsche Koordinaten haben, also z.B. mal 20 Kilometer danebenliegen.
WIe gesagt, ich schätze solche Fehler auf maximal 100 ein.
f) Master und "Slaves"
Braucht man überhaupt einen eindeutigen "Master"? Ich habe den Verdacht, daß das
nicht nötig ist. Es bieten sich vermutlich zwei Dinge an, als eine Art Master
zu fungieren:
die Koordinaten oder die (Bezeichnungen der) Lokalitäten. Das führt mich zu dem
Gedanken, die Redundanz einer Kombination dieser beiden Attribute in Kauf zu
nehmen,
und sie in eine einzige Relation zu packen.
Wenn man sie getrennt halten will, können wir den Vorschlag weiterverfolgen,
eine
Verbindungsrelation für beide Relationen zu benutzen.
g) Ortsteile
Die erstaunliche Anzahl von 26 Ortsteilen hat sich auf die fast ebenso
erstaunliche
Anzahl von 704 erhöht - Arne: magst Du irgendwann mal wieder Dein Skript zur
Übertragung der Developer DB in die Anwender-DB anwerfen?
Thomas
|
