E00-Dateien für einzelne Bundesländer mit Landkreisen

[Steffen Karsch]

Ich hätte eine Frage aus dem Bereich Visualisierung!

Ich möchte gerne ein einzelnes Bundesland mit den dazugehörigen Landkreisen
darstellen;

es sollte ja auch möglich sein durch extrahieren einzelner Sektionen der
ponet.e00 und germany_staatline.e00

z.B. nur die Konturen eines Bundeslandes zu zeichnen!

Mittels der ecadmll.e00 kann man ja auch ganz Deutschland mit seinen
Landkreisen zeichnen,

die Karte ist mir aber entschieden zu groß und Sektionen aus der ecadmll.e00

zu extrahieren bzw. zu identifizieren ist glaube ich (fast) unmöglich bzw.
ein

nicht gerechtfertiger Aufwand! Nun wollte ich die Frage aufwerfen, ob jemand

E00-Dateien der einzelnen Bundesländer inkl. der Landkreise hat bzw. ob über

so etwas schon nachgedacht wurde!



Schönes Wochenende!



gruss steffen

[Stefan Motz]

Hallo Steffen,

mit der Software der TK50-Karten und der entsprechenden CD (gibt es zum
Beispiel auch in einigen Bibliotheken) kannst du Overlay-Dateien (.ovl)
im ASCII-Format erstellen. Dazu reicht es, mit dem Polygon-Werkzeug die
gewünschten Landes- oder sonstige Grenzen nachzuzeichnen. Diese kannst
du statt der e00-Dateien als Grenzdaten laden.
Zu Testzwecken kannst du auch die auf den CDs befindlichen .ovl-Dateien
laden und diese als ASCII-ovl neu speichern (die liegen auf der CD
binär vor). Zur Weiterverwendung sind die Daten dann sicher nicht
geeignet, weil sie urheberrechtlich geschützt sein dürften.

Gruß
Stefan

[David Maciejewski]

Hallo Liste!

Ich setze seit knapp zwei Jahren die Opengeodb erfolgreich ein.

Auf www.mittelalter-spectaculum.de erhält man als angemeldeter /
registrierter User bei den Terminen immer eine Karte (Deutschland +
Schweiz + Österreich) mit Infos über den Ort, Enfernung, Kennzeichen und
so weiter. Im Bereich "meinMS" gibt es dann die o.g. Landkarte in einer
großen Version, in der sämtliche Städte eingetragen und verlinkt werden,
in der sich User befinden.
Diese Seite nimmt doch bitte mal in eure Referenzliste auf.

Nun zu meinem "Problem":
Ich nutze noch die alte 0.1.3-er Struktur (ISO) und wollte nun updaten
auf 0.2.x unter UTF-8. Da sich die Datenbankstruktur ja komplett
geändert hat, muss ich demzufolge auch alles umprogrammieren. Bekomme
ich die o.g. Features weiterhin hin mit der neuen Struktur, oder muss
ich komplizierte Verbieungen einbauen, um auf den alten Stand zu kommen?
Ein einfaches Update wird ja sicherlich nicht helfen.
--
D A V I D M A C I E J E W S K I
Webdesigner und -programmierer

com (_at_) macx (_dot_) de

[Rainer Suthoelder]

Post by David Maciejewski
Auf www.mittelalter-spectaculum.de erhält man als angemeldeter /
registrierter User bei den Terminen immer eine Karte (Deutschland +
Schweiz + Österreich) mit Infos über den Ort, Enfernung, Kennzeichen
und so weiter. Im Bereich "meinMS" gibt es dann die o.g. Landkarte in
einer großen Version, in der sämtliche Städte eingetragen und
verlinkt werden, in der sich User befinden.
Diese Seite nimmt doch bitte mal in eure Referenzliste auf.

alle interessenten (an deinem opengeodb projekt, nicht an dem
mittelalter-inhalten) muessten sich zunaechst anmelden, um deine arbeit
bewundern zu koennen, oder? das verfaelscht deine benutzerstatistik und
bedeutet noch einen account mehr, den man anlegen muss.
hinterleg auf deinem webspace doch noch ein paar statische screenshots und
schick den link dazu dann thomas - damit ist allen geholfen.

gruss

rainer

[David Maciejewski]

Post by Rainer Suthoelder
alle interessenten (an deinem opengeodb projekt, nicht an dem
mittelalter-inhalten) muessten sich zunaechst anmelden, um deine arbeit
bewundern zu koennen, oder?

Ja, der Zusatznutzen steht nur registrierten Nutzern zur Verfügung.
Haben wir als Mehrwert angedacht, um die Registrierung Schmackhaft zu
machen.
Ich werde mal Screenshots anfertigen und diese dann online stellen.
--
D A V I D M A C I E J E W S K I
Webdesigner und -programmierer

com (_at_) macx (_dot_) de

[Thomas Mack]

Hallo David,

[...]

Post by David Maciejewski
Diese Seite nimmt doch bitte mal in eure Referenzliste auf.

Mache ich heute oder morgen...

Post by David Maciejewski
Ich nutze noch die alte 0.1.3-er Struktur (ISO) und wollte nun updaten
auf 0.2.x unter UTF-8. Da sich die Datenbankstruktur ja komplett

Im Prinzip gibt es keine Notwendigkeit dafür. Es sei denn, Du brauchst
die erweiterten Daten der 0.2er Versionen, wie z.B. mehrere Namen für
Orte oder die zeitlichen Änderungen von Daten. Aber es gibt noch nicht
sooo viele von diesen zusätzlichen Daten.

Post by David Maciejewski
geändert hat, muss ich demzufolge auch alles umprogrammieren. Bekomme
ich die o.g. Features weiterhin hin mit der neuen Struktur, oder muss
ich komplizierte Verbieungen einbauen, um auf den alten Stand zu
kommen? Ein einfaches Update wird ja sicherlich nicht helfen.

Wenn Du die GeoClass zum Zugriff benutzt, sollte ein Upgrade der
GeoClass wesentliche Arbeit ersparen. Falls nicht: Grundsätzlich
sind alle Infos der 0.1.3er Version in den 0.2er Versionen enthalten.
Deshalb gibt es kein prinzipielles Problem.

Die 0.2er SQL Anfragen sind vor allem dann deutlich komplexer, wenn man
z.B. die gesamte Hierarchie eines Ortes auslesen möchte. Was vorher
mit einer einzigen DB-Abfrage ging, benötigt jetzt möglicherweise vier
oder fünf "oder so".

Thomas

[David Maciejewski]

Post by Thomas Mack

Post by David Maciejewski
Ich nutze noch die alte 0.1.3-er Struktur (ISO) und wollte nun updaten
auf 0.2.x unter UTF-8. Da sich die Datenbankstruktur ja komplett

Im Prinzip gibt es keine Notwendigkeit dafür. Es sei denn, Du brauchst
die erweiterten Daten der 0.2er Versionen

Ich sehe das Update deswegen als zwingend an, da dort - sofern ich
richtig mitgelesen habe - wesentlich mehr Orte für Österreich und
Schweiz enthalten sind, als noch in der 0.1.3-er. Da wir auch dort tätig
sind, ist das natürlich wünschendwert.
Nochmal: Es kommt mir auf ein möglichst volles Netz von Orten an, die
ich ansprechen kann.
--
D A V I D M A C I E J E W S K I
Webdesigner und -programmierer

com (_at_) macx (_dot_) de

[Thomas Mack]

Post by David Maciejewski
Ich sehe das Update deswegen als zwingend an, da dort - sofern ich
richtig mitgelesen habe - wesentlich mehr Orte für Österreich und
Schweiz enthalten sind, als noch in der 0.1.3-er. Da wir auch dort
tätig sind, ist das natürlich wünschendwert.

Nein, das ist nicht der Fall. Die Anzahl der Orte ist identisch. Aber
es kann passieren, daß die 0.2er Version mehr NAMEN kennt, einfach
weil sie einem Ort mehrere Namen zuordnen kann.

Grüße,
Thomas

[David Maciejewski]

Post by Thomas Mack
Nein, das ist nicht der Fall. Die Anzahl der Orte ist identisch.

