Ortsstruktur

Die Ortsstruktur ist ein integraler Bestandteil der PORTAL-Struktur. Orte gliedern den Inhalt auf dem PORTAL nach lokalen Aspekten und stärken so die Local Authority des PORTALs gegenüber Google. Alle Module des PORTALs greifen auf die gleiche Ortsstruktur zu.

Funktionalitäten der Ortsstruktur

Gliederung von PORTAL-Inhalten nach lokalen Aspekten
Stärkung der Local Authority des PORTALs
Einheitliche Ortsstruktur für alle Module des PORTALS

Inhaltsverzeichnis

1 Allgemeine Beschreibung
- 1.1 Datenstruktur (JSON)
- 1.2 Short-Name
- 1.3 Alias für Orte
- 1.4 Doppelte PLZs
2 Anleitung zum Set-up
- 2.1 Möglichkeiten der Ortsstruktur
- 2.2 Best Practices
  - 2.2.1 Ortsstrukturen mit 2 Levels
  - 2.2.2 Ortsstrukturen mit nur einem Level
- 2.3 Anlieferung der Ortsstruktur als CSV
3 Verwandte Seiten

Allgemeine Beschreibung

Die Ortsstruktur ist als Baumstruktur angelegt. Das bedeutet, dass neben den globalen, allumfassenden Ortsebenen (Level 0) auch Orte (Level 1) existieren, welche Unterorte (Level 2) beinhalten können. Jedem Ort sollte dabei mindestens eine PLZ zugeordnet sein. Seiten und Teaser reagieren in der Regel so, dass sie auf Level 1 die Inhalte des zugeordneten Levels 2 inkludieren.

Die Einrichtung der Ortsstruktur erfolgt beim Set-up.

Datenstruktur (JSON)

[
  {
    "name": "Test Location Root",
    "name_norm": "test-location-root",
    "short_name": "T-1",
    "lat": 12.345,
    "lng": 56.789,
    "zipcodes": [
      {
        "zipcode": "01234",
        "lat": 56.789,
        "lng": 12.345
      }
    ],
    "children": [{
      "name": "Test Location Child",
      "name_norm": "test-location-child",
      "short_name": "RTAG",
      "zipcodes": [
        {
          "zipcode": "56789",
          "lat": 11.11,
          "lng": 22.22
        }
      ],
      "children": []
    }]
  }
]

Daten	Beschreibung

Daten	Beschreibung
name	Der angezeigte Name des Ortes.
name_norm	Die Darstellung des Ortes in der URL. Dieser Wert muss im ganzen Dokument eindeutig sein.
short_name	(Optional) Wird in den Teasern angezeigt, falls die Ortsstruktur-Anzeige eingeschalten ist.
lat	Breitengrad des Ortes in Dezimalschreibweise.
lng	Längengrad des Ortes in Dezimalschreibweise.
zipcode	Postleitzahl(en) des Ortes.
children	Eine Liste der Unterorte. Diese werden anhand der gleichen JSON Objekt-Struktur definiert.

Eine Anlieferung der Ortsstruktur im obigen JSON-Format bietet im Vergleich zu Anlieferung als CSV mehr Definitionsmöglichkeiten. Allerdings kann die Anlieferung der Ortsstruktur beim Set-up auch im CSV-Format erfolgen. In diesem Fall werden die Angaben beim Import validiert und notwendige Angaben über Automatismen durch PEIQ ermittelt.

Short-Name

Pro Ort kann ein Short-Name definiert werden. Dabei handelt es sich in der Regel um Abkürzungen des Ortes. Diese Abkürzungen werden dann in der Meta-Zeile auf den Teasern angezeigt, sofern diese Option aktiviert wurde. Dadurch wird die gesamte Ortsstruktur auf der Teaser-Card angezeigt.

^{Standard-Teaser für Beiträge: DE-BY als Short-Name für die Bundeslandebene “Bayern”}

Alias für Orte

Für einen Ort können in der Datenbank mehrere Aliase durch PEIQ angelegt werden.

Das Anlegen von Aliasen wird u. a. im Rahmen einer Ortskonsolidierung oder für die Umbenennung eines Ortes genutzt, um die URLs mit der alten Ortsbezeichnung entsprechend weiterzuleiten.

Die Weiterleitung erfolgt über ein https://peiq.atlassian.net/wiki/spaces/PUPKB/pages/278331621.

In der Datenbank können mehrere beliebige Aliase für einen Ort angelegt werden. (Diese müssen händisch in der DB angelegt werden).

Beispiel: Location Augsburg

name_norm: augsburg
alias1: augx
alias2: augsb
…

In der URL zum Ort kann nicht nur ‘augsburg’ stehen, sondern auch ‘augx’ oder ‘augsb’. Wird in der URL ein Alias verwendet, dann wird auf dieselbe URL mit name_norm weitergeleitet.

Beispiel:

