[opengeodb] Nochmal zu Prosa-Namen wie "Brandis bei Wurzen" (war: Inkonsistenzen der Download-Daten)

[Frank Glück]

Und hallo nochmal Martin bzw. alle,

ich habe die Liste leider noch nicht lange genug abonniert, so dass ich mit
meinem in den Fähigkeiten begrenzten Outlook keinen Reply auf den
Original-Thread setzen konnte.

In der Hoffnung, es mir hier zum Einstand nicht gleich mit allen zu
verscherzen, würde ich das Thema gern noch einmal aufgreifen und in dieser
Sache Andreas Müller zur Seite springen bzw. einen Kompromiss anbieten
wollen ...

Ich finde nämlich auch, dass ein Wert wie "Brandis bei Wurzen", da er
bereits selbst eine redaktionelle Ableitung aus den eigentlich zur Verfügung
stehenden Rohdaten "Brandis" und "bei Wurzen" darstellt, keine besonders
glückliche Lösung darstellt. Nach Aufarbeitung der etwas quälenden
Diskussion über Normalisierung und Atomarisierung Anfang dieses Monats
tendiere ich inzwischen zwar auch dazu, dass gerade die über den
vermeintlichen Umweg text_type gefundene DB-Struktur womöglich wirklich die
zukunftsoffenste ist, aber gerade diese Erkenntnis sollte doch auch dazu
ermutigen, für solche Metainfos wie "bei Wurzen" eben lieber noch einen
entsprechend zusätzlichen "atomarisierten" neuen text_type einzuführen,
oder?

Dazu nochmal ein Zitat von Martin:

> Es stehen durchaus verschiedene Methoden zur Verfügung, wie du dir die 
> Kurzformen ableiten kannst - z.B. indem du ab dem ersten 
> kleingeschriebenen Wort den Rest wegwirfst, ebenso alles nach einem 
> Komma, Schrägstrich oder Klammer.

Demnach kann man ja auch davon ausgehen, dass der "Prosateil" wirklich immer
an den offiziellen Namen anzuhängen ist und der umgekehrte Fall niemals
vorkommt(?) Was spricht dann dagegen, die beiden Datentypen einfach auch
getrennt voneinander vorzuhalten - dann soll sie doch derjenige für seine
speziellen Zwecke wieder zusammenführen, der sie wirklich in dieser Form
braucht.

> Wie du schon entdeckt hast, steht in 
> 500100002 genau das zur Verfügung, was du brauchst. Den Zusatzaufwand 
> der Konvertierung kannst du entweder im Moment der Abfrage machen oder 
> dir vorab eine Rückkonvertierung ausdenken, die über den ASCII-Teil dir 
> den relevanten Teil der Kurzform zurückgibt.
> Ebenso kannst du natürlich eine Wildcard-Suche verwenden, die dir alles 
> liefert, was mit Brandis beginnt.

Nein, umgekehrt: man sollte nicht darauf angewiesen sein, sich über Skripte
(womöglich noch über den redundanten Sortiernamen) mehr oder weniger
aufwändig das wiederherstellen zu müssen, was die Datenbank auch im
Rohformat liefern könnte. Ebenso, wie auch derjenige, der für seine
spezielle Anwendung Sortiernamen benötigt, sich diese doch nach seinen
eigenen Anforderungen, die ja weit auseinandergehen können, selbst erstellen
könnte. Informationen und Beispiele dazu, wie er das zu Wege bringt, würden
dann ins Wiki gehören. Und dass man diese in Form von SQL-Befehlen zur
Verfügung stellen müsste, halte ich ebenso für falsch. Denn das hier ...

>  tr/a-zäöüáàâãåéèêëíìïïóòôõçñ/A-ZÄÖÜAAAAAEEEEIIIIOOOOCN/;
>  tr/ÀÁÂÃÅÈÉÊËÌÍÎÏÒÓÔÕÇÑ/AAAAEEEEIIIIOOOOCN/;
>  Ä -> AE
>  Ö -> OE
>  Ü -> UE
>  ß -> SS
>  SSS -> SS 

sollte mit so ziemlich jeder Skriptsprache recht einfach hinzubekommen sein,
für viele Anwendungszwecke wohl sogar zur Laufzeit.

Schöne Grüße,
Frank