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.
73 lines
4.8 KiB
Markdown
73 lines
4.8 KiB
Markdown
# 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:
|
||
|
||
```bash
|
||
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](../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).
|