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

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

kreuzschnabel · 2019-03-02T11:14:34.000Z

Der Waldameisenschreck hat recht. Im Schreibfenster habe ich „Geht doch einwandfrei“ aus den mathematischen Bachstuben setzen können, aber im fertigen Beitrag werden nur Fragezeichen ausgeliefert (0x3F im HTML-Code, also kein Darstellungsproblem meinerseits, und Chromium hat auch kein solches mit Unicode).

–ks

Prince_Kassad · 2019-03-02T11:21:51.000Z

Da muss man halt die Serversoftware von Windows NT 4.0 mal endlich upgraden, dann klappt es auch mit dem Unicode.

(scnr)

kreuzschnabel · 2019-03-02T11:32:21.000Z

Prince Kassad:

Da muss man halt die Serversoftware von Windows NT 4.0 mal endlich upgraden,

In dem Fall müsste man eher NT 4.0 runterwerfen und eine Serversoftware aufspielen

telnet forum.openstreetmap.org 80:

Server: Apache/2.4.29 (Ubuntu)

Gut, den String kann man adminseitig beliebig setzen, auch auf einem IIS unter NT 4.0

–ks

Connecticut · 2019-03-02T11:54:17.000Z

Prince Kassad:

Da muss man halt die Serversoftware von Windows NT 4.0 mal endlich upgraden, dann klappt es auch mit dem Unicode.

(scnr)

prinzipell funktioniert utf-8.

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

Nur bestimmte Unicode-Blöcke gehen nicht.

wambacher · 2019-03-02T12:05:39.000Z

kreuzschnabel:

Der Waldameisenschreck hat recht. Im Schreibfenster habe ich „Geht doch einwandfrei“ aus den mathematischen Bachstuben setzen können, aber im fertigen Beitrag werden nur Fragezeichen ausgeliefert (0x3F im HTML-Code, also kein Darstellungsproblem meinerseits, und Chromium hat auch kein solches mit Unicode).

–ks

4-stellige Unicodes (2 bytes) funzen: - zumindest bei mir.

mmd · 2019-03-02T12:07:40.000Z

MySQL (die Datenbank) kann keine UTF-8 Zeichen mit 4 Bytes, deshalb ersetzt die Forensoftware das durch Fragezeichen.

https://github.com/fluxbb/fluxbb/blob/master/include/functions.php#L2070-L2074

Connecticut · 2019-03-02T12:16:37.000Z

mmd:

MySQL (die Datenbank) kann keine UTF-8 Zeichen mit 4 Bytes

den Zeichensatz der Tabelle auf utf8mb4 ändern.

mmd · 2019-03-02T12:23:33.000Z

Es gibt da Anleitungen zu, was da noch alles an fluxbb geschraubt werden muss. Den Zeichensatz der Tabelle zu ändern bringt erstmal keine Veränderung.

Hier gab’s doch mal einen Admin, der sich um das Ding gekümmert hat, scheint aber schon länger nicht mehr aktiv zu sein.

Weide · 2019-03-02T19:17:06.000Z

dieterdreist:

ich verstehe das Problem nicht. Klar kann man solche unüblichen Unicode Zeichen in den Keys benutzen,…

Es geht mir garnicht primär um unübliche Zeichen. Man kann z.B. “fixme” als key verwenden aber auch “FIXME”. Beides ist üblich und wird als gleich betrachtet. Unsere Zusage “es gibt keine doppelten Keys in einem Datensatz” gilt aber nicht mehr, wenn wir solche Fälle als gleich betrachten.

Das ist kein Problem für Mapper beim Betrachten oder Editieren … aber es kann in Programmen böse Folgen haben. Aufeinanderfolgende Abfragen “desselben” Keys können zwei verschiedene Werte liefern und Programme müssen den Fall berücksichtigen und dürfen sich nicht auf das “Keys sind nie doppelt” verlassen.

mmd · 2019-03-02T19:47:49.000Z

Weide:

Es geht mir garnicht primär um unübliche Zeichen. Man kann z.B. “fixme” als key verwenden aber auch “FIXME”. Beides ist üblich und wird als gleich betrachtet. Unsere Zusage “es gibt keine doppelten Keys in einem Datensatz” gilt aber nicht mehr, wenn wir solche Fälle als gleich betrachten.

Ein Tag-Key ist ja erstmal nur rein technisch definiert als ein Unicode-String mit maximal 255 Zeichen. Dein “Betrachten” von Keys sehe ich als Interpretation der Daten auf semantischer Ebene, und wenn du hier zwei technisch unterschiedliche Strings auf denselben Wert mapst, weil deiner Logik nach beide dasselbe ausdrücken, kann das logischerweise auch zu Konflikten führen. Um diese Konflikte müsstest du dich aber auch selbst kümmern, da es keine allgemeingültigen Regeln gibt, welche technisch abweichende Keys als semantisch äquivalent zu betrachten sind.