Webseiten-Werkzeuge


meshcore:allgemeines:regions:definieren

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
meshcore:allgemeines:regions:definieren [05.02.2026 10:22] josch0meshcore:allgemeines:regions:definieren [05.02.2026 16:08] (aktuell) – [Dürfen sich Regions überlappen?] josch0
Zeile 54: Zeile 54:
 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.) 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 Regions, 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:+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)   * 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)
Zeile 79: Zeile 79:
 | {{ :meshcore:allgemeines:regions:folie8b.jpg }} | {{ :meshcore:allgemeines:regions:folie7b.jpg }} | | {{ :meshcore:allgemeines:regions:folie8b.jpg }} | {{ :meshcore:allgemeines:regions:folie7b.jpg }} |
 | **:-) 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  | | **:-) 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 | **:-( NACHTEILE:** \\ - Man muss sich mehr Gedanken machen, wie man solche Regions sinnvoll definiert |+| **:-( 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? ===== ===== Dürfen sich Regions überlappen? =====
Zeile 92: Zeile 92:
 ^ Regions mit festen Grenzen ^ Regions die überlappen ^ ^ Regions mit festen Grenzen ^ Regions die überlappen ^
 | {{ :meshcore:allgemeines:regions:folie9b.jpg }} | {{ :meshcore:allgemeines:regions:folie10b.jpg }} | | {{ :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. |+:-) 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? ===== ===== Wie benennt man Regions am besten? =====
Zeile 111: Zeile 111:
 ^ Beispiel 1: Abgekürzt ^ Beispiel 2: Sprechend ^ ^ Beispiel 1: Abgekürzt ^ Beispiel 2: Sprechend ^
 | {{ :meshcore:allgemeines:regions:folie11.jpg }} | {{ :meshcore:allgemeines:regions:folie12.jpg }} | | {{ :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 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__ |+| **:-) 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 | | **:-( 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 |
  
meshcore/allgemeines/regions/definieren.1770283378.txt.gz · Zuletzt geändert: von josch0