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

[Sascha Mantscheff]

> 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?
>  
Abgeleitete Daten gehören nicht in den Grunddatenbestand. Wenn der Typ
500100002 aus ...0 berechnet werden kann, sollte die
Berechnungsvorschrift im Export enhalten sein. In MySQL kann man einen
entsprechenden Trigger formulieren, der auch bei Updates für
Datenintegrität sorgt.

> 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?
>  

Für sinnvoll halte ich:
- mit Punkt abgekürzte Bestandteile ausschreiben
- diakritische Zeichen normalisieren
- alle nicht-alphabetischen Zeichen entfernen
Ortsnamenszusätze nachstellen (NEUHAUSVERWALTUNGSGEMEINSCHAFT)

Aber da es sich um abgeleitete Daten handelt, kann das ja sowieso jeder
halten, wie er es
am ehesten braucht. Nur wäre es eben schön, eine explizite Regel zu
haben, die auch die sicherlich vorkommenden Sonderfälle berücksichtigt.
In welcher Weise die DB-Nutzer diese Regel dann einbauen, ist eine
Implementierungsfrage und sollte bei der Grunddatenpflege keine Rolle
spielen.

s.m.

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Andreas Labres]

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

Ländercodes (geografisch, ISO 3166): upper case
Sprachcodes (sprachlich, ISO 639):   lower case

z.B. 'BE' ist Belgien, 'be' aber weißrussisch
(auf http://de.wikipedia.org/wiki/ISO_3166 stehen weitere Beispiele)

 > Sortiernamen
 > Was ist hier am sinnvollsten?

Ein paar Beispiele aus AT:

"Gmünd" gibt es 4 Orte in Österreich (Bez. Gmünd in NÖ, Bez. Spittal an der Drau
in K, Bez. Schwaz in T und Bez. Bregenz in V). Zwei haben eigene Postleitzahlen:
3950 Gmünd, Niederösterreich und 9853 Gmünd, Kärnten (so nennt die Post sie).
Trotzdem sollte der Sortiername von allen "GMÜND" (wie immer der Umlaut zu
kodieren ist) sein.

Bei anderen Ortsnamen ist die nähere Ortsbestimmung aber Teil des Namens, z.B.
"Neusiedl am See", "Neusiedl am Walde", "Neusiedl an der Zaya", "Neusiedl bei
Güssing" oder "Matrei am Brenner", "Matrei in Osttirol" (z.B: Neusiedl *a*n der
Zaya kommt vor Neusiedl *b*ei Güssing). St. sollte zum Sortieren SANKT bedeuten
(dann Space, dann der weitere Name).

/al
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Andreas Labres wrote:
> Martin Trautmann wrote:
>> Was ist euch lieber, was ist besser? Ich selbst finde upper-case gewohnter,
>> kann aber gerne auf lower case umstellen.
>
> Ländercodes (geografisch, ISO 3166): upper case
> Sprachcodes (sprachlich, ISO 639):   lower case
>
> z.B. 'BE' ist Belgien, 'be' aber weißrussisch
> (auf http://de.wikipedia.org/wiki/ISO_3166 stehen weitere Beispiele)

Hallo Andreas,

sprechen wir vom gleichen?

>   >  Sortiernamen
>   >  Was ist hier am sinnvollsten?
>
> Ein paar Beispiele aus AT:
>
> "Gmünd" gibt es 4 Orte in Österreich (Bez. Gmünd in NÖ, Bez. Spittal an der Drau
> in K, Bez. Schwaz in T und Bez. Bregenz in V). Zwei haben eigene Postleitzahlen:
> 3950 Gmünd, Niederösterreich und 9853 Gmünd, Kärnten (so nennt die Post sie).
> Trotzdem sollte der Sortiername von allen "GMÜND" (wie immer der Umlaut zu
> kodieren ist) sein.

Die Hauptfrage ist, ob der Sortiername upper oder lower case sein
sollte. Dass der Umlaut ausgeschrieben wird, ist ohnehin schon
Voraussetzung. Es geht also darum, ob der Sortiername wie bis 0.2.4
"gmuend" oder wie seit 0.2.5 "GMUEND" sein sollte.

Ich habe keine Ahnung, warum hier einmal die Kleinschreibung favorisiert
wurde - ob das ein SQL-Standard wäre oder reine Willkür.
Von der Verdeutlichung als ASCII halte ich Großbuchstaben für sinnvoll.
Als Vorteil der Kleinbuchstaben fällt mir nur ein, dass man kein Shift
oder Caps Lock drücken müsse...

Schönen Gruß
Marrtin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Peter Wendorff]

