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.1234. DB-intern — UTM32N / UTM33N
Pro BL natives UTM (siehe 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 — vollständige Begründung.
- Datenmodell — DB-Indexierung pro CRS.