So gesehen macht ein Update nun wirklich keinen Sinn.
Aber: Wie sieht es denn in Zukunft aus, wenn mehr Orte eingepflegt
werden? Lieber jetzt auf die neue Struktur aufsetzen und später nur
Datenbank updaten, oder lieber warten, weil sich eh noch strukturelle
Änderungen ergeben?
--
D A V I D M A C I E J E W S K I
Webdesigner und -programmierer

com (_at_) macx (_dot_) de

[Thomas Mack]

Post by David Maciejewski

Post by Thomas Mack
Nein, das ist nicht der Fall. Die Anzahl der Orte ist identisch.

So gesehen macht ein Update nun wirklich keinen Sinn.
Aber: Wie sieht es denn in Zukunft aus, wenn mehr Orte eingepflegt
werden? Lieber jetzt auf die neue Struktur aufsetzen und später nur
Datenbank updaten, oder lieber warten, weil sich eh noch strukturelle
Änderungen ergeben?

Hmmm, ICH halte die Struktur für recht stabil. Allerdings weiß ich nicht,
wohin sich die opengeodb entwickeln wird. Die Entwicklung geht ein wenig
weg von den reinen Daten von Ortschaften hin zu GPS Daten von allen
möglichen Dingen. Trotzdem ist das gegenwärtige Format flexibel genug,
daß ich noch keine wirklichen Grenzen erkenne.

Also solange DB-Formate noch Sinn machen, solange ist die aktuelle
Struktur "weitestgehend" sinnvoll und damit auch stabil, denke ich.

Zwei Diskussionspunkte sehe ich z.Zt. noch für unsere aktuellen
Punktdaten: eigentlich wollte ich in valid_until immer ein Datum
drinstehen haben, um generell so etwas wie:
... WHERE ... AND valid_until >= [heute]
schreiben zu können. Das funktioniert aber nicht bei "zeitlichen
Punktdaten", die halt für einen bestimmten Stichtag gültig sind,
wie z.B. Bevölkerungszahlen. Wie gehe ich damit um?

Und Punkt zwei: Wie funktionieren Beziehungen zwischen Datensätzen?
Ich habe bei den Daten zu Postleitzahlen bislang eine Referenz über
die geodb_hierarchies gemacht. Aber eigentlich sollte die Referenz
über eine loc_id erfolgen. Zumindest war das der urspüngliche Gedanke.
Wie würden SQL Anfragen DANN aussehen? Wäre das praktikabel oder viel
zu umständlich?

Aber selbst wenn da noch Handlungsbedarf wäre, würde es nicht zu
einer großer Änderung kommen müssen, denke ich mal.


Aber es bleibt noch ein Punkt, nämlich der der unterschiedlichen
Namen. Schreibt man z.B. als default Namen Ch-Biel, dann würde in
der 0.1.3er Version kein Bienne gefunden. Schreibt man Bienne als
default, fehlt Biel. Schreibt man beide hinein, bekäme man z.B.
bei einer Umkreissuche Biel als eigenständigen Ort und Bienne als
weiteren, scheinbar anderen Ort. Oder München als einen Ort, Munich
als einen zweiten Ort, den italienischen Namen für München als
dritten Ort - obwohl alle nur den gleichen Ort bezeichnen.

Hmmm, die Alternative wäre, das Format nocheinmal etwas zu modifizieren
und ein Attribut 'is_default' o.ä. hineinzusetzen. In den 0.1.3er
Datenexport. Ich denke mal darüber nach, ich denke, das wäre eine
gute Lösung...

Thomas

[Stefan Froehlich]

Post by Thomas Mack
Aber es bleibt noch ein Punkt, nämlich der der unterschiedlichen
Namen. Schreibt man z.B. als default Namen Ch-Biel, dann würde in der
0.1.3er Version kein Bienne gefunden. Schreibt man Bienne als default,
fehlt Biel. Schreibt man beide hinein, bekäme man z.B. bei einer
Umkreissuche Biel als eigenständigen Ort und Bienne als weiteren,
scheinbar anderen Ort. [...]

Will man das in letzter Konsequenz loesen, bleibt nicht viel anderes,
als (fuer einfache Abfragen oder als Fallback) die jeweils bevorzugte
Sprache in der Mastertabelle zu verwenden, und dazu noch eine
verknuepfte Tabelle anzulegen, in der Sprachvarianten samt den
zugehoerigen Locales abgelegt sind. Also ("Biel", "de_CH"), ("Bienne",
"fr_CH") und so weiter.

Servus,
Stefan

[Peter Wendorff]

Post by Thomas Mack
Zwei Diskussionspunkte sehe ich z.Zt. noch für unsere aktuellen
Punktdaten: eigentlich wollte ich in valid_until immer ein Datum
drinstehen haben, um generell so etwas wie: ... WHERE ... AND
valid_until >= [heute] schreiben zu können. Das funktioniert aber
nicht bei "zeitlichen Punktdaten", die halt für einen bestimmten
Stichtag gültig sind, wie z.B. Bevölkerungszahlen. Wie gehe ich
damit um?

Ich kenne bisher das Format der neueren Versionen nicht, weil meine
Anwendung der OpenGeoDB (demnächst auf www.abi2003-hgw.strelasoft.de,
allerdings noch nicht ganz fertig) nicht besonders viel braucht, aber
ich würde zwei Felder benutzen: valid_since und valid_until. Ein
einzelner Stichtag wäre dann eben gegeben, wenn valid_since = valid_until.
mfg
Peter Wendorff

[m***@public.gmane.org]

Hi Peter,

Post by Peter Wendorff
ich würde zwei Felder benutzen: valid_since und valid_until. Ein
einzelner Stichtag wäre dann eben gegeben, wenn valid_since = valid_until.

Ja, das ist eine Möglichkeit. Mein erster Gedanke war, daß es ganz praktisch
wäre, wenn man einfach so etwas wie WHERE valid_until > [heute] schreiben
könnte, um nur aktuelle Datensätze zu bekommen.

Bei Stichtagen müßte man so etwas wie: max(valid_until) schreiben, wenn
man max() überhaupt auf Datumsangaben anwenden kann.

Mal schauen.

Thomas

[Michael Hermann]

mir ist neulich auf folgender Seite:
http://worldofcrime.de/
die opengeodb geradezu ins Auge gesprungen...
Erst war ich noch ein wenig unsicher, ob das alles wirklich mit dem Hinter=
grund der
opengeodb gecoded wurde aber nachdem ich in einem Forum gesehen habe, dass=
ein
Entwickler auf die opengeodb.de/suche verwiesen hat wars mir v=F6llig klar=
...

allerdings finde ich weder in FAQ noch sonstwo einen Hinweis auf den Urspr=
ung der
Daten... Aber m=FCssen sie das nicht?

naja - schauts euch mal an und evtl auch viel Spass beim Spielen *g*

LG
Michi

[m***@public.gmane.org]

Hallo!

allerdings finde ich weder in FAQ noch sonstwo einen Hinweis auf den Ursprung der
Daten... Aber müssen sie das nicht?

Nein, die Daten sind frei.

Grüße,
Thomas

[VFAG - Mantel, Patrick]

Post by Michael Hermann
http://worldofcrime.de/
die opengeodb geradezu ins Auge gesprungen...
Erst war ich noch ein wenig unsicher, ob das alles wirklich mit dem Hintergrund der
opengeodb gecoded wurde aber nachdem ich in einem Forum gesehen habe, dass ein
Entwickler auf die opengeodb.de/suche verwiesen hat wars mir völlig klar...
allerdings finde ich weder in FAQ noch sonstwo einen Hinweis auf den Ursprung der
Daten... Aber müssen sie das nicht?
naja - schauts euch mal an und evtl auch viel Spass beim Spielen *g*
LG
Michi

Habe dieses Spiel, als es noch drugworld hieß sehr lange gespielt und
bin mir 100% sicher das dort
nirgendwo ein direkter Hinweis auf opengeodb ist.

Grüße
Patrick

[Younes Jones]

Hallo,
Thomas, ich habe eine Frage ( alle können natürlich antworten) mit
opengeodb.php kann ich köln und düsseldorf krigen und aufm Map sehen
aber mit entf.php kann ich nicht. ich kriege:
Ihre Suche nach "köln" ergab 0 Treffer:
Ihre Suche nach "Düsseldorf" ergab 0 Treffer:

wieso denn?
mit opengeopdb.php

Ihre Suche nach "köln" ergab 1 Treffer:

