Sie erhalten GPS-Vermessungspunkte in WGS 84 und wollen sie auf einem Lageplan in UTM Zone 50N überlagern. Sie fügen die Koordinaten ein, und die Punkte landen mitten im Ozean — tausende Kilometer daneben. Die Zahlen sehen ähnlich genug aus, um ihnen fast zu vertrauen, aber die Koordinatensysteme sind ohne Konvertierung grundsätzlich inkompatibel. Die Konvertierung von Koordinaten zwischen EPSG-Systemen gehört zu den häufigsten GIS-Operationen, und Fehler dabei reichen von unsichtbar (wenige Meter) bis katastrophal (ein anderer Kontinent).
EPSG-Koordinatenkonvertierung transformiert Punktkoordinaten von einem Koordinatenreferenzsystem in ein anderes mithilfe mathematisch definierter Datumstransformationen und Kartenprojektionen. Im Folgenden: der Code dafür in JavaScript, Python und auf der Kommandozeile, plus die Fehler, die Ihre Daten stillschweigend verfälschen.
Was ist Koordinatenkonvertierung und wann brauchen Sie sie?
Koordinatenkonvertierung projiziert Punktdaten von einem KRS in ein anderes um. Sie brauchen sie, wenn Sie Datensätze aus verschiedenen Koordinatensystemen kombinieren, GPS-Daten auf einer Webkarte darstellen, zwischen geographischen (Grad) und projizierten (Meter) Koordinaten umrechnen oder mit Chinas versetzten Koordinatensystemen wie GCJ-02 und BD-09 arbeiten.
Zwei Operationen werden oft verwechselt. Koordinatenkonvertierung ändert die Kartenprojektion bei gleichbleibendem Datum, zum Beispiel die Umrechnung von WGS 84 geographischen Koordinaten (EPSG:4326) in WGS 84 / UTM Zone 50N (EPSG:32650). Koordinatentransformation ändert das Datum selbst. Die Umrechnung von NAD27 nach WGS 84 erfordert physikalische Modellparameter, weil die beiden Datums die Erdform unterschiedlich definieren. Die meisten GIS-Bibliotheken behandeln beides transparent, aber die Unterscheidung ist relevant, wenn Sie Präzisionsprobleme debuggen.
Die fünf Szenarien, in denen Sie einen Koordinatenkonverter brauchen:
- Datensätze aus verschiedenen KRS zusammenführen — ein Auftragnehmer liefert Vermessungsdaten in einem nationalen Gitter (z. B. OSGB 1936, EPSG:27700) und Sie müssen sie mit Ihrer WGS 84-Basislinie kombinieren.
- GPS auf Webkarte — die GPS-Rohausgabe ist WGS 84 (Grad), aber Webkarten rendern in Web Mercator (Meter). Jede kachelbasierte Karte führt diese Konvertierung im Hintergrund durch.
- Vermessungsdaten in einem kundenspezifischen KRS liefern — das CAD-System des Kunden erwartet Lambert-93 (EPSG:2154); Ihre Feldgeräte erfassen in WGS 84.
- Mit chinesischen Karten arbeiten — Amap, Tencent Maps und Baidu Maps verwenden jeweils proprietäre Offset-KRS (GCJ-02 und BD-09), die nicht mit WGS 84 austauschbar sind.
- UTM-Zonenkonvertierungen — ein Projekt erstreckt sich über zwei UTM-Zonen und Sie brauchen ein einheitliches projiziertes KRS für konsistente Entfernungs- und Flächenberechnungen.
EPSG:4326 nach EPSG:3857 konvertieren
Um von EPSG:4326 (WGS 84, Grad) nach EPSG:3857 (Web Mercator, Meter) zu konvertieren, wenden Sie die Mercator-Projektionsformel an. In JavaScript verwenden Sie proj4("EPSG:4326", "EPSG:3857", [lng, lat]). In Python verwenden Sie Transformer.from_crs("EPSG:4326", "EPSG:3857", always_xy=True). Die Konvertierung bildet Längengrad/Breitengrad auf Rechtswert/Hochwert in Metern ab.
Am Beispiel Peking:
// JavaScript — proj4js
import proj4 from "proj4";
const [easting, northing] = proj4(
"EPSG:4326",
"EPSG:3857",
[116.4074, 39.9042] // Beijing (lng, lat)
);
console.log(easting, northing);
// → 12958175.0, 4852834.1
# Python — pyproj
from pyproj import Transformer
transformer = Transformer.from_crs("EPSG:4326", "EPSG:3857", always_xy=True)
easting, northing = transformer.transform(116.4074, 39.9042)
print(easting, northing)
# → 12958175.0, 4852834.1
Die Eingabe besteht aus zwei kleinen Zahlen (Grad). Die Ausgabe sind zwei große Zahlen (Meter vom Ursprungspunkt bei 0°N, 0°E). Das ist erwartungsgemäß — Web Mercator misst die Entfernung vom Schnittpunkt des Äquators mit dem Nullmeridian.
Ein wichtiger Punkt: EPSG:3857 schneidet bei ungefähr ±85,06° Breite ab. Die Mercator-Projektion bildet die Pole ins Unendliche ab, sodass Koordinaten über 85°N oder unter 85°S nicht darstellbar sind. Für arktische und antarktische Daten brauchen Sie eine polar-stereographische Projektion wie EPSG:3413 (Nord) oder EPSG:3031 (Süd).
Sie können jede Konvertierung sofort in KunYus Koordinatenkonverter überprüfen — Koordinaten einfügen, Quell- und Ziel-KRS auswählen, fertig, ohne Installation.
Konvertierung zwischen beliebigen EPSG-Codes
Dasselbe Muster funktioniert für jedes EPSG-Paar. Für nicht eingebaute Codes brauchen Sie die KRS-Definition (einen proj4-String oder WKT). Bibliotheken wie proj4js erfordern die manuelle Registrierung benutzerdefinierter KRS-Definitionen vor der Verwendung; pyproj liefert die vollständige EPSG-Datenbank mit.
JavaScript (proj4js)
Proj4js kennt ab Werk nur EPSG:4326 und EPSG:3857. Für alles andere brauchen Sie einen Definitionsstring, den Sie auf epsg.io nachschlagen können.
import proj4 from "proj4";
// Register Lambert-93 (France) — definition from epsg.io/2154
proj4.defs(
"EPSG:2154",
"+proj=lcc +lat_1=49 +lat_2=44 +lat_0=46.5 +lon_0=3 " +
"+x_0=700000 +y_0=6600000 +ellps=GRS80 +units=m +no_defs"
);
// WGS 84 → Lambert-93
const [x, y] = proj4("EPSG:4326", "EPSG:2154", [2.3522, 48.8566]);
console.log(x, y);
// → 652469.5, 6862035.9 (Paris in Lambert-93 meters)
Ein Detail, an dem sich viele aufhängen: Der proj4-Definitionsstring muss exakt stimmen. Ich habe einmal eine Stunde lang einen 3-Meter-Versatz in einem projizierten CGCS2000-Datensatz gesucht — am Ende lag es daran, dass die .prj-Datei des Shapefiles eine leicht abweichende Ellipsoid-Parametrisierung verwendete als epsg.io. Die Lösung war, den proj4-String direkt aus dem .prj-Inhalt per gdalsrsinfo input.shp zu extrahieren, statt den EPSG-Code nachzuschlagen und davon auszugehen, dass die Definition übereinstimmt. Wenn Präzision zählt, leiten Sie die Definition immer aus den Quelldaten selbst ab.
Python (pyproj)
Pyproj liefert die vollständige PROJ-Datenbank mit, sodass Sie Definitionen nie manuell registrieren müssen. Der entscheidende Parameter ist always_xy=True — ohne ihn folgt pyproj der EPSG-Standard-Achsenreihenfolge (Breitengrad zuerst bei geographischen KRS), was Ihre Koordinaten stillschweigend vertauscht.
from pyproj import Transformer
# pyproj knows all EPSG codes — no manual registration
transformer = Transformer.from_crs("EPSG:4326", "EPSG:2154", always_xy=True)
x, y = transformer.transform(2.3522, 48.8566)
print(x, y)
# → 652469.5, 6862035.9
Kommandozeile (ogr2ogr)
Für dateibasierte Umprojektion von Shapefiles, GeoJSON oder GeoPackage ist ogr2ogr aus GDAL das Standardwerkzeug. Es verarbeitet die Batch-Konvertierung ganzer Datensätze in einem einzigen Befehl.
# Reproject a GeoJSON from WGS 84 to UTM Zone 50N
ogr2ogr -t_srs EPSG:32650 output.geojson input.geojson
# Reproject a Shapefile from OSGB 1936 to WGS 84
ogr2ogr -s_srs EPSG:27700 -t_srs EPSG:4326 output.shp input.shp
Verwenden Sie -s_srs, um das Quell-KRS explizit anzugeben, wenn die Eingabedatei keine KRS-Metadaten enthält (keine .prj-Datei oder eingebettete Projektionsinformationen). Wenn das Quell-KRS bereits in der Datei definiert ist, reicht -t_srs allein aus.
Chinesische Koordinaten konvertieren (WGS 84, GCJ-02, BD-09)
China schreibt Koordinatenversätze für alle öffentlichen Kartendienste vor. GCJ-02 ("Mars-Koordinaten") verschiebt WGS 84-Punkte um 100–700 Meter durch einen nichtlinearen Algorithmus auf Basis des Krasovsky-1940-Ellipsoids. BD-09 fügt auf GCJ-02 einen weiteren Versatz hinzu. Diese Systeme sind nicht bei EPSG registriert, und Standardwerkzeuge wie proj4 und pyproj können sie nicht konvertieren — Sie brauchen benutzerdefinierte Offset-Algorithmen.
Die Versätze existieren, weil Chinas Vermessungsvorschriften für alle öffentlich zugänglichen digitalen Karten ein verschlüsseltes Koordinatensystem vorschreiben. Die Vorwärtstransformation (WGS 84 → GCJ-02) ist eine deterministische Formel. Die Rücktransformation (GCJ-02 → WGS 84) hat keine geschlossene Lösung und erfordert iterative Annäherung — typischerweise 10 Iterationen für Sub-Meter-Genauigkeit (~0,1 m).
Welche Dienste welches System verwenden:
| Kartendienst | Koordinatensystem | Versatz zu WGS 84 |
|---|---|---|
| Google Maps (China) | GCJ-02 | 100–700 m |
| Amap (Gaode) | GCJ-02 | 100–700 m |
| Tencent Maps | GCJ-02 | 100–700 m |
| Apple Maps (China) | GCJ-02 | 100–700 m |
| Baidu Maps | BD-09 | 100–700 m + zusätzlicher Versatz |
| OpenStreetMap | WGS 84 | Keiner |
Die Konvertierungskette lautet: WGS 84 ↔ GCJ-02 ↔ BD-09. Eine direkte Konvertierung zwischen WGS 84 und BD-09 ohne den GCJ-02-Zwischenschritt liefert falsche Ergebnisse. KunYus Koordinatenkonverter implementiert die vollständige Kette mit iterativen Rückwärtsalgorithmen — etwas, das die meisten internationalen GIS-Werkzeuge nicht bieten.
Aus meiner Erfahrung ist der Versatz in Westchina am stärksten. In der Nähe von Urumqi habe ich Verschiebungen von über 600 Metern gesehen, genug, um einen POI auf die andere Seite eines Flusses oder einer Autobahn zu legen. In östlichen Küstenstädten wie Shanghai ist der Versatz kleiner (ca. 200–300 Meter), aber immer noch viel zu groß, um ihn zu ignorieren. Die subtile Falle: Der Versatz variiert gleichmäßig über das Land, sodass man ihn nicht durch Stichproben an einem einzelnen Ort entdeckt — eine Konvertierung, die in Peking "richtig aussieht", kann in Chengdu merklich daneben liegen.
Koordinatenumrechner
Konvertieren Sie Koordinaten zwischen EPSG-Systemen mit Stapelverarbeitung und intelligenter Erkennung.
Try it nowFünf häufige Fehler bei der Koordinatenkonvertierung
Die häufigsten Fehler bei der Koordinatenkonvertierung sind: falsches Quell-KRS, verwechselte Achsenreihenfolge, Web Mercator für Messungen verwenden, fehlende Datumstransformationen und die Annahme, dass alle Gradkoordinaten WGS 84 sind. Jeder dieser Fehler erzeugt subtil falsche Ergebnisse, die erst auffallen, wenn sie nachgelagert echte Probleme verursachen.
Falsches Quell-KRS
Wenn Ihre Quelldaten NAD83 (EPSG:4269) sind, Sie dem Konverter aber WGS 84 (EPSG:4326) angeben, beträgt die Differenz in den meisten Teilen Nordamerikas nur ~1–2 Meter — leicht zu übersehen beim Testen, aber signifikant für vermessungstechnisch präzise Arbeiten. Die Verwechslung von NAD27 mit WGS 84 ist gravierender: Versätze von 10–200 Metern je nach Standort, genug, um ein Gebäude auf die falsche Seite einer Grundstücksgrenze zu setzen.
Achsenreihenfolge (lat/lon vs. lon/lat)
Die formale EPSG:4326-Definition gibt Breitengrad zuerst an (lat, lng). Aber GeoJSON, proj4js, Leaflets L.latlng()-Konstruktor (trotz des Namens) und die meisten Web-Mapping-Bibliotheken erwarten Längengrad zuerst (lng, lat). Wenn Ihre konvertierten Punkte zufällig über die Karte verstreut sind, aber ungefähr den richtigen Maßstab haben, haben Sie wahrscheinlich lat und lon vertauscht. Der Parameter always_xy=True in pyproj existiert genau für diesen Fall.
Web Mercator für Messungen verwenden
EPSG:3857 ist für die Darstellung gedacht, nicht für Berechnungen. Flächenberechnung in Web Mercator liefert bei höheren Breitengraden aufgeblähte Ergebnisse — Grönland erscheint 14× größer als es tatsächlich ist. Für Entfernungs- und Flächenberechnungen konvertieren Sie zuerst in ein lokales projiziertes KRS (eine UTM-Zone oder ein nationales Gitter) und messen dann.
Fehlende Datumstransformationen
Die Konvertierung zwischen KRS, die verschiedene Datums verwenden — zum Beispiel ED50 nach ETRS89 in Europa — erfordert eine Datumstransformation mit spezifischen Parametern. Eine generische oder Standard-Transformation kann Fehler von mehreren Metern einführen. GDAL und pyproj handhaben das automatisch, wenn Gitterverschiebungsdateien verfügbar sind, aber Sie sollten die verwendete Transformationsmethode überprüfen.
Annahme, dass alle Gradkoordinaten WGS 84 sind
Viele geographische KRS verwenden Grad: EPSG:4326 (WGS 84), EPSG:4269 (NAD83), EPSG:4490 (CGCS2000), EPSG:4612 (JGD2000). Ein Punkt bei 139.6917, 35.6895 könnte jedes dieser Systeme sein — das Format sieht identisch aus, aber die Datums sind verschieden. Prüfen Sie immer die Quell-Metadaten, bevor Sie konvertieren.
Das passende Werkzeug für die Koordinatenkonvertierung wählen
Für einzelne oder kleine Batch-Konvertierungen sind browserbasierte Werkzeuge am schnellsten — keine Installation, kein Code. Für Datei-Umprojektion verwenden Sie ogr2ogr oder QGIS. Für programmatische Pipelines integrieren sich proj4js (JavaScript) oder pyproj (Python) direkt in Ihren Code. Für chinesische KRS versagen die meisten internationalen Werkzeuge.
| Szenario | Bestes Werkzeug | Warum |
|---|---|---|
| Schnelle Einzelpunkt-Prüfung | KunYu Koordinatenkonverter | Browserbasiert, 6000+ EPSG, chinesische KRS inklusive |
| Datei-Umprojektion (SHP/GeoJSON) | ogr2ogr (GDAL) | Jedes Format, Batch-Verarbeitung, skriptfähig |
| QGIS-Projekt | Layer umprojizieren | GUI-Workflow, behält Attribute und Styling |
| JavaScript-Webanwendung | proj4js | Client-seitig, ~100 KB, kein Server nötig |
| Python-Datenpipeline | pyproj | Vollständige PROJ-Datenbank, NumPy-kompatibel |
| Chinesische KRS (GCJ-02/BD-09) | KunYu Koordinatenkonverter | Eingebaute Offset-Algorithmen, die den meisten Werkzeugen fehlen |
Persönlich greife ich bei allem Wiederholbaren zu ogr2ogr. Einmal musste ich 200+ GeoJSON-Dateien aus einem kommunalen Datensatz (alle in einer lokalen Lambert-Projektion) für eine Webanwendung nach WGS 84 umprojizieren. In QGIS wären das 200 manuelle "Exportieren → Speichern unter → KRS festlegen"-Klicks gewesen. Mit ogr2ogr war es eine einzeilige Shell-Schleife: for f in *.geojson; do ogr2ogr -t_srs EPSG:4326 out/"$f" "$f"; done — erledigt in unter einer Minute. QGIS ist besser, wenn Sie die Umprojektion visuell verifizieren müssen oder wenn das Quell-KRS nicht in der Datei eingebettet ist und Sie interaktiv verschiedene Optionen ausprobieren wollen.
FAQ
Wie konvertiere ich EPSG:4326 nach UTM?
Bestimmen Sie zunächst, in welche UTM-Zone Ihre Koordinaten fallen: zone = floor((longitude + 180) / 6) + 1. Konvertieren Sie dann mit dem entsprechenden EPSG-Code — EPSG:326xx für die Nordhalbkugel, EPSG:327xx für die Südhalbkugel, wobei xx die Zonennummer ist. Beispiel: Peking bei 116,4°E liegt in UTM Zone 50N, also EPSG:32650.
Was ist der Unterschied zwischen Koordinatenkonvertierung und Koordinatentransformation?
Koordinatenkonvertierung ändert die Kartenprojektion bei gleichbleibendem Datum (z. B. WGS 84 geographisch nach WGS 84 / UTM). Koordinatentransformation ändert das Datum selbst (z. B. NAD27 nach WGS 84), was physikalische Modellparameter erfordert. GIS-Werkzeuge wie pyproj und GDAL behandeln beides transparent — die Unterscheidung wird hauptsächlich beim Debuggen von Präzisionsproblemen relevant.
Warum sind meine konvertierten Koordinaten um Hunderte von Metern versetzt?
Die häufigste Ursache ist ein falsches Quell-KRS. In China erzeugt die Verwechslung von WGS 84 mit GCJ-02 Versätze von 100–700 Metern — das ist beabsichtigt, kein Bug. Außerhalb Chinas führt die Verwechslung von NAD27 mit WGS 84 oder die Verwendung falscher Datumstransformationsparameter zu ähnlichen Fehlern. Überprüfen Sie immer Ihr Quell-KRS, bevor Sie konvertieren.
Kann ich Koordinaten in Massen ohne Programmierung konvertieren?
Ja. KunYus Koordinatenkonverter akzeptiert mehrere Koordinaten (eine pro Zeile) zur Batch-Konvertierung direkt im Browser — keine Registrierung nötig, und Ihre Daten verlassen nie Ihr Gerät. Für dateibasierte Massenkonvertierung von Shapefiles oder GeoJSON verwenden Sie das Format-Konverter-Werkzeug oder ogr2ogr auf der Kommandozeile.
Ist proj4js dasselbe wie PROJ?
Nein. PROJ ist eine C/C++-Koordinatentransformationsbibliothek, die von der OSGeo-Community gepflegt wird, mit einer Datenbank von über 10.000 KRS-Definitionen und Unterstützung für gitterbasierte Datumstransformationen. Proj4js ist ein JavaScript-Port, der dieselben Kernalgorithmen implementiert, aber standardmäßig nur EPSG:4326 und EPSG:3857 enthält — alle anderen KRS-Definitionen müssen manuell registriert werden.
Was Sie sich merken sollten
Das Muster ist immer dasselbe: Quell-KRS identifizieren, Ziel-KRS identifizieren, Konvertierung durchführen. Für schnelle Checks verwenden Sie einen Online-Konverter. Für Umprojektion ganzer Dateien greifen Sie zu ogr2ogr. Für Anwendungscode binden Sie proj4js oder pyproj ein. Und wenn Sie nicht sicher sind, welchen EPSG-Code Sie brauchen, starten Sie mit EPSG-Codes erklärt oder suchen Sie direkt mit dem EPSG-Suchwerkzeug.