Open Data Berlin: Wirklich zwei WMS-Layer für ein Thema?

ALKIS Berlin: Ein Darstellungslayer vs. 5 Sachdatenlayer in einem WMS, warum?

Also eigentlich dachte ich, ich kenne mich mit OGC-konformen Geodiensten ganz gut aus. Nun bin ich aber in Berlin (IMHO ein echter Open Data Vorreiter!) auf einen im März 2026 aktualisierten ALKIS-WMS [1] gestoßen, den ich in dieser Form noch nicht erlebt habe und eigentlich so auch nicht verstehe. Warum betreibt man einen WMS anders als vom Standard vorgesehen?

Ein WMS zeichnet sich lt. Wikipedia durch folgenden Eigenschaften aus:

„Im Sinne eines verteilten Geoinformationssystems (GIS) besitzt ein WMS nur die Fähigkeit zur Auskunft der notwendigen Metainformation, zur Visualisierung dieser Geodaten und für eine allgemeine Abfrage der zugrundeliegenden Sachdaten.“ [2]

Bekanntermaßen liefert mir ein WMS eine Karte mit GetMap (ein georeferenziertes Bild als PNG, GIF, JPG, TIFF, …) und gleichzeitig auf Anfrage die Sachdaten eines Objektes über einen abgefragten Punkt (Koordinate) in diesem Dienst mit GetFeatureInfo. Des Weiteren können noch die Legende mit GetLegendGraphic und die Eigenschaften mit GetCapabilities abgefragt werden.

In Berlin macht man es nun aber plötzlich anders. Hier werden die Inhalte zur Visualisierung für die Flurstücke, Gebäude, Bauwerke, … in einem Layer gemischt und die Sachdaten getrennt in weiteren fünf Layern, immerhin alles in einem Dienst vorgehalten, einer für die gemischte Karte (GetMap) und die fünf für die Sachdaten (GetFeatureInfo). Aber warum? Das heißt ja für den Nutzer in seinem GI-System immer mindestens zwei Layer laden, einen mit der Karte ohne Sachdaten, um die Geodaten überhaupt zu sehen und den zweiten, eben mit leerer Karte, nur, um die Sachdaten via Identifikation abfragen zu können. Das bringt

  • die Nutzer durcheinander,
  • erhört den Aufwand,
  • senkt die Transparenz,
  • konterkariert IMHO die WMS-Philosophie und
  • ist doch eigentlich total unnötig, oder?

Ich hätte je einen Layer für Flurstücke, einen für Gebäude, Bauwerk, Nutzung, etc. erwartet, jeweils mit Karte und Sachdaten, so wie üblich und in allen anderen Bundesländern auch realisiert, üblicherweise getrennt nach Flurstücken, Gebäuden und tatsächlicher Nutzung. Für GIS-Insider ist das vielleicht gewöhnungsbedürftig, aber machbar, für „normale“ Endkunden ohne spezielle GIS-Kenntnisse im WebGIS wie OpenLayers, Leaflet oder MapLibre eine Zumutung.

Hier die Problematik für das Thema „Flurstücke“ mal bebildert:

Screenshot 1: Die zwei verschiedenen Layer für die gemischte „Darstellung“ und die Flurstücks-„Sachdaten“ im QGIS
Screenshot 2: Nur der Layer für „Darstellung“ leider ohne Identifikationsmöglichkeit
Screenshot 3: Nur der Flurstücks-Layer für „Sachdaten“ leider ohne Karte
Screenshot 4: Nur der Flurstücks-Layer für „Sachdaten“ identifizierbar aber leider ohne Karte
Screenshot 5: Beide Layer für gemischte „Darstellung“ und Flurstücks „Sachdaten“ und nur bei richtiger Aktivierung (blau) auch mit Identifikationsergebnis

Ich habe mich mit einigen Fachkollegen dazu ausgetauscht, keiner hatte eine Idee oder plausible Erklärung. Und was macht man heute, man befragt die KI, meinen Chat dazu findet Ihr in [3]. Aber auch dort bin ich nicht wirklich fündig geworden. Der noch plausibelste Grund für verschiedene Toleranzen sollte bei Flurstücken, Gebäuden, … eher keine Rolle spielen, diese Objekte trifft man per Mausklick im Allgemeinen immer sicher.