1. Köln
Deutschland > Nordrhein-Westfalen > Kreisfreie Stadt Köln

oder
Ihre Suche nach "düsseldorf" ergab 1 Treffer:

1. Düsseldorf
Deutschland > Nordrhein-Westfalen > Kreisfreie Stadt Düsseldorf

vielleicht vom "query" $sql ?

Thanks,
Jones.



entf.php:
====================================================================

<html>
<head>
<title>Beispiel f&uuml;r GeoClass/OpenGeoDB</title>
</head>
<body>
<?php

/*
###########################################################
#
# Beispiel für die Verwendung der GeoClass (0.2.2* von
# http://th-mack.de/opengeo)
# mit den Daten der OpenGeoDB (>= 0.2.1)
#
# Erfordert PEAR::DB
#
###########################################################
*/

/**
* Konfiguration muß angepaßt werden:
*/

ini_set('include_path','./PEAR:.');

if (!defined('DSN')) {
// Hier müssen die Zugangsdaten für die Datenbank eingetragen werden:
// define(DSN,'mysql://username:***@localhost/database_name');
define(DSN,'pgsql://tm:***@localhost/opengeo06h');
// define(DSN,'mysql://tm:***@localhost/opengeo06f');
}

require_once('Geo/Geo.php');
require_once('OpengeoDefs.php');

$geodb = Geo::setupSource("DB_OpenGeoDB",DSN);

$date = getdate();
$today = '\''.$date['year'].'-'.$date['mon'].'-'.$date['mday'].'\'';


if ($_GET["id1"] && $_GET["id2"]) {
// IDs sind übergeben. Entfernung ausrechnen und ausgeben:

$sql = 'SELECT td.text_val AS "name", '.
'td.loc_id AS "id", '.
'hi.level, '.
'lon, '.
'lat '.
'FROM geodb_textdata td, '.
'geodb_hierarchies hi, '.
'geodb_coordinates co '.
'WHERE td.loc_id='.(int)$_GET["id1"]." and ".
'td.text_type = '.NAME.' and '.
'td.is_native_lang = true and '.
'td.is_default_name = true and '.
'hi.loc_id = td.loc_id and '.
'hi.level >= 6 and '.
'co.loc_id = td.loc_id and '.
'td.valid_until >= '.$today.' and '.
'hi.valid_until >= '.$today.' and '.
'co.valid_until >= '.$today;
list($ort1) = $geodb->performQuery($sql);

$sql = 'SELECT td.text_val AS "name", '.
'td.loc_id AS "id", '.
'hi.level, '.
'lon, '.
'lat '.
'FROM geodb_textdata td, '.
'geodb_hierarchies hi, '.
'geodb_coordinates co '.
'WHERE td.loc_id='.(int)$_GET["id2"]." and ".
'td.text_type = '.NAME.' and '.
'td.is_native_lang = true and '.
'td.is_default_name = true and '.
'hi.loc_id = td.loc_id and '.
'hi.level >= 6 and '.
'co.loc_id = td.loc_id and '.
'td.valid_until >= '.$today.' and '.
'hi.valid_until >= '.$today.' and '.
'co.valid_until >= '.$today;
list($ort2) = $geodb->performQuery($sql);

echo '<h2>Entfernung '.$ort1->dbValues['name']." ->
".$ort2->dbValues['name'].':</h2>';
echo $ort1->getDistance($ort2)." km";

} else {
// Suchformular ausgeben:

echo '<h2>Ortsdatenbank</h2>';

echo '<form action="'.$_SERVER['PHP_SELF'].'" method="GET">';
echo '<input style="width:200px;" type="text" name="q1"
value="'.htmlentities($_GET["q1"]).'"><br>';
echo '<input style="width:200px;" type="text" name="q2"
value="'.htmlentities($_GET["q2"]).'"><br>';
echo '<input type="submit" name="" value="Suche starten">';
echo '</form>';

if ($_GET["q1"] && $_GET["q2"]) {
// Suchbegriffe sind eingegeben, die Suchresultate können ausgegeben
werden:

// Alle zutreffenden Orte heraussuchen:
$sql = 'SELECT td.loc_id as "id", '.
'td.text_val as "name", '.
'hi.level, '.
'co.lon, '.
'co.lat '.
'FROM geodb_coordinates co, '.
'geodb_textdata td, '.
'geodb_hierarchies hi '.
'WHERE co.loc_id = td.loc_id and '.
'hi.loc_id = td.loc_id and '.
'td.text_type = '.NAME.' and '.
'td.is_native_lang = true and '.
'td.is_default_name = true and '.
'td.text_val LIKE \'%'.utf8_encode($_GET["q1"]).'%\' and '.
'td.valid_until >= '.$today.' and '.
'hi.valid_until >= '.$today.' and '.
'co.valid_until >= '.$today.' '.
'ORDER BY id';

$treffer1 = $geodb->performQuery($sql);
// Anzahl Treffer
echo 'Ihre Suche nach "'.$_GET["q1"].'" ergab '.count($treffer1).'
Treffer:<br>';

$sql = 'SELECT td.loc_id as "id", '.
'td.text_val as "name", '.
'hi.level, '.
'co.lon, '.
'co.lat '.
'FROM geodb_coordinates co, '.
'geodb_textdata td, '.
'geodb_hierarchies hi '.
'WHERE co.loc_id = td.loc_id and '.
'hi.loc_id = td.loc_id and '.
'td.text_type = '.NAME.' and '.
'td.is_native_lang = true and '.
'td.is_default_name = true and '.
'td.text_val LIKE \'%'.utf8_encode($_GET["q2"]).'%\' and '.
'td.valid_until >= '.$today.' and '.
'hi.valid_until >= '.$today.' and '.
'co.valid_until >= '.$today.' '.
'ORDER BY id';

$treffer2 = $geodb->performQuery($sql);
// Anzahl Treffer
echo 'Ihre Suche nach "'.$_GET["q2"].'" ergab '.count($treffer2).'
Treffer:<br>';

if (is_array($treffer1) && count($treffer1)>=1 &&
is_array($treffer2) && count($treffer2)>=1) {
foreach ($treffer1 AS $key1 => $ort1) {
foreach ($treffer2 AS $key2 => $ort2) {
echo '<a
href="'.$_SERVER['PHP_SELF'].'?id1='.$ort1->dbValues['id'].'&id2='.$ort2->db
Values['id'].'">'.utf8_decode($ort1->dbValues['name']).' =>
'.utf8_decode($ort2->dbValues['name']).'</a><br>';
}
}
}
} else {
// Kein Suchbegriff
echo "Bitte geben Sie als Suchbegriff zwei<br>Namensbestandteile oder
Postleitzahlen ein.";
}
}
?>
</body>
</html>

[Martin Trautmann]

Post by Younes Jones
Hallo,
Thomas, ich habe eine Frage ( alle können natürlich antworten) mit
opengeodb.php kann ich köln und düsseldorf krigen und aufm Map sehen

Das sieht nach einem Umlautproblem aus?

Schoenen Gruss
Martin

[Younes Jones]

Post by Martin Trautmann
Das sieht nach einem Umlautproblem aus?

genau, aber nur bei entf.php , mit opengeodb.php funktionniert ganz gut.

Jones.

[m***@public.gmane.org]

Post by Younes Jones
Hallo,
Thomas, ich habe eine Frage ( alle können natürlich antworten) mit
opengeodb.php kann ich köln und düsseldorf krigen und aufm Map sehen

Puuh: WENN die DB in UTF8 kodiert ist, dann müssen der DB auch
UTF8 kodierte Strings übergeben werden. Schreib testhalber mal
ein utf8_encode(...) um die Daten herum, die Du der SQL-Anfrage
übergibst. Oder ein utf8_decode, wenn die DB latin1 ist, aber
das Formular UTF-8...

Thomas

[Martin Trautmann]

Post by Thomas Mack
Zwei Diskussionspunkte sehe ich z.Zt. noch für unsere aktuellen
Punktdaten: eigentlich wollte ich in valid_until immer ein Datum
... WHERE ... AND valid_until >= [heute]
schreiben zu können. Das funktioniert aber nicht bei "zeitlichen
Punktdaten", die halt für einen bestimmten Stichtag gültig sind,
wie z.B. Bevölkerungszahlen. Wie gehe ich damit um?

Ich denke, hier brauchst du mehr Infos:

- Datum der ersten Gueltigkeit
- Datum der letzten, verifizierten Gueltigkeit
- Markierung: ist (weiterhin) gueltig

Je nach Charakter des Eintrags kannst du dann beliebiges damit anfangen.
Beispielsweise kann ein Ort ein 'Protokoll' der Bevoelkerungszahlen
anbieten. Das Datum waere dann ein Stichtag, das entweder als erster Tag,
als letzter Tag oder in beiden Tagen eingetragen wird. Eine Recherche
koennte von mehreren Daten den z.B. letzten aktuellen herausfiltern. Eine
Recherche koennte auch den Auftrag 'Interpoliere' vorgeben, die aus den
bisherigen Bevoelkerungszahlen eine Interpolation hochrechnet, wie wohl
der heutige Stand sein mag. Hierzu braucht's aber moeglicherweise
Zusatzinfos, wenn z.B. die Ortsgroesse sich durch Eingemeindungen
sprunghaft aenderte.

Post by Thomas Mack
Und Punkt zwei: Wie funktionieren Beziehungen zwischen Datensätzen?
Ich habe bei den Daten zu Postleitzahlen bislang eine Referenz über
die geodb_hierarchies gemacht. Aber eigentlich sollte die Referenz
über eine loc_id erfolgen. Zumindest war das der urspüngliche Gedanke.

Sorry - ich denke noch nicht in der GeoDB-Struktur. Was meinst du konkret?
Es gibt einerseits datensatzspezifische Beziehungen, die manuell zu setzen
waeren. Es gibt typischerweise Vererbungen bestimmter Typen (z.B. gehoert
das Kennzeichen eines Kreises meist auch zu den untergeordneten Gemeinden,
Ortsteilen, Strassen, Haeusern, Personen). Und als vermutlich manuell zu
setzende Beziehungen gibt es vor allem die Ausnahmen, wo die Vererbung
ausgesetzt wird - z.B. bei einem Kennzeichen, wo der Ort sein eigenes
behielt, statt das Kreiskennzeichen zu uebernehmen.

Post by Thomas Mack
Aber es bleibt noch ein Punkt, nämlich der der unterschiedlichen
Namen. Schreibt man z.B. als default Namen Ch-Biel, dann würde in
der 0.1.3er Version kein Bienne gefunden. Schreibt man Bienne als
default, fehlt Biel. Schreibt man beide hinein, bekäme man z.B.
bei einer Umkreissuche Biel als eigenständigen Ort und Bienne als
weiteren, scheinbar anderen Ort. Oder München als einen Ort, Munich
als einen zweiten Ort, den italienischen Namen für München als
dritten Ort - obwohl alle nur den gleichen Ort bezeichnen.

Das waere eine eigene Tabelle 'Schreibvarianten' mit

opengeodb-ID: Schluessel
Name: Schreibweise
Sprache: Engl/dtsch./frz./....
evtl. auch Zeitraum (z.B. roemische, mittelalterliche Schreibweise)

Es gibt hier auch 'Bruttonamen', 'Nettonamen', normierte Schreibvarianten
und tatsaechlich angetroffende Schreibvarianten.

Beispiel: A-Stadt im Bundesland B-Land. Typische Schreibweisen davon sind

A-Stadt, B-Land
A-Stadt (B-Land)
A-Stadt/B-Land
A-Stadt / B-Land.

Die Kurzform ist A-Stadt. 'Bruttoname' waere die 'offizielle' Langform,
z.B. "A-Stadt (B-Land)". Ein 'Nettoname' koennte auf alle Sonderzeichen
verzichten und sich auf "A-Stadt B-Land" verkuerzen. Schreibvarianten
koennten aktuelle oder ehemalige Bezeichnungen sein, wie z.B. 'A-Stadt a.
C-Fluß' und 'A-Stadt b. Ddorf'

Eine Suche sollte alle Moeglichkeiten finden - oder aber z.B. ueber die
Sprache eingrenzbar sein. Eine Ausgabe koennte auf Sprachen konfigurierbar
sein und z.B. zum deutschen Namen wahlweise auch den englischen anzeigen.

Schoenen Gruss
Martin

[m***@public.gmane.org]

Hallo Martin,

Post by Martin Trautmann

Post by Thomas Mack
... WHERE ... AND valid_until >= [heute]
schreiben zu können. Das funktioniert aber nicht bei "zeitlichen
Punktdaten", die halt für einen bestimmten Stichtag gültig sind,
wie z.B. Bevölkerungszahlen. Wie gehe ich damit um?

- Datum der ersten Gueltigkeit
- Datum der letzten, verifizierten Gueltigkeit
- Markierung: ist (weiterhin) gueltig

Hehe: das mag ja formal recht korrekt sein, aber gerade bei
Bevölkerungsdaten doch eher utopisch, wenn man nicht gerade
seinen eigenen Haushalt mit eintragen will.

Natürlich kann ich eintragen, daß Bad Harzburg am [...] 23.709 Einwohner
hatte, aber dann noch herauszufinden, wie lange diese Zahl gültig war
(wahrscheinlich bis zum nächsten darauffolgenden Werktag?), das ist
nicht durchführbar.

Für andere Daten als gerade Bevölkerungszahlen könnte man das System
überdenken, aber mir fällt dazu gerade nichts ein.

Post by Martin Trautmann

Post by Thomas Mack
Und Punkt zwei: Wie funktionieren Beziehungen zwischen Datensätzen?
Ich habe bei den Daten zu Postleitzahlen bislang eine Referenz über
die geodb_hierarchies gemacht. Aber eigentlich sollte die Referenz
über eine loc_id erfolgen. Zumindest war das der urspüngliche Gedanke.

Sorry - ich denke noch nicht in der GeoDB-Struktur. Was meinst du konkret?

Wenn ich eine Koordinate für ein Postleitzahlgebiet aufnehme, dann
brauche ich auch Angaben darüber, wo dieses Gebiet "politisch" zu
finden ist, weil es sonst ziemlich schwierig werden kann herauszufinden,
ob dieses Postleitzahlgebiet in D oder A oder CH oder Belgien oder
Liechtenstein liegt.

Oder in Bayern oder Brandenburg oder Thüringen. Usw..

Ich könnte einen Verweis aufnehmen in der Variante, daß ich sage:
"der Ort mit loc_id [xxx] benutzt diese PLZ / liegt in diesem
Postleitzahlgebiet". Oder ich baue die gleiche Struktur auf wie
ich es auch bei den Orten mache, nämlich daß ich die komplette
politische Hierarchie mit aufnehme.

Letzteres vereinfacht die SQL-Anfragen "ein wenig".

Post by Martin Trautmann
Es gibt einerseits datensatzspezifische Beziehungen, die manuell zu setzen
waeren. Es gibt typischerweise Vererbungen bestimmter Typen (z.B. gehoert
das Kennzeichen eines Kreises meist auch zu den untergeordneten Gemeinden,
Ortsteilen, Strassen, Haeusern, Personen). Und als vermutlich manuell zu

Ja genau, wie macht man Vererbung in opengeodb sinnvollerweise?

Usw. usf. :-)

Thomas

[Stefan Froehlich]

Post by m***@public.gmane.org

Post by Martin Trautmann
- Datum der ersten Gueltigkeit
- Datum der letzten, verifizierten Gueltigkeit
- Markierung: ist (weiterhin) gueltig

Natürlich kann ich eintragen, daß Bad Harzburg am [...] 23.709
Einwohner hatte, aber dann noch herauszufinden, wie lange diese Zahl
gültig war (wahrscheinlich bis zum nächsten darauffolgenden Werktag?),
das ist nicht durchführbar.

