Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- meshcore:allgemeines:regions:definieren [03.02.2026 16:55] – [Wie schneidet man Regions am besten?] josch0
+++ meshcore:allgemeines:regions:definieren [05.02.2026 16:08] (aktuell) – [Dürfen sich Regions überlappen?] josch0
@@ Zeile 1: / Zeile 1: @@
 ====== Regionale Regions definieren ======
-Bevor ihre eigene regionale Regions definiert, schaut erstmal nach ob es in eurer Gegend schon Regions und Festlegungen der Communities gibt:
+Bevor eigene regionale Regions definiert werden, bitte erstmal nachschauen ob es in der Gegend schon Regions und Festlegungen der Communities gibt:
-  * [[https://umap.openstreetmap.de/de/map/anonymous-edit/122026:q5Zzdc4m5CMARPVFTeGo6OiZWFDMmqiARlvOv7FBIBs|Regions Karte Deutschland]]
+  * [[basis|Deutschlandweite "Basis Regions"]]
-  * [[reale-regions-in-repeatern|Festlegungen der Communities]]
+  * [[https://umap.openstreetmap.de/de/map/anonymous-edit/122026:q5Zzdc4m5CMARPVFTeGo6OiZWFDMmqiARlvOv7FBIBs|Karte mit regionalen Regions]]
+  * [[reale-regions-in-repeatern|Festlegungen der regionalen Communities]]
 \\
@@ Zeile 11: / Zeile 12: @@
 Bei der Definition von regionalen Regions muss man sich im Vorfeld einige grundlegende Gedanken machen, damit Regions auch einen Mehrwert bringen und nicht eher ein Bottleneck sind. Wichtig ist auch, dass es in Deutschland möglichst einen gemeinsamen Konsens zu Regions gibt und allgemeine Festlegungen auch deutschlandweit umgesetzt werden. Abweichungen vom Konsens führen zu Inselbildung und für den Nutzer unerwartetem Verhalten im Netz.
-Nachfolgend einige Hilfestellungen zur Definition von Regions.
+Für Regions (und damit auch Scopes) gelten folgende Einschränkungen:
+  * Länge maximum 30 bytes (UTF-8).
+  * Nur Kleinbuchstaben, # (Hash), $ (Dollar), - (Bindestrich)
+  * Regions müssen im Netz eindeutig sein.
+  * Regions und Scopes matchen nur exakt (1:1), es gibt kein "Teilmatch" anhand des Namens. Hierarchische Strukturen müssen über jeweils eigene Regions abgebildet werden.
+  * Die Anzahl der Regions auf dem Repeater ist auf 32 begrenzt, ABER: Beim Auto-Discover der Regions können nur 160 Zeichen übertragen werden. Alles Weitere wird abgeschnitten. Es ist daher sehr zu empfehlen, die Anzahl der Regions und deren Namen mit Bedacht zu wählen. Die abgeschnittenen Regions sind im Repeater trotzdem aktiv. Wenn der Nutzer diese kennt, kann er sie trotzdem nutzen. Sie werden lediglich nicht im Auto-Discover angezeigt.
+Anleitungen zur Konfiguration der Regions und Nutzung des Scopes findet ihr hier:
+  * [[cli|Repeater Konfiguration]]
+  * [[scopes-nutzen|Scopes in Companions nutzen]]
 ===== Wie schneidet man Regions am besten? =====
-Regions sollten möglichst eine Menge an Menschen zusammenfassen, die sehr wahrscheinlich miteinander kommunizieren möchten. Dabei spielen gemeinschaftliche Gesichtspunkte wie Kultur, Gesellschaft, Region und Identifikation eine zentrale Rolle. Der Berliner möchte vielleicht innerhalb seiner Stadt kommunizieren, der Franke mit anderen Franken, der Ahrensburger gerne im Großraum Hamburg und die Hessen unter sich.
+Regions sollten möglichst eine Menge an Menschen zusammenfassen, die sehr wahrscheinlich miteinander kommunizieren möchten. Dabei spielen gemeinschaftliche Gesichtspunkte wie Kultur, Gesellschaft, Region und Identifikation eine zentrale Rolle. Der Berliner möchte vielleicht innerhalb seiner Stadt kommunizieren, der gemeine Franke mit anderen Franken, der Ahrensburger gerne im Großraum Hamburg und die Hessen unter sich.
 Unter dem Fachbegriff "Raumplanung" werden in Deutschland auf Grundlage solcher Gesichtspunkte bereits Gebiete definiert, die wir für regionale Regions einfach nutzen können. Diese Gebiete sind bereits klar abgegrenzt, im allgemeinen Sprachgebrauch vorhanden und leicht verständlich. Als Grundlage für Regions könnten dienen:
@@ Zeile 22: / Zeile 34: @@
   * [[https://www.ballungsraumverbaende.de/|Regionalverbände]] (z.B. Großraum Braunschweig)
   * [[https://de.wikipedia.org/wiki/Naturr%C3%A4umliche_Gro%C3%9Fregionen_Deutschlands|Naturräume/Landschaften]] (z.B. Taunus, Harz, Lüneburger Heide)
+  * [[https://de.wikipedia.org/wiki/Liste_der_Gro%C3%9Fst%C3%A4dte_in_Deutschland|Großstädte]] (z.B. Hamburg, Berlin, Frankfurt)
   * ...
-Im Gegenzug eigen sich starre geografisch getriebene Systeme wie PLZ, Locator oder Gemeindeschlüssel (u.A.) weniger als Regions, da diese Systeme die oben genannten Gesichtspunkte gänzlich außer Acht lassen und die starren Grenzen zwischen z.B. PLZ-Gebieten Menschen eher voneinander trennt, als sie zu verbinden.
+Neben diesen theoretischen Überlegungen kann man sinvolle Regions auch aus der Praxis ableiten. Wenn es z.B. einen Channel #singles-frankfurt gibt, in dem rege Kommunikation unter Frankfurtern herrscht, könnte __frankfurt__ ein guter Kandidat für eine Region sein.
+Im Gegenzug eigen sich starre geografisch getriebene Systeme wie PLZ, Locator oder Gemeindeschlüssel (u.A.) weniger als Regions, da diese Systeme die oben genannten Gesichtspunkte gänzlich außer Acht lassen und die starren Grenzen zwischen z.B. PLZ-Gebieten Menschen eher voneinander trennen, als sie zu verbinden.
 \\
@@ Zeile 35: / Zeile 50: @@
 ===== Wie groß sollen die Regions sein? =====
-**:?: BEISPIEL:** Die lokale Community möchte in einer Großstadt Regions einführen \\
+:!: Als Merksatz gilt: **Regions so klein wie möglich, aber so groß wie nötig!** Sowohl bei der Definition der Region, als auch beim Setzen des Scopes in den Channels.
-\\
+Die Kommunikation in den Channels soll zukünftig bevorzugt immer mit einem gesetztem Scope erfolgen. Daher muss der Nutzer die Möglichkeit haben, den für die Kommunikation passenden und kleinstmöglichen Scope auch auswählen zu können. Ein Channel #singles-frankfurt sollte auch nur mit dem Scope __frankfurt__ genutzt werden, ein Channel #singles-hessen entsprechend mit dem Scope __de-he__ usw. (Das Thema Verschachtelung von Scopes wird im nächsten Abschnitt im Detail besprochen.)
+Nach oben hin gibt es keine zwingende Limitierung der Größe einer Region, allerdings belasten große Regions das Netz erheblich mit Flood-Traffic. Entsprechend dem obigen Merksatz braucht es also gute Gründe, warum man seine Nachrichten z.B. mit dem Scope __europe__ sendet. Auch wenn große Regions damit eher problematisch wirken, sind sie dennoch wichtig und sollten auf den Repeatern auch immer vorhanden sein. Dies hat zwei maßgebliche Gründe:
+  * Nachrichten OHNE Scope (64 Hops durch alle Länder) sind immer schlechter als mit großem Scope (__de__ bleibt innerhalb Deutschlands und stört die Nachbarn nicht)
+  * Der Nutzer findet immer einen passenden Scope und gewöhnt sich an die Nutzung des Scopes
+Zu kleine Regions bringen allerdings schnell Nachteile mit sich. Als kleinste Einheit empfehlen sich Regions, die durch mehrere Repeater redundant versorgt werden können, ohne dass die Reichweite der Repeater zu erheblichen Überlappungen führt. Wenn z.B. zwei Regions auf gleicher Ebene durch den selben Repeater zu 100% versorgt werden können, bringen die Regions keinen Nutzen.
+\\
 |< 100% 50% 50% >|
-^ Idee 1: Regions pro Stadtteil ^ Idee 2: Eine Region für die ganze Stadt ^
+^ Beispiel 1: Regions pro Stadtteil ^ Beispiel 2: Eine Region für die ganze Stadt ^
 | {{ :meshcore:allgemeines:regions:folie5.jpg }} | {{ :meshcore:allgemeines:regions:folie6.jpg }} |
 | **:-) VORTEILE:** \\ - Man kann sich gezielt mit den Leuten aus seinem Stadtteil unterhalten \\ - Flood Traffic wird maximal reduziert | **:-) VORTEILE:** \\ - Erheblich vereinfachte Konfiguration der Repeater \\ - Gute Abdeckung/Versorgung durch mehr Repeater in der Region \\ - Einfacher für den Nutzer, weil weniger Regions |
-| **:-( NACHTEILE:** \\ - Reichweite der Repeater hört nicht an Stadtteilgrenze auf \\ - Ggf. gibt es im Stadtteil gar keinen eigenen Repeater \\ - Jeder Repeater muss individuell auf die Stadtteile im Umfeld konfiguriert werden \\ - Nutzer hat die Qual der Wahl, welche Region er nimmt  | **:-( NACHTEILE:** \\ - Mehr Flood Pakete in der Stadt |
+| **:-( NACHTEILE:** \\ - Reichweite der Repeater hört nicht an Stadtteilgrenze auf \\ - Ggf. gibt es im Stadtteil gar keinen eigenen Repeater \\ - Jeder Repeater muss individuell auf die Stadtteile im Umfeld konfiguriert werden \\ - Die Menge der Nutzer, die innerhalb eines Stadtteils kommunizieren wollen, ist ggf. verschwindend gering \\ - Die Anzahl der Regions kann Nutzer überfordern  | **:-( NACHTEILE:** \\ - Mehr Flood Pakete in der Stadt |
-| **:!: FAZIT:** \\ Zu kleine Regions lassen sich weder einfach verwalten, noch sinnvoll nutzen. Die Nachteile überwiegen die Vorteile deutlich. Als kleinste Einheit empfehlen sich Gebiete, die durch mehrere Repeater redundant versorgt werden können, ohne dass die Reichweite der Repeater zu erheblichen Überlappungen führt. Wenn z.B. zwei Regions auf gleicher Ebene durch den selben Repeater zu 100% versorgt werden können, bringen die Regions keinen Nutzen. Ebenso sollten die Überlegungen aus Punkt 1 "Regionen schneiden" berücksichtigt werden, um eine sinnvolle Größe von Regions einzuschätzen. Zu Große Regions erzeugen wieder zu viel Traffic. Die Regions sollten grundsätzlich daher nur "so groß wie nötig" sein. Über eine Verschachtelung (siehe nächster Punkt) lassen sich Regions unterschiedlicher Größe sinnvoll kombinieren. ||
+===== Sind Regions hierarchisch? =====
+Grundsätzlich gibt es keine notwendige und festgelegte hierarchische Struktur von Regions, auch wenn die CLI eine solche Eingabe im Repeater zulässt. Da sich Regions nach ganz unterschiedlichen Gesichtspunkten definieren, kann es kleine und große Regions geben, sowie Regions die sich erheblich überlappen oder im Gegensatz starren Grenzen folgen. Es kann natürlich auch Regions geben, die auf Grund ihrer Herkunft einer Hierarchie folgen (Z.B. Bund und Bundesländer), was aber trotzdem nicht bedeutet, dass die nächste Region automatisch hierarchisch unterhalb des Bundesländer aufgehängt werden muss. Eine starre hierarchische Struktur von Regions über mehrere Ebenen hinweg (z.B. 5 Ebenen bei plz-1 bis plz-12345) bringt für Repeater-Admins und Nutzer eine erhebliche Komplexität mit, bei kaum oder gar kontraproduktivem Nutzen.
+Bei der Definition von Regions muss stets im Fokus stehen, dem Nutzer "passende" Regions für seine Kommunikation zur Verfügung zu stellen. Das bedeutet, Regions mit unterschiedlichem Schnitt und unterschiedlichen Größen. Wenn die kleinste Region (z.B. Stadt) nicht passt, kann der Nutzer so auf anders geschnittene oder größere Regions (z.B. Metropolregion, Bundesland, ...) ausweichen. Daher sollen Repeater standardmäßig auch mit den Basis-Regionen __de-bl__, __de__, __europe__ konfiguriert sein, die nach oben hin immer größer werden, damit der Nutzer nicht gezwungen ist bei nicht passender regionaler Region seine Nachricht ganz ohne Scope zu senden.
-===== Regions verschachteln und Überlappen? =====
 |< 100% 50% 50% >|
-^ Verschachteln ^ Überlappen ^
+^ Beispiel 1: Starre Struktur über X-Ebenen  ^ Beispiel 2: Anders geschnittene Regions verschachteln sich automatisch ^
-| {{ :meshcore:allgemeines:regions:folie7.jpg }} | {{ :meshcore:allgemeines:regions:folie8v2.jpg }} |
+| {{ :meshcore:allgemeines:regions:folie8b.jpg }} | {{ :meshcore:allgemeines:regions:folie7b.jpg }} |
-| Um den Flood-Traffic sinnvoll einzuschränken, sollen zukünftig im besten Fall alle Nachrichten mit Scope gesendet und die Regions so klein wie möglich gehalten werden. Möchte man in einem größeren Umkreis kommunizieren, sollten deshalb dafür auch entsprechend größere Regions existieren die der Nutzer auswählen kann. Bisheriger Konsens ist, dass die Ebenen "Deutschland" und "Bundesland" auf jedem Repeater vorhanden sein sollen. Die Ebenen darunter werden von den regionalen Communities definiert und sind weder in der Anzahl, noch der Art vorgegeben. Ebenso müssen die Ebenen nicht Hierarchisch/Strukturell voneinander abhängig sein - eine Metropolregion ist z.B. nicht automatisch einem Bundesland untergeordnet. Aus den Überlegungen auch aus den ersten Punkten lässt sich Stand heute ein gewisses Muster erkennen, welches als Vorlage für alle dienen kann: \\ - Bundesweit (de) \\ - Bundesland (z.B. de-he) \\ - Region/Landschaft (z.B. ruhrgebiet, westerwald) \\ - Großstadt/Landkreis (z.B. frankfurt, lk-esslingen) | Regionen (auf der gleichen Ebene, wie z.B. Bundesland) überlappen nicht. Jeder Ort in Deutschland gehört nur zu einem Bundesland.  |
+| **:-) VORTEILE:** \\ - Klar strukturiert, auf ganz Deutschland anwendbar \\ - Man kann die Größe des Scopes in 5 Stufen selbst wählen | **:-) VORTEILE:** \\ - Verschachtelung geschieht automatisch durch Regions mit anderem Schnitt und anderer Größe \\ - Man wird in den meisten Fällen regionale Regions finden, die genau das Gebiet umfassen, in dem man kommunizieren will \\ - Regions sind eindeutig benannt, oftmals selbsterklärend \\ - Man kommt mit einer geringeren Anzahl Regions aus, als wenn man einer starren Struktur über viele Ebenen folgt  |
+| **:-( NACHTEILE:** \\ - PLZ Gebiete sind reine Verwaltungsgebiete mit starren Grenzen \\ - Eine Kommunikation von z.B. Mainz (plz-5) nach Wiesbaden (plz-6) ist nicht möglich \\ - Unheimliche Komplexität bei der Administration der Repeater \\ - Der Nutzer hat keine Ahnung, welche Ebene für ihn ausreichend ist \\ - Es kann PLZ-Gebiete ohne eigene Repeater geben \\ - Repeater an Grenzen von PLZ-Gebieten müssen auch alle benachbarten Regions enthalten | **:-( NACHTEILE:** \\ - Man muss sich mehr Gedanken machen, wie man solche Regions sinnvoll definiert |
+===== Dürfen sich Regions überlappen? =====
+Bezüglich Überlappung von Regions gibt es zwei Möglichkeiten:
+  - Regions, die starren Grenzen folgen (z.B. Bundesland), sollten auf keinen Fall aufgeweicht werden oder überlappen. Es ist nicht sinnvoll, die Landesgrenze von Hessen um 100km nach Bayern zu verschieben, nur um dort auch den hessischen Traffic mitzubekommen. Möchte ein Nutzer über die Landesgrenze kommunizieren, muss er einen anderen (z.B. __rhein-main__) oder größeren Scope (z.B. __de__) wählen. Um an den Landesgrenzen aber trotzdem eine ausreichende Versorgung durch Repeater zu gewährleisten, ist es sinnvoll die "Grenzrepeater" mit Reichweite in beide Richtungen auch mit jeweils beiden Regions zu konfigurieren.
+  - Regions, die keinen starren Grenzen folgen, können beliebig überlappen. Hier ist allerdings zu beachten, dass Überlappungen immer zu mehr Konfigurationsaufwand bei den Repeatern führt.
+\\
+|< 100% 50% 50% >|
+^ Regions mit festen Grenzen ^ Regions die überlappen ^
+| {{ :meshcore:allgemeines:regions:folie9b.jpg }} | {{ :meshcore:allgemeines:regions:folie10b.jpg }} |
+| :-) Die Landesgrenzen zwischen DE und RP sind klar definiert und sollten nicht aufgeweicht werden. \\ ABER: "Grenzrepeater" mit Reichweite in beide Gebiete, sollten auch beide Regions konfiguriert haben. | :-) Frei definierte Regions können nach belieben überlappen. Das kann sogar von Vorteil sein, weil damit eben eine starre Zuordnung zu einer oder der anderen Region entfällt. Es muss aber deutlich ersichtlich sein, dass solche Überlappungen existieren, um diesen Vorteil sinnvoll auszunutzen. |
+===== Wie benennt man Regions am besten? =====
+Bei der Benennung von Regions muss der Fokus zu 100% auf dem Nutzer ohne MeshCore- und Community-Erfahrung liegen, damit dieser bei der Auswahl des Scopes intuitiv den Richtigen findet und auswählen kann. Wenn der Nutzer die Scopes nicht versteht, oder auf Grund eines schlecht gewählten Scopes eine schlechte Nutzererfahrung macht, wird er zukünftig vermutlich auf die Nutzung von Scopes komplett verzichten, weil "geht ja eh nicht".
+Die Diskussionen die bisher in den Communities zu Regions stattgefunden haben, tendieren eher dazu, Benennungen nach technischen Aspekten (Länge) auszuwählen, was zu mehrdeutigen oder nicht nachvollziehbaren Abkürzungen führt. In der Runde der Entscheider mögen die Namen nachvollziehbar sein, für Außenstehende vermutlich aber nicht. Dies muss vermieden werden, um bei den Nutzern eine breite Akzeptanz für Scopes herzustellen.
+Folgende Punkte sollten bei der Benennung von Regions beachtet werden:
+  * Namen möglichst sprechend wählen, mehrdeutige oder unbekannte Abkürzungen vermeiden (__westerwald__ vs. __ww__, __rhein-main-gebiet__ vs. __rmg__)
+  * Für definierte Gebiete besser den bereits etablierten Namen nutzen, als eigene Namen erfinden (__rhein-main-gebiet__ vs. __frankfurter-umland__)
+  * Keine Hierarchien einbauen, die faktisch nicht existieren (__de-rp-westerwald__ ist falsch, da der Westerwald HE, RP und NW umfasst)
+  * Da regionale Regions eine begrenzte Reichweite und im besten Fall eindeutigen Namen haben, braucht es keinen de-Präfix (__de-westerwald__ ist unnötig, __westerwald__ reicht)
+\\
+|< 100% 50% 50% >|
+^ Beispiel 1: Abgekürzt ^ Beispiel 2: Sprechend ^
+| {{ :meshcore:allgemeines:regions:folie11.jpg }} | {{ :meshcore:allgemeines:regions:folie12.jpg }} |
+| **:-) VORTEILE:** \\ - Abkürzungen sparen Platz in der begrenzten Übertragung (160 Zeichen) der Regions \\ - Abkürzungen folgen der __de__ und __de-bl__ Schematik  | **:-) VORTEILE:** \\ - Namen sind sprechend und nachvollziehbar \\ - Es gibt bei aktuellem Schnitt der Regions nach Empfehlung dieser Seite vermutlich nur eine handvoll Regions pro Repeater, die sich ohne Probleme mit 160 Zeichen übertragen lassen \\ - Keine Verwechslungsgefahr wie bei Abkürzungen \\ - Das Schema __de__ -> __de.bl__ muss nicht fortgesetzt werden, ebenso braucht es keine fixen weiteren Hierarchie-Ebenen unterhalb __de-bl__ |
+| **:-( NACHTEILE:** \\ - Für den Nutzer ist die Bedeutung der Abkürzungen kaum nachvollziehbar \\ - Bei sehr kurze Abkürzungen kann es häufiger Duplikate mit unterschiedlichen Bedeutungen geben | **:-( NACHTEILE:** \\ - Etwas längere Namen |
+===== Was sind private Regions? Was ist die Home-Region? =====
+Das wissen wir auch noch nicht genau. In der Firmware gibt es entsprechende Hinweise sowohl auf private Regions (mit $ am Anfang) und eine spezielle Home-Region, die man auch jetzt schon per CLI setzen kann. Beides wird aber weder in der App erwähnt, noch gibt es Blog-Beiträge o.Ä. zu Zweck und Nutzung. Sobald es weitere Erkenntnisse gibt, wird das Wiki ergänzt/angepasst.

MeshCore Wiki DE

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge