Hmm. Das wären dann bis 2048 UTF-8 Bytes. Ist das wirklich so gedacht? Lässt die Datenbank das zu? Können die Editoren das verdauen?
Das ist m.E. eine schöne vernünftige Regel. Aber…
Wollen wir denn wirklich, dass
description=xxx
description=yyy
verboten ist während
description=xxx
Description=yyy
erlaubt ist?
Es wäre sogar das Folgende in einem Datensatz erlaubt:
description=xxx
descriptiοn=yyy
(Die Keys sind verschieden … man sieht es nur nicht … da steckt ein griechisches Omikron drin)
Es geht sogar noch wilder. In UTF-8 kann man dasselbe Zeichen manchmal auf mehrere Arten ausdrücken. Da haben wir den gleichen Unicode aber verschiedene UTF-8 Darstellungen. Alle Bytestring-Vergleiche wären damit nicht korrekt.
Sollten wir da nicht lieber sagen, dass ein Key maximal xxx Byte haben darf und dass die Gleichheit von Keys nicht zwischen Groß- und Kleinbuchstaben unterscheidet und das in Keys nur ein Subset von Unicode erlaubt ist?
Ja, das ist so gedacht und die Editoren können das auch so. Der Datenbank ist das eigentlich egal, da könnten auch noch längere Strings drinstehen, allerdings kümmert sich die API um die 255 Zeichen-Grenze.
Das wäre nicht wirklich logisch auf der einen Seite bei den Values mit Characters und auf der anderen Seite bei den Keys mit Bytes zu arbeiten.
Es gibt übrigens heute schon Leute die komische Zeichen (z.B: kyrillisch) in Keys ermitteln und die fixen.
Wobei ich den Nutzen von Bytes >U+FFFF in OSM stark bezweifeln darf, auch wenn es wohl tatsächlich Scherzkekse gibt, die Emoji in Tags benutzen (und damit einige Editoren kaputtmachen, wie ich gehört habe)
Darum geht’s ja nicht, sondern darum, in Keys z.B. nur ASCII-Zeichen zuzulassen, eben damit …
… diese Leute ihre in OSM investierte Zeit produktiver verbringen können. Dieses Zitat bestätigt ja, dass kyrillische Zeichen in Keys grundsätzlich falsch sind
Weide hat doch oben für “Bytes” argumentiert. Das ist aber nicht die Logik, die heute zum Einsatz kommt für die 255 Zeichen!
Ist für mich eher eine Sache, um die sich ein Validator im Editor kümmern sollte. Da könnte z.B. als Warnung herauspurzeln: “Key enthält Zeichen, die nicht dem erwarteten UTF-8 Subset entsprechen”.
Das Problem, was ich mit der API sehe, ist: für diese Art von Einschränkungen braucht es erst einen Konsens, das ganze muss über /api/capabilities nach außen abfragbar sein, alle Editoren müssen das dann entsprechend auswerten können und berücksichtigen, also alles in allem mal wieder ein Riesenaufwand.
Ich gehe davon aus, dass die meisten Editoren die Längenbeschränkung auf die eine oder andere Art schon überprüfen, das wäre also vermutlich tatsächlich mal kein so grosser Aufwand.
OK. Dann ist der Teil mit den Characters/Bytes erledigt.
Das Problem der Gleichheit und der doppelten Keys existiert dann aber weiterhin. Es ist für OSM-Daten verarbeitende Programme sinnvoll, gegenüber Groß- und Kleinschreibung in Keys tolerant zu sein und allenfalls Anmerkungen zu machen. Sobald ein solches Programm aber davon ausgeht wird die Regel von den nicht doppelt vorkommenden Keys eine praktisch unbrauchbare technische Spielerei.
Ich muss sagen, dass ich da nicht ganz so optimistisch bin. Die meisten Editoren dürften wohl hier eher mit hartcodierten Werten arbeiten (was wiederum ein Thema für https://github.com/openstreetmap/openstreetmap-website/issues/2025 wäre). Dann müsste auch noch definiert werden, was ein zulässiges UTF-8 Subset ist und wie dies als Teil der capabilities ausgedrückt werden kann, etc. Also eher etwas im Bereich 6-12 Monate.
Einen Validator entsprechend aufzuschlauen dürfte um einiges schneller umzusetzen sein, einfach weil die ganzen technischen Abhängigkeiten und Abstimmungen wegfallen.
Das kann durchaus zu Problemen führen. Wir haben standardmäßig viele “ref:XYZ” Tags, bei denen XYZ irgendeine Organisation oder anderer Name ist. Wenn du nur ASCII zulässt, muss die halbe Welt ihre Namen transliterieren, was in vielen Fällen noch nicht mal eindeutig möglich ist. Also lieber den Originalnamen im passenden Alphabet im Key haben, als noch mehr Inkonsistenzen zu produzieren.
(Dass abgesehen davon alle Keys die definierten, englischen Kürzel/Worte verwenden sollten steht außer Frage)
Ich glaube, das war Ironie. Solange OpenStreetMap Länder wie Russland und China abdeckt, können wir gar nicht auf ASCII-only umsteigen, denn die betroffenen Länder wollen sicher nicht auf ihre eigene Sprache verzichten.
Hallooooo? Es geht um den Kii-hiiiee! Das ist das, was vor dem Gleichheitszeichen steht. Natürlich darf ein chinesischer Name in chinesischen Schriftzeichen eingesetzt werden. Aber davor sollte name= stehen, in 7bit-ASCII.
Sorry, Lesen bildet. Es geht dir nicht um Values, sondern um Subkeys. Ich ziehe den Sarkasmus reumuetig zurueck.
Aber muss im Subkey wirklich ein Name stehen? Wenn an einem building=* auch ein shop=* klebt, der einen russischen Namen hat, dann steht der russische Name doch als Value im shop:name=* (fände ich logischer) oder name:shop=* und nicht im Subkey.
Ich meine nicht den Namen des Objekts, sondern der Organisation, die eine ‘ref’ Nummer vergibt. Davon haben wir Millionen in der Datenbank: https://taginfo.openstreetmap.org/search?q=ref%3A
z.B. an ÖPNV-Haltestellen haben wir ref:IFOPT als international eindeutige Nummer, und die Nummer des lokalen Verbundes, z.B. ref:AVV
Ähnliches gibt es auch bei denkmalgeschützten Objekten.
So lange Englisch (genauer sogar BE) als Sprache für keys und subkeys (nicht für die Werte) verbindlich ist, müsste sogar 7-Bit ASCII reichen.
Ich halte selbst ref: in irgendeiner Schrift für sehr kritisch, denn die Darstellung dieser Codes ist nicht garantiert, da wir auf die richtige Auswertung von Unicode bei allen Anwendungen möglicherweise noch ein paar Jahrzehnte warten müssen, von der Darstellung unterschiedlicher Codes durch die selben Zeichen (Glyphen) mal abgesehen.
Muss denn der Name der Organisation o.ä. unbedingt in der Originalschrift stehen?
Das eröffnet ja ungeahnte Möglichkeiten!
statt old_name dann ???=
statt alt_name dann ???ℯ=
statt alt_name_1= dann ???=
statt alt_name_2= dann ???=
statt var_name_47= dann ???=
etc.
Ich liebe Unicode!
Ich denke schon. Es sei denn, man kann sich auf eine eineindeutige Transliteration einigen.
Naja, wer muss Keys schon anzeigen können? Die meisten Apps müssen nur damit arbeiten können, aber sie nicht darstellen. Lokale ref-Codes sind auch eher in einer lokalen Anwendung notwendig, und die muss natürlich die lokalen Schriften beherrschen. Andererseits müsste man mit transliterierten Keys wieder eine Lookup-Tabelle einbauen, die vom Key zurück auf die lokale Schreibweise geht. Stell dir vor, wir hätten statt ref:VRR nun ref:ВРР (kyrillische Buchstaben!) da stehen - damit kann hierzulande wohl kaum einer etwas anfangen.
Mir würde ein eineindeutiger und lesbarer Phantasie-Key schon reichen.
Nun ja, gelegentlich muss sich auch ein armer Mapper die Keys anzeigen lassen, es sei denn, man stellt sich auf den Standpunkt: Ein nicht einheimischer Mapper hat hier gefälligst nichts zu suchen.
ich verstehe das Problem nicht. Klar kann man solche unüblichen Unicode Zeichen in den Keys benutzen, aber die tags werden dann halt von niemand ausgewertet, es macht also aus Mappersicht keinen Sinn außer vielleicht als besonders obskure Variante von Vandalismus, die allerdings gut automatisch aufzuspüren wäre.