Das oesterreichische Rechtsinformationssystem (http://ris.bka.gv.at/)
hat potentiell das gleiche Problem: niemand weiss, wie lange in Gesetz
gueltig sein wird.

Am ehesten brauchbar scheint mir auch hier die Kombination von
"gueltig_ab" und "gueltig_bis" zu sein, wobei "gueltig_bis" im
Normalfall mit dem maximal darstellbaren Datum gefuellt wird.
Beim Anlegen eines neuen, aktualisierten Datensatzes wird dann der
alte mit einem konkreten Enddatum versehen (also beendet z.B. ein
Ergebnis der Volkszaehlung 2011 die Gueltigkeit der Daten von 2001).

Das hat den Vorteil, dass immer ein gueltiger (wenn auch nicht zwingend
wirklich aktueller) Datensatz vorhanden ist.

Servus,
Stefan

[Martin Trautmann]

Post by m***@public.gmane.org
Hallo Martin,

Post by Martin Trautmann

Post by Thomas Mack
... WHERE ... AND valid_until >= [heute]
schreiben zu können. Das funktioniert aber nicht bei "zeitlichen
Punktdaten", die halt für einen bestimmten Stichtag gültig sind,
wie z.B. Bevölkerungszahlen. Wie gehe ich damit um?

- Datum der ersten Gueltigkeit
- Datum der letzten, verifizierten Gueltigkeit
- Markierung: ist (weiterhin) gueltig

Hehe: das mag ja formal recht korrekt sein, aber gerade bei
Bevölkerungsdaten doch eher utopisch, wenn man nicht gerade
seinen eigenen Haushalt mit eintragen will.

Ich glaube, hier liegt ein Missverständnis vor!?

Post by m***@public.gmane.org
Natürlich kann ich eintragen, daß Bad Harzburg am [...] 23.709 Einwohner
hatte, aber dann noch herauszufinden, wie lange diese Zahl gültig war
(wahrscheinlich bis zum nächsten darauffolgenden Werktag?), das ist
nicht durchführbar.

Nach meiner praktischen Erfahrung brauche ich fast nie ein
vorausschauendes Datum, wann eine Gültigkeit enden wird. Die meisten
Daten brauchen nur den Zeitstempel als Referenzpunkt, wann sie
(einmalig) gültig waren.

Viele Daten sind aber über einen längeren Zeitraum hinweg gültig. Bei
denen kennt man womöglich in vielen Fällen den genauen Zeitpunkt, ab
wann sie gültig wurden - ein eindeutiger Eintrag als Datum der ersten
Gültigkeit.

Bei vielen Infos weiss man aber nur, dass sie zumindest zu einem
bestimmten Zeitpunkt gültig waren - die Vorgeschichte ist unbekannt.
Das Datum der ersten Gültigkeit ist also kleiner-gleich zu diesem
bekannten Zeitpunkt.

Diese Daten können immer wieder überprüft werden - und damit ergibt
sich entweder eine Liste von geprüften Zeitstempeln 'geprüft an Tag X,
geprüft an Tag Y, geprüft an Tag Z' oder aber ein Zeitbereich: Gültig
ab <=X, gültig bis >=Z, und Z wird mit der nächsten Prüfung erhöht,
wenn ein späteres Datum bekannt ist.

Diese Zeit-Punkte gültig ab / gültig bis sind nicht feste Anfangs- und
Endpunkte einer Zeit-Strecke, sondern Markierungen auf einem
Zeitstrahl, die eigentlich zur Interpretation weitere Zusatzinfos
benötigen. Oftmals erkenne ich das Ende einer Gültigkeit nicht an einem
bekannten genauen Zeitpunkt sondern einfach aus dem Verschwinden vom
einen Prüfzeitpunkt zum nächsten. Das Ende der Gültigkeit liegt dann
meist genau zwischen diesen beiden Prüfzeitpunkten (manchmal auch vor
dem vorletzten Prüfzeitpunkt, weil die Vergleichsdaten selbst zu deren
Referenzzeitpunkt schon veraltet waren - aber genau diese Veränderungen
kann man oft genauer nachprüfen und korrigieren)

Aus dem Grund bevorzuge ich für diese Zeiten statt eines festen
Datumstyps eine zugleich unschärfere und formalisierte
Textschreibweise. Daraus abgeleitet mal hier ein Vorschlag:

- Datumstyp: Text
- Präfix: <, ≤ oder = (bzw. >, ≥ oder =) für Zeitpunkte, die vor (<),
evtl. vor (<=) oder exakt auf dem zugehörigen Zeitpunkt lagen
(bzw. entsprechend nach einem Zeitpunkt)
- Datumsformat: yyyy-mm-dd: Jahr, Monat, Tag.
Dieses Format wurde vor ein paar Jahren als DIN und ISO offiziell
normiert. Es mag anfangs ungewohnt sein, bietet aber erhebliche
Vorteile, einerseits in der primitiven Sortierung nach Text,
andererseits als verwechslungsfrei eindeutige Darstellung im
internationalen Gebrauch (vgl. Deutschland d.m.yy, England d/m/yy, USA
m/d/yy, ...)

Dieses Format erlaubt auch Variationen wie z.B.
heute: 2005-04-17
Dieses Monat: 2005-04
Dieses Jahr: 2005
Diese Woche: 2005-W16
Dieses Quartal: 2005-Q1
Zeitraum: 2005-04..2006-05
2005/2006
2005-04-15..16
Zeitstempel: 2005-04-17 22:34
Zeitzone: 2005-04-17 22:34 +0100


Viele Einträge benötigen entweder einen einmaligen Zeitpunkt oder eine
mehrfache Aktualisierung. Für einmalige Zeitpunkte wäre dies
systematisch z.B. Beginn: = 2005-04-17 (Randbemerkung: Persönlich
lasse ich ein "=" wegfallen, aber für eine sauber systematische
Darstellung kann man das in der Datenhaltung sauber mitziehen und je
nach Bedarf der Darstellung auf der Oberfläche verbergen.)

Für wiederholte Zeitpunkte würde man dann das Ende nutzen: ≥ 2005-04-17
bedeutet also: Wurde heute geprüft und für gültig befunden -
wahrscheinlich bleibt's auch weiterhin gültig. Wüsste ich allerdings,
dass die Gültigkeit definitiv nur bis 2005-31-12 gegeben ist, so kann
ich das auch gleich als "= 2005-12-31" festhalten.

Post by m***@public.gmane.org
Für andere Daten als gerade Bevölkerungszahlen könnte man das System
überdenken, aber mir fällt dazu gerade nichts ein.

Bevölkerungszahlen sind entweder heute (vgl. das klassiche
Western-Einwohnerschild am Stadteingang), meist aber auf einen
Bilanzstichtag bezogen.

Post by m***@public.gmane.org

Post by Martin Trautmann

Post by Thomas Mack
Und Punkt zwei: Wie funktionieren Beziehungen zwischen Datensätzen?
Ich habe bei den Daten zu Postleitzahlen bislang eine Referenz über
die geodb_hierarchies gemacht. Aber eigentlich sollte die Referenz
über eine loc_id erfolgen. Zumindest war das der urspüngliche Gedanke.

Sorry - ich denke noch nicht in der GeoDB-Struktur. Was meinst du konkret?

Wenn ich eine Koordinate für ein Postleitzahlgebiet aufnehme, dann
brauche ich auch Angaben darüber, wo dieses Gebiet "politisch" zu
finden ist, weil es sonst ziemlich schwierig werden kann
herauszufinden,
ob dieses Postleitzahlgebiet in D oder A oder CH oder Belgien oder
Liechtenstein liegt.

Ok, Verstanden - die loc_id sollte den Zugang zu allen diesen
Informationen bieten.
Irgendwo muss eben eine Tabelle vorliegen, die auch die
Hierarchie-Information mitbringt. Aus Effizienzgründen habe ich hier
eine hierarchische Nummer, die alle diese Informationen mitbringt.
Fehlende Daten werden daher einfach aus der übergeordneten Ebene
geerbt. Aber diese Hierarchie ist auch immer einem permanenten Wandel
unterzogen - dieser Wandel kann besser über eine separate Zuordnung und
statische loc_IDs archiviert werden, wie opengeodb dies vorsieht.

Post by m***@public.gmane.org
Oder in Bayern oder Brandenburg oder Thüringen. Usw..
"der Ort mit loc_id [xxx] benutzt diese PLZ / liegt in diesem
Postleitzahlgebiet". Oder ich baue die gleiche Struktur auf wie
ich es auch bei den Orten mache, nämlich daß ich die komplette
politische Hierarchie mit aufnehme.
Letzteres vereinfacht die SQL-Anfragen "ein wenig".

Ich vermute, man braucht hier einerseits die minimalistische
Darstellung: Wo eine PLZ politisch hingehört, ist archivtechnisch
zweistufig zu lösen: PLZ gehoert zu loc_ID A und loc_IC B, loc_ID A
gehört zu Ort/Gemeinde/Kreis AA, loc_ID B gehört zu Ort/Gemeinde/Kreis
BB.

Für den Datenaustausch ist allerdings ein Schnappschuss der aktuell
erwünschten Info in ausgeflachter Version (z.B. deine Text-Dateien)
sehr hilfreich. Die sind auch ohne SQL über einfache grep oder
Import-Funktionen in anderen Umgebungen leicht nutzbar.

Post by m***@public.gmane.org

Post by Martin Trautmann
Es gibt einerseits datensatzspezifische Beziehungen, die manuell zu setzen
waeren. Es gibt typischerweise Vererbungen bestimmter Typen (z.B. gehoert
das Kennzeichen eines Kreises meist auch zu den untergeordneten Gemeinden,
Ortsteilen, Strassen, Haeusern, Personen). Und als vermutlich manuell zu

Ja genau, wie macht man Vererbung in opengeodb sinnvollerweise?

Ich weiss keinen generell sinnvollen Ansatz - Ich denke, das hängt
immer sehr vom Einzelfall ab.

Beispiel: Kfz-Kennzeichen eines Orts ist in fast allen Fällen das
gleiche Kennzeichen wie das des Kreises.
Ausnahmen: Einerseits einige Exoten (BÜS/KN, VK/SB, IGB/HOM,
andererseits Änderungen durch Gemeinde- und Kreisreformen (SUL -> AM ->
AS), durch Aktualisierungen, durch Ost-West-Vereinigung (L -> LDK) usw.
D.h. typischerweise kann eine Gemeinde das Kennzeichen des Kreises
erben - ausser, es wird sofort eine Ausnahme dokumentiert. Gleichzeitig
mag aber die historische Suchoption eine Ausnahme darstellen, wo man
auch an früheren Einträgen interessiert ist.

Umgekehrt kann z.B. eine Stadt alle Postleitzahlen aller ihrer
einzelnen Ortsteile zusammenfassen - wobei auch hier beliebige
Ausnahmen möglich und sinnvoll sind. Beispielsweise gehört hier ein Hof
rechtlich zum Nachbarkreis, wird postalisch (und wegetechnisch) von
diesem Kreis aus erfasst. Dieser Hof hat also die PLZ des
Nachbarkreises, und es ist kaum sinnvoll, dessen PLZ an den Kreis nach
oben weiterzuvererben: Wenn man Postleitzahlengebiete von einander
abgrenzen möchte, so weichen solche Ausnahmen den tatsächlich gesuchten
typischen Wert beliebig auf. Der Ortseintrag dieses Hofes sollte also
die Information enthalten, die PLZ nicht nach oben zu vererben. Aber es
mag wiederum Ausnahmefälle geben, wo man auch diese Exoten eines
Kreises mitgenannt bekommen möchte.



Ich begrüße also die derzeitige Aufsplittung der openbeodb-Struktur in
thematisch passende Teile, wie z.B. PLZ, Kfz-Kennzeichen, Vorwahlen,
...
Ich vermisse die entsprechende Schaffung einer Versionierung (evtl. mit
genannten Datumswerten).
Ich wünsche mir weiterhin ausgeflachte Versionen im einfachen
Text-Format.

Schönen Gruß
Martin

[m***@public.gmane.org]

Hallo Martin,

es ist zwar schon ein Weilchen vergangen, aber trotzdem ein paar

Post by Martin Trautmann
Aus dem Grund bevorzuge ich für diese Zeiten statt eines festen
Datumstyps eine zugleich unschärfere und formalisierte
- Datumstyp: Text
- Präfix: <, ? oder = (bzw. >, ? oder =) für Zeitpunkte, die vor (<),
evtl. vor (<=) oder exakt auf dem zugehörigen Zeitpunkt lagen
(bzw. entsprechend nach einem Zeitpunkt)
- Datumsformat: yyyy-mm-dd: Jahr, Monat, Tag.
Dieses Format wurde vor ein paar Jahren als DIN und ISO offiziell
normiert. Es mag anfangs ungewohnt sein, bietet aber erhebliche
Vorteile, einerseits in der primitiven Sortierung nach Text,
andererseits als verwechslungsfrei eindeutige Darstellung im
internationalen Gebrauch (vgl. Deutschland d.m.yy, England d/m/yy, USA
m/d/yy, ...)
Dieses Format erlaubt auch Variationen wie z.B.
heute: 2005-04-17
Dieses Monat: 2005-04
Dieses Jahr: 2005
Diese Woche: 2005-W16

Schon hier wird es sichtbar, daß diese > / < Vergleiche nicht mehr
richtig funktionieren. Es ist die Frage, ob es relevante Auswirkungen
hätte.
methode, dem Datum einen Typ zuzuordnen ist da etwas flexibler.
Allerdings bekommt man dann immer ein genaues Datum zurück: wenn
man nicht auch noch den Typ auswertet, könnte man auf den Gedanken
kommen, es wäre ein exakt definierter Zeitpunkt.

Möglicherweise könnte man Dein Format auch so umformulieren, daß
Vergleiche korrekt bleiben. Es bleibt, daß die Datumsarithmetik
nicht mehr funktioniert. Aber möglicherweise braucht man sie auch
gar nicht...

Wie dem auch sei: ich behalte erstmal das Format wie gehbat bei,
Zeitpunktdaten werde ich wahrscheinlich wie vorgeschlagen mit
einem genauen Zeitpunkt in den valid_since und dem "irgendwann
später" Eintrag in valid_until vornehmen, wenn es der letzte
Eintrag ist. Die vorgehenden Einträge werden dann jeweils auf
since = until gesetzt. Da ist zwar eine gewisse formale
Inkonsistenz drin, aber es macht das Leben einfacher :-)

Thomas

[Martin Trautmann]

Post by m***@public.gmane.org
Hallo Martin,
es ist zwar schon ein Weilchen vergangen, aber trotzdem ein paar

Post by Martin Trautmann
Aus dem Grund bevorzuge ich für diese Zeiten statt eines festen
Datumstyps eine zugleich unschärfere und formalisierte
- Datumstyp: Text
- Präfix: <, ? oder = (bzw. >, ? oder =) für Zeitpunkte, die vor (<),
evtl. vor (<=) oder exakt auf dem zugehörigen Zeitpunkt lagen
(bzw. entsprechend nach einem Zeitpunkt)
- Datumsformat: yyyy-mm-dd: Jahr, Monat, Tag.
Dieses Format wurde vor ein paar Jahren als DIN und ISO offiziell
normiert. Es mag anfangs ungewohnt sein, bietet aber erhebliche
Vorteile, einerseits in der primitiven Sortierung nach Text,
andererseits als verwechslungsfrei eindeutige Darstellung im
internationalen Gebrauch (vgl. Deutschland d.m.yy, England d/m/yy, USA
m/d/yy, ...)
Dieses Format erlaubt auch Variationen wie z.B.
heute: 2005-04-17
Dieses Monat: 2005-04
Dieses Jahr: 2005
Diese Woche: 2005-W16

Schon hier wird es sichtbar, daß diese > / < Vergleiche nicht mehr
richtig funktionieren. Es ist die Frage, ob es relevante Auswirkungen
hätte.

Hallo Thomas,

Deine Antwortzeile steht unter meinem Text zum Format. Hier wird fuer mich
nicht sichtbar, warum Vergleiche auf diesem Format nicht funktionieren
sollten. Im Gegenteil halte ich das Format hier fuer ausserordentlich
geeignet. Mag sein, dass die Woche 2005-W16 hier aus dem Rahmen faellt,
wie auch z.B. ein Quartal 2005-Q3 - aber es wuerde fuer alles im Jahr 2004
oder nach z.B. 2003 korrekt gefunden werden.

Post by m***@public.gmane.org
methode, dem Datum einen Typ zuzuordnen ist da etwas flexibler.

Die Praefix [><=] kann wahlweise als erstes Zeichen in ein Textfeld fuer's
Datum uebernommen werden oder in einem eigenen Feld landen - beides
enthaelt die gleiche Info. Bei einem eigenen Feld kann man beliebig auch
statt dessen Nummern zuordnen (0: =, -1: <=, -2: <, +1: >=, +2: >=) oder
Abkuerzungen vergeben (g: gleich, m(ehr): >=, n(noch mehr): >, w(weniger):
<=, v(iel weniger): <, c(irca): ~=, u(ngleich): !=, usw.).

Sprich: die Art, der Datentyp ist mir voellig wurscht. Mir geht's um die
Information, die enthalten sein sollte. Ein Datum wie 1.4.2004 spiegelt eine
Genauigkeit wieder, die eigentlich nur aus der Verlegenheit entstand, dass
es wohl irgendwann zwischen April und Juni 2004 gelegen haben mag, aber
die Datumseingabe komplett Tag, Monat und Jahr verlangt.

Post by m***@public.gmane.org
Allerdings bekommt man dann immer ein genaues Datum zurück: wenn
man nicht auch noch den Typ auswertet, könnte man auf den Gedanken
kommen, es wäre ein exakt definierter Zeitpunkt.
Möglicherweise könnte man Dein Format auch so umformulieren, daß
Vergleiche korrekt bleiben. Es bleibt, daß die Datumsarithmetik
nicht mehr funktioniert. Aber möglicherweise braucht man sie auch
gar nicht...

Ich weiss hier nicht, worauf sich deine Arithemtik bezieht. Vielleicht
brauche ich da ein paar Beispiele. Keine Ahnung, worauf du Arithemtik
brauchst. Aber wenn dich z.B. die Eintraege der letzten 100 Tage
interessieren, dann erfolgt eine Datenbankabfrage dann eben nicht auf
'heute - 100'..'heute', sondern auf '> Datum2Text(heute - 100)'. Gibt es
keine Datenbankfunktionen mit > , < oder Wildcards auf Text?

Post by m***@public.gmane.org
Wie dem auch sei: ich behalte erstmal das Format wie gehbat bei,
Zeitpunktdaten werde ich wahrscheinlich wie vorgeschlagen mit
einem genauen Zeitpunkt in den valid_since und dem "irgendwann
später" Eintrag in valid_until vornehmen, wenn es der letzte
Eintrag ist. Die vorgehenden Einträge werden dann jeweils auf
since = until gesetzt. Da ist zwar eine gewisse formale
Inkonsistenz drin, aber es macht das Leben einfacher :-)