Vielleicht können uns die Berliner Kollegen mal auf die Sprünge helfen, warum sie das so (ungewöhnlich) gelöst haben, gern in den Kommentaren. Ich jedenfalls bin gespannt und lerne gern dazu!

Übrigens, über den für mich unverständlichen, weil unterschiedlichen Umgang mit inhaltlich gleichen Themen in den einzelnen Bundesländern habe ich in meinem Vortrag „Open Data in D: Perfekte Idee, halbherzige Umsetzung? Ein Erfahrungsbericht.“ auf der FOSSGIS 2025 in München [4], [5] das erste Mal berichtet, dann immer mal wieder.

[1] … https://gdi.berlin.de/services/wms/alkis?SERVICE=WMS&REQUEST=GetCapabilities
[2] … https://de.wikipedia.org/wiki/Web_Map_Service
[3] … https://geoobserver.de/download/KI_ALKIS_WMS_Berlin_ChatGPT52_20260428.pdf
[4] … https://www.youtube.com/watch?v=bVLV-df5O6I
[5] … https://geoobserver.4lima.de/downloads/myPresentations/FOSSGIS_2025_ OpenDataGermany_Erfahrungsbericht_Elstermann_v02.pdf

QGIS-Tipp: „Cluster Generator“ am Beispiel von Postleitzahlen

Mitunter kann man viel Zeit benötigen, um Daten zu prüfen. Eine häufig verwendete Methode ist dabei, die Objekte mit demselben Attributwert zu ermitteln und deren räumlichem Zusammenhang zu berechnen und zu visualisieren. Das kann dann u. U. wieder viel Zeit sparen. Man erstellt dazu s. g. Clusterflächen. Eine wirklich praktikable Lösung dafür liefert das neue QGIS-Plugin „Cluster Generator“ [1]

Screenshot 1: Mein Test, 34098 Punkte mit „plz“-Attribut geclustert

Ich habe das Plugin mal kurz angetestet, die Bedienung ist einfach und selbsterklärend. Genutzt habe ich dazu unseren Postleitzahlen- (PLZ-) Datenbestand. Der automatisch einmal pro Nacht generierte Datenbestand hat vfür Halle (Saale) momentan 34098 Punkte mit PLZen. Die Clusterfunktion darauf angewendet liefert recht schnell die Clusterflächen mit den PLZ-Bereichen und färbt und beschriftet diese automatisch nach dem ausgewählten Attributfeld, hier also „plz“. Das Formular und die Ergebnisse findet Ihr in Screenshot 1.

Ein wunderbarer, positiver Nebeneffekt. Man findet so auch ganz schnell, quasi nebenbei die fehlerhaften Objekte, bei meinem Test die Punkte mit dem Eintrag „plz=NULL“. Ich habe diese NULL-Flächen mal etwas hervorgehoben. Für die Punkte in diesen Flächen sind die PLZ-Attributwerte also zeitnah zu aktualisieren, von „NULL“ auf die tatsächliche PLZ oder die Punkte an sich sind zu überprüfen.

Screenshot 2: Fehlerhafte Punkte mit „plz=NULL“ in Extra-Clusterinseln

[1] … https://plugins.qgis.org/plugins/cluster_generator/
[2] … https://www.linkedin.com/posts/senolbaskaya_qgis-gis-plugin-activity-7447516085979136000-CzPq

GIS-Wissen: Mercator, immer wieder!?

Bildquellen [1]

Über Fluch und Segen der Mercartor-Projektion [1] habe ich hier [2] schon oft berichtet. In den GIS-Schulungen erlebe ich immer wieder, dass sich die Teilnehmer das Ganze aber doch recht schwer vorstellen können. Deshalb habe ich mal nach guten Visualisierungen zur Mercartor-Problematik gesucht, einige seien hier vorgestellt.

Übrigens , wer sich selbst mal ein Bild machen will, dem sei TheTrueSize.com [3] empfohlen, hier habe ich mal Russland untersucht:

Die runde Erde auf eine Fläche projezieren, wie geht das und warum wird so unterschiedlich verzerrt? [4]

Die wahre Größe der Staaten [5]

Die wahre Größe der Staaten animiert [6]

So verzerrt Mercartor Grönland, hier im Vergleich mit Afrika [7]

Grönland in verschiedenen Projektion, Mercartor verfälscht am meisten [8]

Sehenswert: „Warum alle Weltkarten falsch sind | Terra X plus“ auf Youtube [9]

[1] … https://de.wikipedia.org/wiki/Mercator-Projektion
[2] … https://geoobserver.de/?s=mercator&submit=Suchen
[3] … https://thetruesize.com/
[4] … https://x.com/vintagemapstore/status/2035573299699232939
[5] … https://x.com/brilliantmaps/status/2007270953504399413
[6] … https://x.com/geoawesome_dgtl/status/2036435866470453446
[7] … https://x.com/brilliantmaps/status/2008984742318780696
[8] … https://x.com/milan_janosov/status/2037204804536054177
[9]… https://youtu.be/NAi3v33fVww?is=y3swBQCmcDFlyFqc

DataViz: „Wahrnehmung von Farben in Choroplethenkarten im Dunkelmodus“

Bildquelle [3]

Meine Leseempfehlung zum Thema: Wirkt der „Dark Mode“ in der Kartographie anders herum oder wie werden die Farben im immer mehr genutzten Dunkelmodus wahrgenommen? Während im Hellmodus dunklere Farben mit einer größeren Wertigkeit assoziiert werden, stellt sich die folgende Frage: Ist das im Dunkelmodus genau so oder, wie vielleicht zu erwarten, genau umgekehrt? Prof. Dr. Jochen Schiewe, Präsident der DGfK [1] hat es in einer mit 214 Personen durchgeführten Online-Studie untersucht. In seinem KN-Beitrag „Dark‑is‑More Bias Also in Dark Mode? Perception of Colours in Choropleth Maps in Dark Mode“ [2], als PDF downloadbar unter [3], sind die Ergebnisse veröffentlicht, also, wie die Farben im Hell- und Dunkelmodus auf die Probanden wirken. Ich spoilere mal nicht, lest selbst 😉 es lohnt sich. Nur eins dazu:

„Die Studienergebnisse erlauben auch generelle Gestaltungsempfehlungen für künftige Dunkelmodus-Farbschemata für Karten.“ [2]

[1] … https://dgfk.net/
[2] … https://link.springer.com/article/10.1007/s42489-024-00171-z
[3] … https://link.springer.com/content/pdf/10.1007/s42489-024-00171-z.pdf

NDVI: Realisierung mit QGIS, Standard & Grenzen

NDVI (Normalized Difference Vegetation Index) [1] ist lt. Wikipedia „der am häufigsten angewandte Vegetationsindex“ und ist seit Jahren ein Standardwerkzeug bei der Beurteilung von Fernerkundungsdaten. In vielen GI-Systemen ist er einfach zu berechnen mit der vergleichbar simplen Formel:

NVDI = NIR-Kanal - Rot-Kanal / NIR-Kanal + Rot-Kanal


In QGIS kann diese Berechnung unkompliziert mit dem Rasterrechner realisiert werden. Ich habe das mit den vom LVermGeo LSA als freie DOP20-Luftbilder [2] angebotenen Daten getestet. Die Besonderheit hier: die DOP20 repräsentieren im Kanal 4 den benötigten NIR-Kanal. Folgender Screenshot zeigt die Vorgehensweise im QGIS-Rasterrechner mit den LSA-DOPs.

Screenshot 1: Umsetzung der NDVI-Berechnung im QGIS mit dem Ratserrechner

Um das Ergebnis der Berechnung, ein Graustufen-Bild, noch deutlicher zu visualisieren, kann das entstandene Raster z. B. als „Einkanalpseudofarbe“ eingefärbt werden. Die Klassen und Unterschiede im NVDI werden damit deutlich sichtbarer.

Screenshot 2: Einfärben des Graustufen-Ergebnisses als „Einkanalpseudofarbe“ im QGIS

Grenzen und Gefahren bei Fehlinterpretation:

  • vertrocknete pflanzliche Strukturen (z. B. vertrocknete Rasenfläche)
  • starker Schattenwurf
  • unterschiedliche Kamera-Sensoren
  • vergleichbare Fotos? unterschiedliche Überfliegungssituationen (anderes Überfliegungsdatum, anderer Sonnenstand, …), Normierung 0.7 vs. 0.7
Screenshot 3: Gefahr der Fehlinterpretation durch Verschattung (hier Verschattung von Dächern)
Screenshot 4: Verschattung von Dächern kann dazu führen, dass das Dach teilweise als „Grün“ interpretiert wird
Screenshot 5: Gefahr der Fehlinterpretation durch vertrocknete pflanzliche Strukturen (hier vertrocknete Rasenfläche)
Screenshot 6: Die vertrocknete Rasenfläche kann dazu führen, dass sie teilweise als „versiegelt“ interpretiert wird

Danke für den fachlichen Input und das Coaching von M. Sc. Matthias Henning von der Hochschule Anhalt. So muss Netzwerken! Hier noch ein paar wichtige Bemerkungen und Ergänzungen von Matthias bzgl. der Grenzen und Gefahren bei Fehlinterpretation:

„So gerne und häufig der NDVI auch eingesetzt wird, sollten die Grenzen der jeweiligen Methode immer berücksichtigt werden. Beim NDVI sind diese vor allem bei den Sensoren (Kamera) und den aufgenommenen Lichtspektren zu finden. Einfache Kameras nehmen den NIR-Bereich lediglich als den Bereich wahr, der auf den roten Bereich folgt. Die Intensität der Lichtaufnahme ist bei jedem Kamerasensor unterschiedlich und gleicht einer Kurve. Etwas hochwertigere Kameras steuern die auf den Sensor treffenden Wellenlängenbereiche über einzelne schmalbandigere Filter. Im Bild unten sind die Bereiche der Multispektralkamera der im Einstiegs-UAV-Bereich häufig verwendeten DJI Mavic 3 zu sehen (CC-BY-4.0, Jon Atherton). Diese ordnet die Bereiche des roten und nah-infraroten Spektrums deutlich schmaler zu als z.B. den Rotbereich einer RGB-Kamera. Im Bereich der professionellen Fernerkundung werden diese Wellenlängenbereiche noch viel detaillierter und feiner erfasst. Daher können die NDVI-Werte unterschiedlicher Kamerasysteme nicht ohne weiteres verglichen werden. Ebenso spielen der Sonnenstand, Schattenwürfe, Zentrum der Bildaufnahme, Wuchsrhytmus der Pflanzen, Feuchtigkeit, die Temperaturen und atmosphärische Verzerrungen eine Rolle. Das Licht der Sonne musste immerhin bereits viele Kilometer durch die Atmosphäre zurücklegen, bevor es reflektiert wurde und zum Sensor gelangte. Selbst der Vergleich zweier Aufnahmen desselben Sensors ist daher nicht immer einfach, zumal jedes Sensorsystem teilweise eigene Korrekturen dafür vorsieht. Entweder wird daher der NDVI in jeder Aufnahme kalibriert, indem beispielsweise auf die Werte des vitalsten Baumes normalisiert wird. Oder aber es wird nicht der NDVI, sondern dessen Klassifikation je Aufnahme in verschiedene Vitalitätsklassen, miteinander verglichen.“


Bildquelle: Atherton, J., Alonso Chorda, L., Suomalainen, J., Miettinen, I., Kuurasuo, J., & Hakala, T. (2024). DJI Mavic 3 Multispectral Edition spectral response [Data set]. Zenodo. [3]

Neben NDVI findet Ihr weitere Indizes in folgendem Tweet [4] und der Index DataBase [5].

[1] … https://de.wikipedia.org/wiki/Normalized_Difference_Vegetation_Index
[2] … https://www.lvermgeo.sachsen-anhalt.de/de/gdp-open-data.html
[5] … https://doi.org/10.5281/zenodo.11102543
[4] … https://x.com/mashfordmahute/status/2030910298459193528
[5] … https://www.indexdatabase.de/

Leseempfehlung: „The Zero-Area Paradox“

Zum Wochenende meine Leseempfehlung. Einen wunderbaren Artikel über Flächenberechnung in GI-Systemen habe ich die Tage auf LinkedIn [1] gefunden. Im Artikel „Why your GIS polygons might be lying to you: The Zero-Area Paradox“ [2] zeigt Ahmad Zaenun Faiz, wie ein GIS die Flächeninhalte ermittelt und welche Besonderheiten und Fallen es dabei gibt. Selbstüberschneidene Polygone (self-intersecting polygons) haben danach „selbstverständlich“ eine falschen Flächeninhalt. Ich habe das Ganze mal im QGIS nachgestellt, siehe die folgende Animation. Übrigens, mein QGIS-Plugin QuickPolygonRepair [3] repariert via GEOS-Methode solche Polygone ;.)

