---
title: CRS-Konventionen
summary: Welche Coordinate Reference Systems Lodapi nutzt — intern und über die API.
---# CRS-Konventionen

Lodapi nutzt drei CRS-Klassen, je nach Schicht:

## 1. API-Ausgabe — WGS84 (EPSG:4326)

Alle Geo-Antworten der API sind in **WGS84-Längengrad/Breitengrad** (`EPSG:4326`, GeoJSON-Default). Reihenfolge: `[lon, lat]` (RFC 7946).

| Endpoint | Output-CRS |
|---|---|
| `/v1/buildings*` | WGS84 (GeoJSON) |
| `/v1/tilesets` `bounding_volume` | WGS84 (GeoJSON-Polygon) |
| `/v1/terrain/elevation` | Input WGS84, Output ohne Geometrie |
| `/v1/terrain/profile` | WGS84 (GeoJSON FeatureCollection) |

## 2. 3D-Tiles + Mesh-Tilesets — ECEF

3D-Tiles 1.1 verwendet **Earth-Centered Earth-Fixed (ECEF)**-Koordinaten (geozentrisches kartesisches System). Cesium, three.js (`3d-tiles-renderer`) und Blender-Addon transformieren das automatisch zur Anzeige.

| Asset | CRS |
|---|---|
| `tileset.json` (Buildings) | ECEF |
| Terrain-Mesh `tileset.json` | ECEF |
| b3dm-Files (in beiden) | ECEF |

## 3. GLB-Export — ENU-Lokal

`/v1/buildings/3d.glb` liefert **East-North-Up (ENU)**-Koordinaten relativ zum Bbox-Center. Origin-Metadaten kommen in den Response-Headern (`X-Lodapi-Anchor-Srid`, `X-Lodapi-Origin-EN`).

```
X-Lodapi-Anchor-Srid: 25832
X-Lodapi-Origin-EN: 478234.567,5556789.123
```

## 4. DB-intern — UTM32N / UTM33N

Pro BL natives UTM (siehe [bundeslaender.md](./bundeslaender.md)). Die API transformiert dynamisch zu WGS84.

| CRS | Verwendung |
|---|---|
| `EPSG:25832` (UTM32N + ETRS89) | Westliche BL — BW, BY, HB, HH, HE, NI, NW, RP, SL, SH |
| `EPSG:25833` (UTM33N + ETRS89) | Östliche BL — BE, BB, MV, SN, ST, TH |

## 5. Vertikales Datum

Terrain-Höhen sind **DHHN2016** (Höhen über NHN). Lodapi gibt das explizit in jeder Höhen-Antwort als `datum`-Feld zurück.

Building-Z-Werte (LoD2) sind ebenfalls DHHN2016, kommen aus dem CityGML-Original ohne Transformation.

## Pitfalls

### Bbox-Reihenfolge

Lodapi-API erwartet `bbox=minLon,minLat,maxLon,maxLat` (West-Süd-Ost-Nord) — die **OGC-Standard-Reihenfolge** (BBOX in WGS84 Lon/Lat-Order). Das ist die gleiche Reihenfolge wie GeoJSON-Bbox-Feld.

Verwechsle das nicht mit:
- WMS GetMap mit `SRS=EPSG:4326` (Lat,Lon-Order).
- ISO-19107 Bbox (Lat,Lon).

### Mixed-CRS-Federation an BL-Grenzen

Föderierte bbox-Queries (`/v1/buildings`) sammeln Geometrie aus **mehreren UTM-Zonen** auf einmal und transformieren alles zu WGS84. An den BL-Grenzen (z.B. Frankfurt/Oder zwischen BE/BB und benachbart) kann das zu sub-mm-Sprüngen führen — Lodapi mappt das **nicht** glatt. Für sub-mm-genaue Analysen das BL der Geometrie respektieren und im nativen UTM rechnen.

### Cesium-Building-Clamping

Bei Mesh-Tilesets als 3D-Tilesets (nicht als Terrain-Provider) gibt es **kein automatisches Clamping** von Building-Geometrie. Lodapi-LoD2-Buildings haben absolute DHHN2016-Z aus dem CityGML — beide Layer liegen ohne Provider-Magic richtig übereinander.

## Bezug

- [ADR-0002 — CRS-Strategie](../../adr/0002-crs-strategy.md) — vollständige Begründung.
- [Datenmodell](./data-model.md) — DB-Indexierung pro CRS.