ich wuerde keine Dummyeintraege fuer valid-until verwenden, die auf
irgendein fiktives Datum doomsday verweisen, sondern dann lieber das Feld
leer belassen. Wofuer brauchst du denn ein valid_until mit 'unendlichem'
Wert?

Schoenen Gruss
Martin

[Thomas Mack]

Post by Martin Trautmann
Diese Woche: 2005-W16

[Datumsvergleiche]

ausserordentlich geeignet. Mag sein, dass die Woche 2005-W16 hier aus
dem Rahmen faellt, wie auch z.B. ein Quartal 2005-Q3 - aber es wuerde
fuer alles im Jahr 2004 oder nach z.B. 2003 korrekt gefunden werden.

Das meinte ich. Es wird schwammiger hier. Vielleicht macht das nichts,
kann schon sein.

Datumsarithmetik: Mit den SQL Datentypen kann man so etwas machen wie
heute - 2 weeks oder solche Geschichten. Diese Möglichkeiten verliert
man mit Texteinträgen. Auch hier wieder: es ist fraglich, ob es
relevant ist.

ich wuerde keine Dummyeintraege fuer valid-until verwenden, die auf
irgendein fiktives Datum doomsday verweisen, sondern dann lieber das
Feld leer belassen. Wofuer brauchst du denn ein valid_until mit
'unendlichem' Wert?

Das hat den Vorteil, daß man bei Anfragen einfach WHERE valid_until

= 'today' schreiben kann. Das ist auch die Logik dahinter, wenn man

aktuelle Daten sucht. Ich finde es angemessen, wenn man es in dieser
Form ausdrückt. In Postgres gibt es so etwas wie ein "unendliches Datum",
was in etwa diesen Sinn hat. Nur ist mir nicht ganz klar, wie groß die
Verbreitung dieses "unendlichen" Datums in anderen Datenbanken ist:
sprich, ist es ein verbreiteter Standard oder eine Postgres Spezialität?

Grüße,
Thomas

[Stefan Froehlich]

Post by Thomas Mack
[Datumsvergleiche]
Datumsarithmetik: Mit den SQL Datentypen kann man so etwas machen
wie heute - 2 weeks oder solche Geschichten. Diese Möglichkeiten
verliert man mit Texteinträgen. Auch hier wieder: es ist fraglich,
ob es relevant ist.

Warum jetzt dagegen entscheiden, wenn es spaeter relevant werden
_koennte_. Datumseintraege sind ideal dafuer geschaffen, auch als
solche abgespeichert zu werden - in Textformat kann man sie dann
immer noch konvertieren, wo man es benoetigt.

Post by Thomas Mack

Wofuer brauchst du denn ein valid_until mit 'unendlichem' Wert?

Das hat den Vorteil, daß man bei Anfragen einfach WHERE valid_until

= 'today' schreiben kann.

Ansonsten hat man bei derartigen Abfragen immer noch ein
"AND valid_until > 0" dabei. Das ist natuerlich nicht ganz
so elegant.

Post by Thomas Mack
In Postgres gibt es so etwas wie ein "unendliches Datum", was in
etwa diesen Sinn hat. Nur ist mir nicht ganz klar, wie groß die
Verbreitung dieses "unendlichen" Datums in anderen Datenbanken
ist: sprich, ist es ein verbreiteter Standard oder eine Postgres
Spezialität?

MySQL kennt das jedenfalls nicht, und ich habe auch noch nichts
davon gehoert, dass es in einem SQL-Standard auftaucht.

Servus,
Stefan

[Martin Trautmann]

Post by Stefan Froehlich

Post by Thomas Mack
[Datumsvergleiche]
Datumsarithmetik: Mit den SQL Datentypen kann man so etwas machen
wie heute - 2 weeks oder solche Geschichten. Diese Möglichkeiten
verliert man mit Texteinträgen. Auch hier wieder: es ist fraglich,
ob es relevant ist.

Warum jetzt dagegen entscheiden, wenn es spaeter relevant werden
_koennte_. Datumseintraege sind ideal dafuer geschaffen, auch als
solche abgespeichert zu werden - in Textformat kann man sie dann
immer noch konvertieren, wo man es benoetigt.

Hallo Stefan,

du setzt aber voraus, dass tatsaechlich konkrete Datumseintraege
existieren wuerden.

Beispiel:
Ich beobachte, dass im Maerz 2005 eine Gemeinde noch eigenstaendig war.
Zum halbjaehrlichen Update im September stelle ich fest, dass diese
Gemeinde aufgeloest wurde.

Was traegst du nun als Datum fuer diese Aenderung ein? 2005-03-01?
2005-09-01?