Annimation: Falschen Flächeninhalt, nämlich 0,00 m² bei einem selbstüberschneidenen Polygon

[1] … https://www.linkedin.com/posts/ahmad-zaenun-faiz_why-your-gis-polygons-might-be-lying-to-you-activity-7431910778707853313-nq6I
[2] … https://medium.com/@zaenun.faiz/why-your-gis-polygons-might-be-lying-to-you-the-zero-area-paradox-febae3e6fb04
[3] … https://geoobserver.de/qgis-plugins/#QuickPolygonRepair

Klassisches ESRI-Geoprozessing, aber mit SQL & PostGIS

Abbildung: Die alte und die neue Welt (Bildquellen [2], [3])

Seit 1991 arbeite ich mit GI-Systemen, angefangen habe ich mit ARC/INFO 4.0. Und damals, als Topologie noch eine heilige Kuh war, hatten wir leistungsstarke Funktionen für die Topologiebildung und das Geoprozessing. CLEAN & BUILD dienten der Qualitätssicherung und der korrekten Topologie, sie waren nach jeder Editiersitzung Pflicht. UNION, IDENTITY, CLIP, ERASE und Co. wurden für das Geoprozessing genutzt. Leider wurden später in der Geodatenwelt die Pflicht zur Topologie und auch diese einfachen und nützlichen Kommandozeile-Befehle aufgegeben. Ich jedenfalls hab sie mir immer mal wieder gewünscht.

Ende 2025 bin ich nun auf zwei interessante Beitragsserien gestoßen „ARC/INFO Functions in SQL – ERASE, INTERSECT, IDENTITY, UNION“ [1] und „Classic ARC/INFO Commands in PostGIS: Getting started“ [2]. Bereits 2014 beginnend und bis heute fortgeschrieben zeigt der Autor, wie mal die alten Geoprozessing-Klassiker mit heutigen SQL/PostGIS-Mitteln realisieren könnte.
Danke Artlembo [4], Cooler Stoff und … mir wird warm ums GeoHerz 😉

[1] … https://www.artlembo.com/post/arc-info-functions-in-sql-erase-intersect-identity-union
[2] … https://www.artlembo.com/post/classic-arc-info-commands-in-postgis-getting-started
[3] … ARC Command References, Commands J-Z, ESRI, Juli 1991
[4] … http://x.com/artlembo

PostgreSQL: Index-Typen

Bildquelle [1]

Befragt man eine KI zum Thema „Indizierung von Datenbanken“, bekommt man z. B. folgende Antwort:

„Datenbankindizierung beschleunigt Suchanfragen durch das Erstellen von separaten Datenstrukturen (Indizes), die wie ein Inhaltsverzeichnis funktionieren und schnellen Zugriff auf bestimmte Datensätze ermöglichen, indem sie die Notwendigkeit des sequenziellen Durchsuchens großer Tabellen reduzieren; dies erhöht die Performance bei Suchen, erfordert aber zusätzlichen Speicher und Pflege bei Schreibvorgängen (INSERT, UPDATE, DELETE).“ [hier Google-KI-Antwort vom 26.01.2026, 20:00 Uhr]

Aber wusstet Ihr, wie viele verschiedene Arten der Indizierung in einer PostgreSQL möglich sind? Mir waren in meiner Praxis bisher im Wesentlichen nur B-Tree und speziell für Geodaten der GIST unter gekommen. Aber es gibt deutlich mehr. Durch einen LinkedIn-Beitrag [1] und einen Tweet [2] von Crunchy Data bin ich angepingt worden, dort kommen sie auf 10 verschiedene Arten von Indizes, andere Quellen [3] weisen 9 Typen aus.

Hier der Original-Tweet [2]:

[1] … https://www.linkedin.com/posts/crunchy-data-solutions-inc-_key-postgres-index-terms-and-how-they-activity-7411445490501877760-Idak/
[2] … https://x.com/crunchydata/status/1983508876801531931?s=20
[3] … https://leapcell.medium.com/understanding-the-9-types-of-indexes-in-postgresql-6508f3b9fb71

GIS-Wissen: Die wichtigsten Tools/Funktionen zum Editieren

Bildquelle [1]

Einen coolen Beitrag zum Einstieg für GIS-Neulinge und als Auffrischung für gestandene GIS-Nutzer (Profis und Nerds) habe ich bei GISGeography in „25 Must-Know GIS Editing Tools“ [1] gefunden. Trace, Move, Rotate, Buffer, Scale, Reshape, Simplify, … die meisten Funktionen kennt Ihr vermutlich, aber hättet Ihr auch alle zusammen gekriegt? 😉

[1] … https://gisgeography.com/gis-editing-tools/

GPS, GNSS, Galileo, GLONASS, BeiDou, … alles klar?

Bildquelle [1]

Einen interessanten Beitrag von Rashid Jaafar zum Thema „GPS & Co“ [1] habe ich neulich auf LinkedIn gefunden und möchte ihn hier für Euch weiter leiten, direkt als Übernahme, da Nicht-LinkedIn-Nutzer ohne Anmeldung momentan dort auch nicht mitlesen können. Danke Rashid Jaafar für die Aufklärung und Zusammenfassung bzgl. der verschiedenen Systeme und Bezeichnungen. Gut, mal wieder dran erinnert zu werden 😉

📡 GPS vs. GNSS:

Warum viele den Begriff falsch verwenden und warum es in der Vermessung richtig teuer werden kann.

Im Alltag sagen die meisten einfach „GPS“.
Auf der Baustelle, im Auto, sogar in Fachgesprächen.

Aber als Vermesser weißt du:
GPS ist nur EIN System. GNSS ist die ganze Welt.

Und genau dieser Unterschied entscheidet darüber,
wie schnell dein Fix kommt –
wie stabil deine Lösung ist –
und wie präzise deine Arbeit am Ende wird.

🇺🇸 GPS (USA)

Global Positioning System
Das amerikanische System.
Der „Vater“ aller Navigationssatelliten.
Start: 1978
Für viele Jahre das Einzige, was es gab.

🇪🇺 Galileo (Europa)

Das modernste zivile System der Welt.
Extrem stabil.
Extrem präzise.
Start: 2016
Für Vermesser heute fast unverzichtbar.

🇷🇺 GLONASS (Russland)

Start: 1982
Robustes System, hilfreich bei schlechten Sichtbedingungen.
In Kombination mit GPS/Galileo sehr wertvoll.

🇨🇳 BeiDou (China)

Start: 2000 / global seit 2020
Sehr schnelle Signale, moderne Satelliten –
und in vielen Receivern längst Standard.

🔍 Der echte Unterschied?

GPS = ein System
GNSS = alle Systeme zusammen.

In der Praxis bedeutet das:

🔸 Mehr Satelliten
🔸 Weniger Signalabbrüche
🔸 Bessere Genauigkeit
🔸 Schnellere Fix-Lösung
🔸 Stabiler unter Bäumen, Brücken, Gebäuden
🔸 Verlässlicher bei Maschinensteuerung & Drohnen

Kurz gesagt:

Wer heute noch „GPS“ sagt, misst eigentlich mit GNSS.
Und wer nur GPS nutzt, verschenkt Präzision.

💬 Eure Erfahrung zählt:

Welche Genauigkeit erreicht ihr aktuell mit eurem System?

RTK? NRTK? SAPOS? VRS Now?

👇 Schreibt eure Werte in die Kommentare – ich vergleiche gern!

🔸 Teile den Beitrag, damit mehr Leute den Unterschied verstehen.

🔖 Speichere ihn für deine nächsten Projekte.

🔔 Mehr echte Insights
→ Folge mir Rashid Jaafar 🔥

#Vermessung #GNSS #GPS #Galileo #GLONASS #BeiDou #Geodäsie #Surveying #Satellitentechnik #DigitalConstruction #Engineering #Bauindustrie #Maschinensteuerung #Drohnenvermessung #Insights #RashidJaafar #USA #Europa #China #Russland“

Quelle: [1]

Noch mehr Informationen zu den genannten Navigationssatellitensystemen findet Ihr auf Wikipedia unter [2] … [6].

[1] … https://www.linkedin.com/posts/activity-7401141779930165248-Q_0u/
[2] … https://de.wikipedia.org/wiki/Global_Positioning_System
[3] … https://de.wikipedia.org/wiki/Globales_Navigationssatellitensystem
[4] … https://de.wikipedia.org/wiki/Galileo_(Satellitennavigation)
[5] … https://de.wikipedia.org/wiki/GLONASS
[6] … https://de.wikipedia.org/wiki/Beidou_(Satellitennavigation)