Martin Trautmann schrieb:
> Ich habe keine Ahnung, warum hier einmal die Kleinschreibung favorisiert
> wurde - ob das ein SQL-Standard wäre oder reine Willkür.
> Von der Verdeutlichung als ASCII halte ich Großbuchstaben für sinnvoll.
> Als Vorteil der Kleinbuchstaben fällt mir nur ein, dass man kein Shift
> oder Caps Lock drücken müsse...
>  
Wenn sämtliche Sonderzeichen rausfallen, gebe ich Dir recht; allerdings
verweise ich auf die Problematik mit ss und ß, die ja gerade in unserem
Bereich, den deutschsprachigen Orts- und damit Eigennamen vorkommen.
Bei Kleinbuchstaben dagegen existieren alle Zeichen (soweit ich weiß).

Viele Grüße
Peter
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Peter Wendorff wrote:

> Wenn sämtliche Sonderzeichen rausfallen, gebe ich Dir recht

Es fallen sämtliche Sonderzeichen raus - 7bit ASCII.

Ich würde sogar so weit gehen, das ganze einzuschränken auf A-Z

Allerdings würde damit aus einer "Straße der 1822er" eine
"STRASSEDERER"

> allerdings
> verweise ich auf die Problematik mit ss und ß, die ja gerade in unserem
> Bereich, den deutschsprachigen Orts- und damit Eigennamen vorkommen.

ß wird zu SS, nicht etwa zu SZ. Es bleibt die Frage, was man aus einer
Schloss-Straße macht. Doppel- oder Dreifach-S? "SCHLOSSTRASSE"

Ich reduziere hier derzeit alle dreifach-S auf zweifach-S,
unterlasse das aber bei anderen Buchstaben.

> Bei Kleinbuchstaben dagegen existieren alle Zeichen (soweit ich weiß).

Nicht in ASCII - und vermutlich gibt's auch irgend eine Sprache, wo
manches nur gross oder klein vorkommt.

Schönen Gruß
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Ingmar Lötzsch]

Egal, was rauskommt, ich empfehle etwas festzulegen, was auf einfachste
Weise von einem Computer berechenbar ist - am besten ausschließlich mit
SQL - und möglichst wenig Ausnahmen macht.

- keine Buchstaben weglassen, etwa sss-> SS
- keine Buchstaben hinzufügen, etwa St. -> SANKT

Beim letzten Beispiel handelt es sich entweder um eine Abkürzung des
offiziellen Namens - dann sollte dieser unabgekürzt gespeichert werden,
etwa "Sankt" statt "St." - oder die offizielle Bezeichnung ist "St.
...". Dann wäre es wünschenswert, wenn man es bei St. -> ST belassen könnte.

Es könnte sein, dass manche Gemeinden die Abkürzung als offizielle
Bezeichnung festlegen, andere nicht. Dann könnte man die Forderung
aufstellen, dass so sortiert wird, als würde überall dieselbe Varainte
verwendet. Das ist durchaus plausibel, birgt aber die Gefahr, dass die
Zahl dieser Ausnahmen anwächst und irgendwann unübersichtlich wird.
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Simon Schmid]

Hallo,

das Problem mit den Namen ist mehr bekannt. Meiner Meinung nach
sollten immer die offiziellen Namen verwendet werden wie sie z.B. in
den Gemeinde/Orts/Bezirkslisten von Statistik Austria drin stehen.
Sollte der aktuell in der Datenbank befindliche Namen anders lauten,
sollte man diesen erhalten und die Gültigkeit (valid_until) "beenden"
weil der Name nicht mehr offiziell so gültig ist. Gefunden würde der
Datensatz schlussendlich mit beiden Namen. Aber wenn man alle Orte o.ä
auflisten möchte, kann man hier nur die offiziell gültigen Namen
auflisten lassen. Durch diese offiziell gültigen Namen wird auch das
Problem mit St. oder Sankt gelöst.

Ansonsten muss man halt für die gängisten Kürzel einen Filter einbauen
und halt noch eine 2. Bedinung einfügen wie WHERE name = "STPOELTEN"
OR name = "SANKTPOELTEN"

