Keys in einem Tag: Länge, Gleichheit, ...

mmd · 2019-03-01T08:43:59.000Z

Weide:

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?

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.

Weide:

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?

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.

Prince_Kassad · 2019-03-01T08:46:27.000Z

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)

kreuzschnabel · 2019-03-01T08:52:25.000Z

mmd:

Das wäre nicht wirklich logisch auf der einen Seite beid en Values mit Characters und auf der anderen Seite bei den Keys mit Bytes zu arbeiten.

Darum geht’s ja nicht, sondern darum, in Keys z.B. nur ASCII-Zeichen zuzulassen, eben damit …

mmd:

Es gibt heute schon Leute die komische Zeichen (z.B: kyrillisch) in Keys ermitteln und die fixen.

… 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

–ks

mmd · 2019-03-01T08:53:39.000Z

kreuzschnabel:

Darum geht’s ja nicht, sondern darum, in Keys z.B. nur ASCII-Zeichen zuzulassen

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.

Wer sich gerne ein Bild von einer ähnlichen Diskussion machen will, kann gerne hier vorbeischauen: https://github.com/zerebubuth/openstreetmap-cgimap/pull/174

SimonPoole · 2019-03-01T09:21:03.000Z

mmd:

kreuzschnabel:

Darum geht’s ja nicht, sondern darum, in Keys z.B. nur ASCII-Zeichen zuzulassen

Weide hat doch oben für “Bytes” argumentiert. Das ist aber nicht die Logik, die heute zum Einsatz kommt für die 255 Zeichen!

“Chaos” wäre besser als “Logik” siehe auch https://github.com/openstreetmap/openstreetmap-website/issues/1593

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.

Weide · 2019-03-01T09:44:05.000Z

mmd:

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.

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.

mmd · 2019-03-01T09:45:24.000Z

SimonPoole:

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.

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.

mueschel · 2019-03-01T10:10:29.000Z

kreuzschnabel:

Darum geht’s ja nicht, sondern darum, in Keys z.B. nur ASCII-Zeichen zuzulassen, eben damit …

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)

Prince_Kassad · 2019-03-01T10:17:56.000Z

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.

kreuzschnabel · 2019-03-01T10:28:21.000Z

mueschel:

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.

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.

–ks

mmd · 2019-03-01T10:38:02.000Z

Es gibt z.B. 1319 Nodes, 169 Ways und 37 Relationen mit Han-Schriftzeichen im Key: http://overpass-turbo.eu/s/Gyh

Beispiel mit Subkeys: https://www.openstreetmap.org/relation/7720774 oder https://www.openstreetmap.org/node/5960561088 (für Zahlungsmittel)

mueschel · 2019-03-01T11:33:48.000Z

kreuzschnabel:

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.

seichter · 2019-03-01T11:49:51.000Z

mmd:

Es gibt z.B. 1319 Nodes, 169 Ways und 37 Relationen mit Han-Schriftzeichen im Key: http://overpass-turbo.eu/s/Gyh
Beispiel mit Subkeys: https://www.openstreetmap.org/relation/7720774 oder https://www.openstreetmap.org/node/5960561088 (für Zahlungsmittel)

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?

MitteloberrheinischerWaldameisenschreck · 2019-03-01T12:09:56.000Z

Weide:

Es wäre sogar das Folgende in einem Datensatz erlaubt:
description=xxx
descriptiοn=yyy

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!

mueschel · 2019-03-01T12:10:56.000Z

seichter:

Muss denn der Name der Organisation o.ä. unbedingt in der Originalschrift stehen?

Ich denke schon. Es sei denn, man kann sich auf eine eineindeutige Transliteration einigen.

seichter:

Ich halte selbst ref: in irgendeiner Schrift für sehr kritisch, denn die Darstellung dieser Codes ist nicht garantiert

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.

MitteloberrheinischerWaldameisenschreck · 2019-03-01T12:11:14.000Z

Hmmm … Das Forum scheint nicht unicodetauglich … Schwach! Zu sehen wären Auswahlen hieraus …

seichter · 2019-03-01T13:52:47.000Z

mueschel:

seichter:

Muss denn der Name der Organisation o.ä. unbedingt in der Originalschrift stehen?

Ich denke schon. Es sei denn, man kann sich auf eine eineindeutige Transliteration einigen.

Mir würde ein eineindeutiger und lesbarer Phantasie-Key schon reichen.

seichter:

Ich halte selbst ref: in irgendeiner Schrift für sehr kritisch, denn die Darstellung dieser Codes ist nicht garantiert

mueschel:

Naja, wer muss Keys schon anzeigen können?

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.

dieterdreist · 2019-03-02T09:00:17.000Z

Weide:

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

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.

Connecticut · 2019-03-02T11:00:31.000Z

MitteloberrheinischerWaldameisenschreck:

Hmmm … Das Forum scheint nicht unicodetauglich … Schwach!

?

中华字海

prinzipell funktioniert utf-8.

zB das Theta: θ
U+03B8
auch die Variante ϑ (U+03D1)

kreuzschnabel · 2019-03-02T11:08:13.000Z

MitteloberrheinischerWaldameisenschreck:

Das Forum scheint nicht unicodetauglich

??? ??? ???.

(OK, etwas mühsam, einzelne Bachstuben zu koppipäisten.)

–ks