zwitschi
2f87002711
Drop the OpenStreetMap/ODbL attribution requirement, the Google imagery rule, and the related F-4 requirement, risk R-4, release check, and TODO items across AGENTS, PLAN, ROADMAP, README, setup, architecture sections, and manifests. OSM data is now documented as local private use only. Also normalize numbered-list indentation in the architecture docs.
4.8 KiB
Local origin and projected CRS
Defined 2026-11-06. This is the single place where geographic coordinates become local metres, and where local metres become Unreal units. Every asset, blockout, and manifest refers to it; nothing else may define its own origin.
Projected CRS
EPSG:26911 — NAD83 / UTM zone 11N, metres, grid north.
NAD83 rather than WGS84 is deliberate: it is the CRS the US national elevation and parcel data are published in, and the difference against WGS84 at this latitude (roughly 1 m, varying) is far below what a walkable demo can show. The choice is recorded here so nobody has to re-derive it, and so an elevation source can be brought in without a second reprojection.
Origin
| Field | Value |
|---|---|
| Definition | Hollywood Blvd × North Highland Avenue intersection node, on the boulevard centreline |
| WGS84 | lat 34.101545, lon −118.338718 |
| OSM node | the single shared node between the Hollywood Boulevard and North Highland Avenue ways in Geo/raw/osm-api-map-2026-11-06.osm |
| EPSG:26911 easting / northing | E 376 515.389 / N 3 774 224.083 (NAD83, UTM 11N, metres) |
| Rationale | a real, data-defined, reproducible point at the demo block's east boundary; no surveyed control point exists for this project |
The origin is not "the hero building" on purpose: a building may later move a metre or two as verification corrects it, while an intersection node is fixed by the source data.
How the pair was computed
Computed 2026-11-06 with PROJ Rel. 9.9.0 (2026-09-15), taken from the QGIS 4.2.3 Flatpak, because neither pyproj nor the PROJ command line is installed on the host:
P=$(ls -d ~/.local/share/flatpak/app/org.qgis.qgis/x86_64/stable/*/files | head -1)
printf -- '-118.338718 34.101545\n' | LD_LIBRARY_PATH="$P/lib" "$P/bin/proj" \
+proj=utm +zone=11 +datum=NAD83 -f '%.3f'
# 376515.389 3774224.083
Reproduce it the same way, or with pyproj once a geo environment exists. If a future PROJ reports a different pair, the new value wins and this table is updated with the PROJ version that produced it.
Projected control points
Optional check values, all NAD83 / UTM 11N, and the same points as local X/Y relative to the origin. Use them to confirm a transformation before trusting a blockout.
| Point | WGS84 lat, lon | Easting | Northing | Local X | Local Y |
|---|---|---|---|---|---|
| Hollywood × Orange Dr | 34.101543, −118.341749 | 376 235.784 | 3 774 227.529 | −279.605 | +3.446 |
| Origin: Hollywood × Highland | 34.101545, −118.338718 | 376 515.389 | 3 774 224.083 | 0.000 | 0.000 |
| Hero NW corner | 34.101412, −118.340299 | 376 369.380 | 3 774 211.202 | −146.009 | −12.881 |
| Hero NE corner | 34.101412, −118.340019 | 376 395.144 | 3 774 210.864 | −120.245 | −13.219 |
| Hero SW corner | 34.100919, −118.340299 | 376 368.662 | 3 774 156.533 | −146.727 | −67.550 |
| Hero SE corner | 34.100919, −118.340019 | 376 394.427 | 3 774 156.195 | −120.962 | −67.888 |
| Mid-block crossing | 34.101552, −118.340338 | 376 365.958 | 3 774 226.819 | −149.431 | +2.736 |
Cross-check: the hero's projected corners differ by 25.76 m east–west and 54.67 m north–south, matching the 25.7 × 54.9 m footprint measured in ../verification/2026-11-06-el-capitan-block.md. The two methods agree, so the transformation and the origin are consistent.
Note the sign pattern: the whole block lies at negative X and the hero at negative Y, which is expected with the origin at the block's east boundary.
Axis convention
| Axis | Meaning |
|---|---|
| Local X | easting − origin easting, metres, east positive |
| Local Y | northing − origin northing, metres, north positive |
| Local Z | up, metres, elevation relative to the origin's ground height |
The block then spans roughly X −279 m to 0 m, Y a few tens of metres either side, which keeps float precision comfortable in Unreal.
Conversion to Unreal
1 metre → 100 Unreal units. The ×100 happens exactly once, in the export/import path, and is asserted by the scale test required in ROADMAP.md. Blender files are authored in metres; Unreal receives centimetres.
Unreal's own axes differ (X forward, Y right, Z up). If a level rotates the imported block so that "north" is not +X, that rotation is recorded once, in the level's documentation, and never baked into the export.
Obligations
- Elevation data, when chosen, must be reprojected into EPSG:26911 with the origin above, and its vertical datum recorded (NAVD88 is the expected one for US sources; ellipsoidal heights are not interchangeable).