Rework transmitter_groups structure

[dh3wr]

Bis jetzt gibt es ja ein Array aus Strings in der Form a.b.c.d die entsprechend bei Angabe einer Teilmenge (z.B. a.b) auf alle a.b* ausgedenht werden. Wenn man nun geografische Referenzen die Landeskenner.Unter-Land verwendet, könnten in den Bezeichnern auch Punkte vorkommen. Insb. wenn man diese Zuordnung mittels https://wiki.openstreetmap.org/wiki/Nominatim automatisch vorschlägt. Da es eigentlich keinen Grund gibt, hier eine eigene Syntax mittels . zu machen, könnte man auch die Struktur direkt in JSON abbilden und wäre von speziellen Zeichen unabhängig.

Ebenso würde ich die Zwecks besserer Darstellung in der GUI die geografischen Gruppen von wahlfreien Gruppen-Namen wie "Alle Sender vom OV Z98" trennen, so dass man im Auswahldialog dies besser unterscheiden kann. Es wird ja im Grund bei der "4 Unterkategorien-Geografischen-Zuordnung" genau so viele diskunjkte Gruppe wie Sender geben. Dazu dann noch die Wahlfreien. Um das besser Darstellen zu können schlage ich folgende Schema vor:

"transmitter_groups": {
  "geo": [
     ["dl","Nordrhein-Westfalia","Aachen"],
     ["nl","Brabant","Vaals"]
  ],
  "arbitrary" : ["Nordsee-Inseln", "HappyPagingGroup Transmitters"],
  "special": ["dx-cluster"]
}

[7h0ma5]

Die Gruppen direkt als JSON-Arrays zu speichern macht Sinn, weil in CouchDB beim Map-Reduce für jede Gruppe eh ein group.split(".") ausgeführt wird und so genau dieses Array erzeugt wird.

Ob es Sinn macht UTF-8-Strings mit Groß-/Kleinschreibung und Leerzeichen als eindeutige ID zu verwenden ist eine andere Frage. Mit CouchDB wäre das natürlich problemlos möglich.

Die Verwendung eines Objektes für die Transmitter-Gruppen halte ich für überflüssig, da es sich weiterhin um eine Baumstruktur handelt, die sich auch mit dem alten Verfahren abbilden lässt:

"groups": [
    ["geo", "dl", "Nordrhein-Westfalia", "Aachen"],
    ["geo", "nl", "Brabant", "Vaals"],
    ["arbitrary", "Nordsee-Inseln"],
    ["arbitrary", "HappyPagingGroup Transmitters"],
    ["special", "dx-cluster"],
]

Wenn man es so machen würde wie bei den geografischen Gruppen, müsste es auf der obersten Ebene eigentich "Geographical", "Arbitrary" und "Special" heißen.

Für diese Namen sollte es dann eine Übersetzung im Frontend geben. Für die geografischen Namen gibt es ja auch oft Übersetzungen, die in den OpenStreetMap-Daten vorhanden sein müssten.

Auch deshalb wäre es schon schöner, wenn für alle Gruppen, inklusive der geografischen, möglichst kurze Identifier in Kleinschreibung und ohne Leerzeichen verwendet werden, die dann im Frontend durch den ausführlichen Namen je nach Sprache ersetzt werden.

[dh3wr]

Hallo @7h0ma5,
Danke für die Antwort. Zur Struktur: ok,
Ich bräuchte für das Webfrontend eine CouchDB Abfrage nach Typ des ersten Eintrags. Also gebe mir alle Gruppen mit "geo" vorne. Oder sogar im besten Fall mit startkey und endkey frei wählbar, dann ist man flexibel.

Zur i8n der Einträge: Ja, darüber habe ich auch schon nachgedacht. Man kann bei nominatim-Anfragen die Sprache der Antwort festlegen. Die "geografischen, möglichst kurze Identifier in Kleinschreibung und ohne Leerzeichen" muss man dann allerdings von Hand machen und auch die entsprechende Übersetzung irgendwo sinnvoll speichern. In der bis jetzt verwendeten POEditor JSON Datei sehe ich das als schwierig an, weil die Einträge ja dynamisch sind. Vielleicht wäre eine Lösung, direkt "alle" (was auch immer das ist) Sprachen bei nominatim abzufragen und im Transmitter-Objekt zu speichern?

Wenn man die Kurzformen als ID nimmt, bräuchte man ein Mapping von Kurzform -> Langform(Sprache)
Ideen für eine Umsetzung?