Buchstaben wie ein dreifaches 'S' wegzulassen, würde ich nicht machen.
Da ich z.B. in einer Suchabfrage das deutsche SZ durch ein doppel S
ersetzen würde. Und nicht prüfen möchte ob der vorherige oder
nachfolgende Buchstabe auch ein 'S' ist. Auch Zahlen würde ich im
Sortiernamen speichern, da diese ja ebenfalls nötig sind um den
Datensatz zu finden. Es sollte hier kein Informationsverlust
stattfinden, sondern lediglich eine einheitliche "Formatierung" sprich
7bit ASCII und UPPER- oder lowercase und keine Leerzeichen.

Gruss

Simon






















2008/1/23 Ingmar Lötzsch <iloetzsch@...>:

> Egal, was rauskommt, ich empfehle etwas festzulegen, was auf einfachste
> Weise von einem Computer berechenbar ist - am besten ausschließlich mit
> SQL - und möglichst wenig Ausnahmen macht.
>
> - keine Buchstaben weglassen, etwa sss-> SS
> - keine Buchstaben hinzufügen, etwa St. -> SANKT
>
> Beim letzten Beispiel handelt es sich entweder um eine Abkürzung des
> offiziellen Namens - dann sollte dieser unabgekürzt gespeichert werden,
> etwa "Sankt" statt "St." - oder die offizielle Bezeichnung ist "St.
> ...". Dann wäre es wünschenswert, wenn man es bei St. -> ST belassen könnte.
>
> Es könnte sein, dass manche Gemeinden die Abkürzung als offizielle
> Bezeichnung festlegen, andere nicht. Dann könnte man die Forderung
> aufstellen, dass so sortiert wird, als würde überall dieselbe Varainte
> verwendet. Das ist durchaus plausibel, birgt aber die Gefahr, dass die
> Zahl dieser Ausnahmen anwächst und irgendwann unübersichtlich wird.
>
> --
> Mailingliste OpenGeoDB
> Listenadresse: opengeodb@...
> Informationen: http://opengeodb.de
> Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Ingmar Lötzsch wrote:
> Egal, was rauskommt, ich empfehle etwas festzulegen, was auf einfachste
> Weise von einem Computer berechenbar ist - am besten ausschließlich mit
> SQL - und möglichst wenig Ausnahmen macht.
>
> - keine Buchstaben weglassen, etwa sss->  SS
> - keine Buchstaben hinzufügen, etwa St. ->  SANKT

Ja und nein - ein Dreh- und Angelpunkt ist, ob man den sortname
überhaupt mitgeben muss. Ich würde sagen: nein.

Ich gehe aber davon aus, dass man den sortname mitgeben kann - gerade in
den Fällen, wo er nicht durch eine ganz einfache Regeln reproduziert
werden kann wie

Zeichensatz -> Großschrift
Umlaute -> ausschreiben
Bindestriche, Leerzeichen -> Löschen

In allen komplizierteren Fällen ist der Sortname im export dump
enthalten, nur in den einfachen sollte er automatisch generiert werden.

Bei der Neuerstellung von Einträgen wird ein solcher sortname
automatisch angelegt. Jeder hat die Freiheit, diesen nachzubessern. Auch
solche Änderungen sind natürlich zulässig und mitzugeben.

> Beim letzten Beispiel handelt es sich entweder um eine Abkürzung des
> offiziellen Namens - dann sollte dieser unabgekürzt gespeichert werden,
> etwa "Sankt" statt "St." - oder die offizielle Bezeichnung ist "St.
> ...". Dann wäre es wünschenswert, wenn man es bei St. ->  ST belassen könnte.

Da unklar ist, ob und wann es offiziell ist, tendiere ich zum generellen
ausschreiben, sprich Umwandlung in die Form, in der es auch
ausgesprochen wird. Ich habe noch nie
"ess-te-Bindestrich-Georg-Bindestrich-schtra-sse" gehört und würde das
als Sortname "SANKTGEORGSTRASSE" verwenden wollen.


> Es könnte sein, dass manche Gemeinden die Abkürzung als offizielle
> Bezeichnung festlegen, andere nicht.