Alles, was ich zu dem Zeitpunkt weiss ist, dass die Aenderung vermutlich
zwischen Maerz und September stattfand. Ich wuerde also zumindest sagen,
als Datum fuer die Aenderung waere '2005' angemessen. Vielleicht wuerde
ich sogar '2005-03..09' verwenden (vielleicht auch nicht, versteht ja
keiner, koennte aber automatisch leicht ersetzt werden in 'zwischen
2005-03 und 2005-09'). Tatsaechlich konnte ich in der Praxis
beobachten, dass Gemeindeaufloesungen rueckdatiert wurde - da wurde z.B.
erst im Maerz 2004 veroeffentlicht, dass mit Wirkung zum 1. Januar 2004
eine Gemeinde aufgeloest wurde.

[weitere Probleme hierzu wieder geloescht - interessiert euch wohl kaum so
im Detail]

Gerade daher lehne ich aber ab, mit einer erzwungenen taggenauen
Datumsangabe eine Genauigkeit vorzugeben, die nicht mal auf den Monat
genau gewaehrleistet ist.

Umgekehrt ist eine Umrechung der liberaleren Text-Version jederzeit in
eine taggenaue Datumsversion ebenso moeglich - so weit die Information es
zulaesst und man zum Zeitpunkt der Abfrage die Abweichungen toleriert.

Was aber erst mal an Information verloren ist, weil's nicht in ein starres
Formatraster passt, das bekommen wir nicht wieder.

Von daher bin ich auch nicht ganz gluecklich damit, dass in manchen
Koordinatensammlungen Werte auf x Dezimalstellen angegeben werden (z.B.
52.500000 - wo die tatsaechliche Genauigkeit bei 52.50 ± 0.20 gelegen
haben mag. Aber gerade bei der Umrechnung von 52° 40' in 52.6667 (mit
Toleranz vielleicht 52.5834 - 52.75) gibt's wohl kaum eine bessere
Loesung.

Schoenen Gruss
Martin

[Stefan Froehlich]

Post by Martin Trautmann

Post by Stefan Froehlich
Warum jetzt dagegen entscheiden, wenn es spaeter relevant werden
_koennte_. Datumseintraege sind ideal dafuer geschaffen, auch als
solche abgespeichert zu werden - in Textformat kann man sie dann
immer noch konvertieren, wo man es benoetigt.

du setzt aber voraus, dass tatsaechlich konkrete Datumseintraege
existieren wuerden.

Nein.

Post by Martin Trautmann
Ich beobachte, dass im Maerz 2005 eine Gemeinde noch eigenstaendig war.
Zum halbjaehrlichen Update im September stelle ich fest, dass diese
Gemeinde aufgeloest wurde.
Was traegst du nun als Datum fuer diese Aenderung ein? 2005-03-01?
2005-09-01?

Wenn Du das Datum nicht genauer lokalisieren kannst, ist es _im_Prinzip_
vollkommen egal, welches der beiden Daten (oder auch irgendeines
dazwischen) Du eintraegst. Das aktuelle Datum wuerde sich im konkreten
Fall vielleicht eher anbieten. Aber es ist immer noch ein Datum und
keine Zeichenfolge, daher sollte es auch als ein solches behandelt
werden.

Der Text "2005-Q2" mag Dir vielleicht das zweite Quartal symbolisieren,
in Abfragen hilft er Dir aber wenig. Und selbst "2005-03" unterscheidet
sich beim Suchen kaum von "2005-03-01 00:00:00.000". Die Information,
dass der Zeitpunkt relativ unbestimmt ist, wird kaum in einer Abfrage
relevant sein.

Aber: suche nach allein Eintraegen, die besonders instabil sind (also
beispielsweise solche, fuer die > 2 Datensaetze existieren, bei denen
zwischen valid_from und valid_until weniger als 9 Monate vergangen sind.
Viel Spass mit dem Textfeld...

Post by Martin Trautmann
Gerade daher lehne ich aber ab, mit einer erzwungenen taggenauen
Datumsangabe eine Genauigkeit vorzugeben, die nicht mal auf den Monat
genau gewaehrleistet ist.

Das ist die Sichtweise eines Naturwissenschaftlers, so habe ich das auch
einmal gelernt :-)

Alleine: die Darstellung sollte in Datenbanken moeglichst normiert sein.
Ueberschuessige Genauigkeit ist dabei zwar ab und an nicht elegant, aber
abgesehen vom Platzbedarf auch nicht stoerend.

Post by Martin Trautmann
Umgekehrt ist eine Umrechung der liberaleren Text-Version jederzeit in
eine taggenaue Datumsversion ebenso moeglich

Siehe oben - fuer komplexere Abfragen sind Textangaben vollkommen
unbrauchbar und daher zu vermeiden, wo immer es nur machbar ist.

Post by Martin Trautmann
Was aber erst mal an Information verloren ist, weil's nicht in ein
starres Formatraster passt, das bekommen wir nicht wieder.

Du verlierst ja aber keine Information, sondern gewinnst ein wenig an
Redundanz (bzw. eigentlich an Rauschen). _Wenn_ Dir die Genauigkeit
der Zeitangaben im Datenbankmodell wirklich ein Anliegen ist, dann
sollte dafuer eher noch ein eigenes Feld eingefuehrt werden - das haette
dann wieder Struktur. Ich bezweifle allerdings die Notwendigkeit.

Servus,
Stefan

[Martin Trautmann]

Post by Thomas Mack

Post by Martin Trautmann
Diese Woche: 2005-W16

[Datumsvergleiche]

ausserordentlich geeignet. Mag sein, dass die Woche 2005-W16 hier aus
dem Rahmen faellt, wie auch z.B. ein Quartal 2005-Q3 - aber es wuerde
fuer alles im Jahr 2004 oder nach z.B. 2003 korrekt gefunden werden.

Das meinte ich. Es wird schwammiger hier. Vielleicht macht das nichts,
kann schon sein.
Datumsarithmetik: Mit den SQL Datentypen kann man so etwas machen wie
heute - 2 weeks oder solche Geschichten. Diese Möglichkeiten verliert
man mit Texteinträgen. Auch hier wieder: es ist fraglich, ob es
relevant ist.

Heute - 2 weeks = alles ab 2005-04-11. Damit verliert man evtl. Eintraege
mit nur 2005-04. Aber die haettest du auch nicht gefunden, haettest du das
Datum auf 2005-04-01 vordatiert.

Heute - 4 weeks wuerde alles suchen, das nach 2005-03-25 kaeme. Damit
waere sowohl 2005-04-01, als auch 2005-04 gefunden worden. Die Suche
erfolgt dann eben natuerlich nicht auf Integer-Werten im Datumsformat,
sondern auf Textwerten. Sind die in der Performance deutlich schlechter,
oder was spricht dagegen?

Post by Thomas Mack

ich wuerde keine Dummyeintraege fuer valid-until verwenden, die auf
irgendein fiktives Datum doomsday verweisen, sondern dann lieber das
Feld leer belassen. Wofuer brauchst du denn ein valid_until mit
'unendlichem' Wert?

Das hat den Vorteil, daß man bei Anfragen einfach WHERE valid_until

= 'today' schreiben kann. Das ist auch die Logik dahinter, wenn man

aktuelle Daten sucht. Ich finde es angemessen, wenn man es in dieser
Form ausdrückt. In Postgres gibt es so etwas wie ein "unendliches Datum",
was in etwa diesen Sinn hat. Nur ist mir nicht ganz klar, wie groß die
sprich, ist es ein verbreiteter Standard oder eine Postgres Spezialität?

Wozu ueberhaupt suchen nach 'WHERE valid_until >= today'?
Entweder wir haben noch keine historischen Eintraege - dann braucht man
valid_until ueberhaupt nicht zu beachten.

Oder wir haben historische. Wenn man dann tatsaechlich nur aktuell
gueltige hat, so ist logisch gleichwertig die Vernkuepfung mit
'where valid_until not < today'. Oder ergibt das Fehlermeldungen, wenn
valid_until undefiniert waere?

Schoenen Gruss
Martin

[Thomas Mack]

Hallo Martin,

in der Datumsdiskussion ging es ursprünglich nur darum, wie ich
Zeitpunkte in der aktuellen Variante mit valid_since / date_type_since /
valid_until / date_type_until umsetze, um möglichst kompatibel zu dem
Format zu bleiben, das ich für Zeitbereiche eingeführt hatte.

Mehr wollte ich eigentlich nicht diskutieren, im Moment. Wenn ein
Textformat wesentliche Vorteile in der Praxis bringen würde, oder
anders gesagt: wenn das jetzige Format als zu umständlich und /
oder als ungeeignet empfunden wird, können wir darüber nochmal
neu nachdenken. Momentan läuft es so wie es halt läuft. Und es hat
sich nie jemand darüber beklagt. Vielleicht weil das DB-Format noch
immer nicht viele Freunde gefunden hat, wer weiß.

Grüße,
Thomas

Post by Martin Trautmann
Wozu ueberhaupt suchen nach 'WHERE valid_until >= today'?
Entweder wir haben noch keine historischen Eintraege - dann braucht man
valid_until ueberhaupt nicht zu beachten.

Haben wir.

Post by Martin Trautmann
Oder wir haben historische. Wenn man dann tatsaechlich nur aktuell
gueltige hat, so ist logisch gleichwertig die Vernkuepfung mit
'where valid_until not < today'. Oder ergibt das Fehlermeldungen, wenn
valid_until undefiniert waere?

Wenn es NULL wäre, würde der Vergleich nicht funktionieren. Man könnte
höchstens definieren: valid_until is NULL => Unbekanntes Datum in der
Zukunft. Und dann erweitert man die Abfrage: ... OR valid_until is null.