[opengeodb] ASCII-Schreibweise: upper/lower, mit/ohne Trennzeichen, kurz/lang (500100002)

[Martin Trautmann]

Hallo,

die Struktur der opengeodb sieht derzeit vielerlei Schreibvarianten vor,
speziell:

INSERT INTO geodb_type_names VALUES(500100000,'de','Name');
INSERT INTO geodb_type_names VALUES(500100001,'de','ISO 3166 Alpha-2');
INSERT INTO geodb_type_names VALUES(500100002,'de','Sortiername');
INSERT INTO geodb_type_names VALUES(500100003,'de','ISO_3166_2');

http://surfnet.dl.sourceforge.net/sourceforge/opengeodb/Constants.txt
beschreibt dazu:

        NAME                  500100000
        ISO_3166_1_ALPHA_2    500100001
        NAME_7BITLC           500100002 // 7 Bit, Lower case
        ISO_3166_2            500100003

Ich vermute, meine derzeitige Implementierung ist hier falsch, denn ich
verwende fuer 500100002 nicht lower case, sondern upper case.

Was ist euch lieber, was ist besser? Ich selbst finde upper-case gewohnter,
kann aber gerne auf lower case umstellen.

Wofuer dient ein solcher Sortiername? Bei mir ist er vor allem auch ein
Suchmerkmal, das schneller funktioniert, als ueber Gross-/Kleinschreibung,
mit und ohne Umlaute.

Mein naechster Fehler ist aber, dass ich hier die Schreibweise noch recht
unberuehrt lasse. Daher kann der gleiche Ort dennoch in unterschiedlichen
Schreibvarianten zu Problem fuehren. Was ist richtig?
* ALT RUPPIN
* ALT-RUPPIN
* ALTRUPPIN

Bisher belasse ich es hier bei der Originalschreibweise. Mein Vorschlag:
alle Trennzeichen fallen in Zukunft heraus: Leerzeichen und Bindestriche.

Was gehoert in den Sortiernamen aber hinein? Im Augenblick ist das ganz
pragmatisch: Der Name (500100000) enthaelt eine uebliche Langversion des
Namens (Beispiel: "Kehl am Rhein" oder "Kehl (Rhein)" zur Unterscheidung von
"Kehl in Bayern"). Der Sortiername enthaelt nur die Kurzversion ("KEHL"),
unterscheidet also in der Sortierung nicht ueber Namens-Zusaetze (was gerade
bei der Sortierung nach mehr als einem Merkmal deutlich unterschiedliche
Resultate ergibt).

Ist das fuer euch ok? 

Die lange Schreibweise ist manchmal in der Gemeinde selbst nicht unbedingt
gelaeufig: Bei Gemeindedaten entstammt diese Schreibvariante jenem Amt, das
den amtlichen Gemeindeschluessel erstellt und dabei bei Bedarf durch
Zusaetze verhindert, dass in diesem Verzeichnis gleichnamige Gemeinden
aufgefuehrt werden.

Was ist mit dem SQL-dump? Ist es ueberhaupt sinnvoll, die Datenmenge zum
Austausch, Archivierung, Versionierung mit diesen Daten aufzublaehen, statt
hier einen passenden SQL-Befehl aufzunehmen, der ueberall dort durch eine
moeglichst einfache Regel den Typ 500100002 aus 500100000 berechnet, wo dies
moeglich ist? Im SQL-Dump wuerden dann nur jene Daten uebergeben, wo nicht
automatisch der Wert von 500100002 sich aus lower(500100000) ergeben wuerde?

Und nach welchen aufwaendigeren Regeln sollte der Typ 500100002 bestimmt
werden?

Beispiele:
* Amt Neuhaus -> "NEUHAUS" oder "AMTNEUHAUS"
* Verwaltungsgemeinschaft Neuhaus -> "NEUHAUS" oder
"VERWALTUNGSGEMEINSCHAFTNEUHAUS"
* VG Neuhaus -> "NEUHAUS" oder "VGNEUHAUS"

... ich verwende hier bisher "NEUHAUS"

* St. Peter-Ording -> "STPETER", "SANKTPETER", "SANKTPETERORDING",
"STPETERORDING", ...
* Schloss-Str. -> "SCHLOSSSTRASSE", "SCHLOSSTRASSE", "SCHLOSSSTR",
"SCHLOSSSTR.", ...

Was ist hier am sinnvollsten? 

Schoenen Gruss
Martin


-- 
View this message in context: http://www.nabble.com/ASCII-Schreibweise%3A-upper-lower%2C-mit-ohne-Trennzeichen%2C-kurz-lang-%28500100002%29-tp14995797p14995797.html
Sent from the Php German - opengeodb mailing list archive at Nabble.com.