Kannst du das den Daten selbst ansehen? Ortsnamen sind immerhin halbwegs
bekannt und offiziell - aber schon bei den Zusätzen wird es beliebig
willkürlich. Heisst es "Xyz / Westerwald", "Xyz im Westerwald", "Xyz am
Westerwald", "Xyz (Westerwald)", "Xyz/WW", "Xyz WW." oder wie? Und das
sind nur einige der Variationen  um ein einziges Wort herum.

Von den Straßen her habe ich einen rechtt großen Erfahrungsschatz, was
offiziell beliebig falsch gehen kann. Solche Leute wie Gerhard/t
Hauptmann haben es der Stadt noch zusätzlich schwer gemacht ;-)

Was ist dann die Referenz? Der Stadtplan der Stadt, der
Gemeindebeschluss zur (fehlerhaften) Benennung, die korrekte Schreibweise?

Nur mal als Hausnummer: Ich habe mehr als 100 000 Ortseinträge. Bei
einem Drittel davon habe ich lange Namensvarianten. Bei 1895 habe ich
weitere Namensvarianten, z.B. gerade nach Namensänderungen wie Zugewinn
des Status als Bad:

Lobenstein, Thüringen
Lobenstein, Moorbad
Bad Lobenstein
Lobenstein

> Dann könnte man die Forderung
> aufstellen, dass so sortiert wird, als würde überall dieselbe Varainte
> verwendet. Das ist durchaus plausibel, birgt aber die Gefahr, dass die
> Zahl dieser Ausnahmen anwächst und irgendwann unübersichtlich wird.

So läuft's derzeit aber, wenn du mal sortname und name vergleichen
möchtest. Bei manchen Einträgen bin ich mir nicht wirklich sicher -
kannst du auf Anhieb beantworten, wie Hann. Münden ausgesprochen wird?

Schönen Gruß
Martin

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Andreas Labres]

Martin Trautmann wrote:
> Dass der Umlaut ausgeschrieben wird, ist ohnehin schon
> Voraussetzung.

Ok, also DIN-2.

> Es geht also darum, ob der Sortiername wie bis 0.2.4
> "gmuend" oder wie seit 0.2.5 "GMUEND" sein sollte.

IMO letzteres.

> Ich würde sogar so weit gehen, das ganze einzuschränken auf A-Z
>
> Allerdings würde damit aus einer "Straße der 1822er" eine
> "STRASSEDERER"

Dann stimmt aber die Sortierreihenfolge (und um die geht's hier ja doch?)
nimmer, z.B.:

...
SCHLOSS WOLFSBERG
SCHLOSS ZELLHOF   kommt vor
SCHLOSSAECKER
SCHLOSSAU
...

Ad Wortzeichen in der Sortierung:
Von mir aus kann man überlegen, Bindestrich durch Leerzeichen zu ersetzen.
Apostroph (so es vorkommt) müßte man weglassen. Der Abkürzungspunkt sollte wohl
nur bei 'St.' vorkommen (ist als SANKT zu sortieren), sonstige Wort- oder
Interpunktionszeichen dürften wohl nicht vorkommen.

NB: SSS zu SS zu machen ist nicht korrekt (insbesondere [aber nicht nur] nicht
nach der neuen Rechtschreibung):

Schloßleiten  SCHLOSSLEITEN   vor
Schloßsee     SCHLOSSSEE

Jedenfalls sollte man die Summe aller Regeln, wie man vom Begriff zum
Sortierbegriff kommt, irgendwo gesammelt dokumentieren (und festschreiben).

/al

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Andreas Labres]

Martin Trautmann wrote:
> Ja und nein - ein Dreh- und Angelpunkt ist, ob man den sortname
> überhaupt mitgeben muss. Ich würde sagen: nein.

ACK.

/al
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Robert Böck]

Martin Trautmann wrote:

> Ja und nein - ein Dreh- und Angelpunkt ist, ob man den sortname
> überhaupt mitgeben muss. Ich würde sagen: nein.

Aber natürlich gehört er in den Dump mit rein. Ansonsten müsste man nach
einem DB-Import den sortname erst umständlich mit einem Script bauen.
Denn UPPER() bzw. LOWER() Ziel führen leider nicht zum Ziel mit den
ganzen Sonderzeichen ...

Im Übrigen finde ich die Diskussion, ob nun GROSSBUCHSTABEN oder
kleinbuchstaben für den sortname verwendet werden sollen, müßig, weil es
für die Sortiererei völlig wurscht ist.

cu, Robo :)

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)