Es wird nach “http://www.domain.de/augx” oder “http://www.domain.de/augsb” gesucht
Die URL “http://www.domain.de/augsburg” wird aufgerufen

Sobald ein Alias angelegt wird, der denselben Namen wie ein name_norm einer anderen Location hat, funktioniert der Alias nicht mehr.
Der name_norm hat immer Vorrang!

Es wird für den Ort Augsburg der Alias “ingolstadt” gesetzt.
Dabei wird bei der Eingabe von “http://www.domain.de/ingolstadt” nicht auf “http://www.domain.de/augsburg”, sondern auf “http://www.domain.de/ingolstadt” (lokalisiert in Ingolstadt) weitergeleitet. Das bedeutet, der Alias “ingolstadt” für Location Augsburg hat hier keine Auswirkung.

Doppelte PLZs

Prinzipiell ist es zwar möglich, eine PLZ mehreren Levels zuzuordnen (vgl. https://peiq.atlassian.net/wiki/spaces/CORE/pages/45385642/Ortsstruktur#M%C3%B6glichkeiten-der-Ortsstruktur.1). Die Empfehlung lautet allerdings, dass eine PLZ nur einem Ort (Level 1) oder Unterort (Level 2) zugeordnet werden sollte.

Anleitung zum Set-up

Möglichkeiten der Ortsstruktur

Die Ortsstruktur ist als Baumstruktur gedacht, das bedeutet, neben der globalen, allumfassenden Ortsebenen (Level 0) existieren Orte (Level 1), welche optional Unterorte (Level 2) beinhalten können. Es wird empfohlen, dass jedem Ort mindestens eine PLZ zugeordnet wird. Es ist allerdings auch möglich, PORTALe mit nur einem Level zu betreiben.

Bei der Definition der Ortsstruktur ist Folgendes zu beachten:

Orte (Level 1) gruppieren die Unterorte (Level 2), Global enthält alle Orte und Unterorte.
Jeder Unterort (Level 2) kann nur einem Ort (Level 1) zugeordnet werden.
Orte (Level 1) müssen nicht zwangsläufig einen Unterort (Level 2) enthalten. Das kann z. B. verwendet werden, um z. B. eine Deutschland-und-die-Welt-Ebene nebenstehend anzubieten.
Jeder Ort (Level 1) und Unterort (Level 2) kann eine oder mehrere PLZ enthalten. Die Angabe von PLZ sind optional, jedoch empfohlen.
Empfehlung: Eine PLZ sollte nur einem Ort (Level 1) oder Unterort (Level 2) zugeordnet werden.
Empfehlung: Es sollten nur Orte oder Unterorte verwendet werden, welche in Google Maps gefunden werden.

Best Practices

Bislang wurden zwei grundsätzliche Varianten umgesetzt:

Das PORTAL wird mit der “natürlichen” Ortsstruktur aufgesetzt und bildet damit die tatsächlichen Bundesländer, Gemeinden, Orte etc. ab (z. B. http://www.meinbezirk.at, ).
Oder: Das PORTAL bildet die Vertriebsstruktur des Verlages ab (z. B. ).

Ortsstrukturen mit 2 Levels

Global	Ort (Level 1)	Unterort (Level 2)
Land (& die Welt)	Bundesland	Landkreis / Bezirk
Land (& die Welt)	Bundesland	Region
Land (& die Welt)	Bundesland	Stadt / Kommune
Bundesland (& die Welt)	Region	Stadt / Kommune
Region (& Bundesland)	Landkreis	Stadt / Kommune
Verlagsgebiet	Ausgabe	Stadt / Kommune

Ortsstrukturen mit nur einem Level

Global	Ort (Level 1)	Unterort (Level 2)
Region (& Bundesland)	Landkreis	-
Region (& Bundesland)	Ort / Kommune	-
Landkreis	Ort / Kommune	-
Stadt / Kommune	Bezirk / Teilort	-
Verlagsgebiet	Ausgabe	-

Anlieferung der Ortsstruktur als CSV

PLZ;Level 1;Level 2

Die Anlieferung als CSV-Format kann als einfache Alternative zum JSON-Format (vgl. ) benutzt werden. Die Struktur ist dabei fix vorgegeben:

Es müssen 3 CSV-Spalten vorhanden sein, wobei die erste Spalte die PLZ enthält und die nächsten beiden Spalten dann die Namen der Ebenen (zuerst der Ort (Level 1), dann der Unterort (Level 2)).
Gibt es einen der Werte nicht (also z. B. keine PLZ), dann muss die Spalte trotzdem vorhanden sein, kann aber leer gelassen werden.
Gibt es keine Unterorte (Level 2), dann muss der Ort selbst (Level 1) in diese letzte Spalte eingetragen werden und das vorherige Feld muss leer bleiben.

Eine Mustertabelle, von welcher das CSV abgeleitet werden kann, würde entsprechend so aussehen:

PLZ	Ort (Klarname)	Unterort (Klarname)