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

[Peter Wendorff]

Hallo Frank.

Frank Glück schrieb:
> 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 ...
>   
Also mit mir persönlich sicher nicht - da muss man schon mit 
Beleidigungen oder so kommen ;)
> 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?
>   
Ja, ist eine Idee, die ich nicht ablehnen würde.
> 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.
>   
Zum Beispiel, dass durch den reinen Prosateil niemandem geholfen wäre.
Was kann ich mit der Information "bei Wurzen" anfangen?
Sinnvoll wäre, sowohl "Brandis" als auch "Brandis bei Wurzen" 
aufzunehmen, womit der Suche nach Orten genüge getan wäre; davon könnte 
"Brandis" als Name und "Brandis bei Wurzen" als alternativer Name oder 
so geführt werden - analog natürlich bei allen anderen Orten mit dieser 
Problemstellung.
Wer dann - wie ja einige wollten - nur offizielle Schreibweisen braucht, 
könnte die alternativen dann simpel über den Typ löschen.
>> 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.
Stimme ich Dir zu.
>  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.
Die Idee ist gut - aber wie an so vielen anderen Stellen auch:
Das Problem taucht auf, sobald sich Nutzer selbst Gedanken darüber 
machen müssen, wie sie das tun können - denn viel zu viele tun gerade 
das eben nicht.
Deshalb müssen die Daten entweder mitgeliefert werden, oder aber es muss 
eine Anleitung existieren, wie sie erzeugt werden können.
Also Aufgabe für Dich (oder jeden anderen Freiwilligen): Schreibe ein 
SQL-Script, das genau das leistet - lösche aus einer bei dir lokalen 
opengeodb-Installation alle Sortiernamen heraus und erzeuge per 
SQL-Befehlen diese aus den noch vorhandenen Daten - das sollte ja 
möglich sein, wie Du (und ich stimme Dir zu) behauptest.
Wenn dabei korrekte Daten herauskommen, stelle das Script hier zur 
Diskussion und ich bin sicher, auch Martin wird nichts dagegen haben, es 
der breiten Masse zur Verfügung zu stellen - und dann auf Dauer auch die 
Sortiernamen aus den Dumps entfernen.
>  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.
>   
Dass das für so ziemlich jede Scriptsprache recht einfach hinzubekommen 
ist, ist durchaus korrekt.
Nur:
1) die wenigsten Nutzer machen sich tatsächlich so weitreichende 
Gedanken, die meisten werden sich beschweren, dass das, was vorher ging, 
mit aktuellen Versionen einfach nicht mehr geht
2) SQL-Befehle muss man natürlich nicht zur Verfügung stellen, aber die 
Dokumentation sollte da sein - und dann sollte das ganze in irgendeiner 
Sprache soweit umgesetzt worden sein, dass die Dokumentation auch auf 
Verwendbarkeit getestet ist. Wenn das nicht SQL ist, ist das egal - es 
auch oder nur in SQL zur Verfügung zu stellen, kann aber nicht schaden.

Gruß
Peter