1Project

To be written.

1.1 How the parts fit

Where each part of the website comes from: the public sources on the left, what is made from them in the middle, and the page that shows it on the right.

2Site model

2.1 LiDAR point cloud

LiDAR is a laser scan made from an aircraft: the scanner sends laser pulses down as it flies over the city, and every pulse that comes back is one point, placed where the laser hit. The US Geological Survey flew Los Angeles in 2023 and publishes the points. Looking down, the scan sees roofs, the ground and tree crowns well and walls badly: glass reflects the laser away, so towers have many points on their roofs and few on their sides (2.4).

What every point carries in the website's file: its position (1 cm), how strongly it reflected the laser (intensity) and the class USGS gave it (ground, building, vegetation, water and so on), and three things added by us: the segment we labelled it (2.2), the object it belongs to (one building part, one tree, one car) and its height above the ground. The colours, the building tags and the people's buildings all come from these.

Loading…

2.2 Labelling the points

Every point carries two labels: a segment (ground, low, building, tree, shrub, vehicle, wall, street furniture, podium tree, porous facade, unsure) and the object it belongs to: one building part, one tree, one car. The nine USGS tiles are cut into 500 m chunks, each with a 50 m margin for the points around it, and labelled one at a time in Houdini. (site-model/houdini/tools/split_chunks.py)

Buildings and trees are told apart by a random forest trained on the shape of the points around each return. Its training labels come only from where a point is (inside a LARIAC building outline, or by a tree far from any outline), never from the shapes it learns, so it can judge the points in between; it is tested on 50 m blocks it did not see. (site-model/houdini/tools/train_seg_forest.py)

Building points are grouped by the LARIAC 2020 outlines (BLD_ objects) or, where no outline exists, as structures found in the LiDAR alone (PC_). Trees are first split at every local top and then joined again where the canopy hardly dips between two tops; leftover points join the building or tree they touch. Cars are checked last: low objects are scored against the cars already found, and every candidate is looked at before it is relabelled. (site-model/houdini/tools/refine_objects.py, car_sweep.py)

2.3 Buildings

Loading…

2.4 Estimated facades

Airborne LiDAR sees roofs well and walls badly: glass curtain walls reflect the laser away and the near-vertical view grazes the walls. Points are added on the walls of each building's volume (its outline at every 3 m of height, 2.3), only where no measured return is near, mostly on the storey lines read from the building's own wall returns, and not in the lowest metres above the ground (arcades, entrances and plazas stay open). They thin with distance like the measured cloud. They are estimates, not measurements; the viewer draws them with the measured points of their building, and leaves them out where a structure is drawn as ground (2.6: a deck has no walls). (site-model/houdini/tools/synth_facades.py)

2.5 Terrain

The ground is Houdini's ground model of the LiDAR: every point keeps its height above it. For the analysis layers it is written as a 2 m grid over 2.5 by 2.5 km around Y-1 (1,250 by 1,250 cells), each cell the mean ground height of the returns in it, under buildings too; 0.2% of the cells had no returns and take the nearest measured cell. Heights are NAVD88: the street at Y-1 is about 90 m. In the viewer the ground is the Terrain points, thinned by place as 2.1 says, with the ground under the buildings estimated. (site-model/houdini/tools/export_handoff.py → handoff/terrain.npy)

The ground here is not the original hill: the CRA's clearance in the 1960s took some 30 feet off the top of Bunker Hill (bh-008).

2.6 Layers in the viewer

3People: a modeled typical day

4Research

4.1 The entries

What is known about Parcel Y-1 is kept as entries, each with its sources, a status (verified, unverified, open question, our analysis) and the date it was last checked. They are read in Research, List; the rules for checking them are in RESEARCH.md: every quoted excerpt is fetched again and compared with its source, and an entry the sources do not support is marked down, not deleted.

4.2 The network

Research, Network draws the same entries in 3D, height for date. Its links come only from the entries: one entry naming another, an entry naming a person or organisation (from a list of names and their other forms, every match read), a Media comment and its subject (our grouping), and two entries citing the same source. Each link keeps the sentence or source that shows it. (docs/connections_build.py)

5Design

To be written.

6Working record

The project is made in a GitHub repository, one topic at a time: a branch, a pull request, merged by the owner; most of the work is done together with Claude (Claude Code), in conversation. The record keeps, for each person, how long they worked with Claude each day, counted from their first session about the project, the tokens that work used and what they would cost on the API, and what came of each day: the pull requests opened and merged. (docs/worklog.py, web/data/worklog.json)

6.1 Hours per day

6.2 Daily log

• Loading…

6.3 Pull requests

6.4 The rule

6.5 Tokens

7References

The data behind each part is listed with it above (2.1, 2.3, 3.3); the published figures used in the population model are cited in its assumptions (3.4).

Further references to be added.