Wir haben in Österreich die Situation, dass Mobilfunknetzbetreiber Infrastruktur gemeinsam nutzen und teilweise auch fremde Masten als Träger für ihre Antennen verwenden. Dazu kommt, dass Mobilfunksender nicht als separate Objekte, sondern immer als Attribut an der entsprechenden Trägerstruktur erfasst werden.
Dies stellt ein Problem dar, wenn man erfassen möchte, welche Betreiber an einem Standort präsent sind. Der operator-Schlüssel ist in vielen Fällen ungeeignet, da die Trägerstruktur schon einen Betreiber hat, wie bei einem Strommasten. Der Strommast wird dann auch nicht von den Mobilfunkern mitbetrieben, sondern die haben da nur ihre Antennen dran montiert.
Ein weiteres Problem ist das erfassen der Standortbezeichnung. Wenn die Trägerstruktur schon eine Nummer hat, ist das Ergänzen der Mobilfunkstandorte in ref verwirrend. Außerdem ist eine Zuordnung von Betreiber und dessen Standortbezeichnung nicht möglich.
Daher habe ich mir folgendes Schema überlegt:
communication:mobile_phone:a1=yes
communication:mobile_phone:magenta=yes
communication:mobile_phone:drei=no # Oder alternativ weglassen
ref:a1=T326
ref:magenta=SASG131
Gibt es Kritik oder Vorschläge zu diesem Schema?
Bevor das Thema Verifizierbarkeit aufkommt: Die Standortbezeichnungen sind meistens als Aufkleber auf den Basisstationen drauf. Wenn man nicht zukommt, kann man sie auch nicht erfassen. Welchem Betreiber eine Basisstation gehört erkennt man entweder am Format der Bezeichnung oder an der Telefonnummer für Störungen. Man bekommt auch recht schnell ein Gefühl für die unterschiedliche Gestaltung.
Intuitiv würde ich trotzdem bei operator bleiben, weil das schon gut passen würde. Man könnte es mit einem prefix vom Mast(Trägerstruktur) Operator unterscheiden.
zB communication:operator:a1=yes oder
operator:communication:a1=yes
Und für den Fall, dass an einem Mast mehrere unterschiedliche Kommunikationsarten angeboten werden, wurde auch schon das spezifischere communication:mobile_phone:operator verwendet.
operator war nie ein yes/no Schlüssel. Ich finde ein Suffix sollte nicht die grundlegende Struktur des Schlüssels ändern, dafür spricht auch die aktuelle Verwendung von ihnen.
Da sehe ich kein Problem, das ist das übliche Schema wie es bei vielen Dingen verwendet wird. ref + Kurzname des Betreibers als Subkey. Über Groß/Kleinschreibung gibt es geteilte Meinungen, ich würde diejenige übernehmen die schon irgendwo anders verwendet wird (falls möglich).
Ich hätte das so interpretiert, dass nach der Wiki-Seite für die automatische Editierung gefragt wurde, nicht zum Schlüssel. Die würde mich nämlich auch interessieren.
Nein, mich hat die Doku für dieses Tag interessiert.
Wenn man hunderte Objekte mit etwas taggt, das noch nicht im Wiki steht, sollte man diese Seite anlegen. Das dient zum einen dazu, dass andere sehen, was man denn mit dem neuen Tag meint, und zum anderen ermöglicht es, dass andere es nachmachen.
Ok, dann interessiert mich die Dokumentation zur automatischen Editierung wohl alleine, aber ich halte sie trotzdem für sehr relevant für dieses Thema. Wäre gut, wenn @mueschel die noch liefert.
Achso, du meinst das Changeset an sich. Da gab es eine Diskussion in einem Changeset (Changeset: 181224672 | OpenStreetMap), bei der herauskam, das absichtlich eine falsche Schreibweise bei einem Import (tausende POIs, alle in eigenen Changesets) verwendet wurde, damit die Daten bei der Suche nicht stören.
Für die weiteren Importe wird jetzt das geänderte Schema verwendet.
Handelt es sich dann um eine nicht diskutierte oder dokumentierte automatische Editierung um die Fehler eines nicht genehmigten Imports aus einer nicht erlaubten Quelle zu korrigieren? Keine Ahnung was ihr da in Deutschland aufführt, aber es wirkt auf den ersten Blick nicht nach etwas, an dem man sich ein Beispiel nehmen sollte.