Refactor codebase to accommodate multi-hazard development

[katamartin]

We are beginning to work on incorporating new hazard data into ocr-web. Right now, we're pointing at data in a temporary ocr-explore bucket and scratch code, but we should eventually move that development into this repo.

Some feature requirements to note:

• Maintaining a docs site that reflects the production status of OCR (i.e. wildfire-only)
• Repository structure that reasonably organizes data from multiple hazards
• Easy iteration on CONUS-wide outputs (e.g., GeoParquet schema, risk score bins, etc.)
  • Perhaps without rerunning wildfire pipeline (or is this a quick + deterministic task relative to the rest?)

cc @Shane98c @norlandrhagen

[andersy005]

do we expect buildings to be the common denominator across the hazards, where the hazards meet only at the vector, joined on building id? if so, should we rely on overture's GERS id and carry it through the pipeline? my understanding is that right now a building is addressable only by its geometry. id gets dropped at the CONUS subset and again when the spatial-join table is built

ocr/ocr/input_datasets/vector/overture.py

Lines 138 to 145 in 1cf47d2

	query = f"""
	COPY (
	SELECT bbox, geometry
	FROM read_parquet('s3://{overture_bucket}/release/{version}/theme=buildings/type=building/*.parquet')
	WHERE
	bbox.xmin BETWEEN {bbox[0]} AND {bbox[2]} AND
	bbox.ymin BETWEEN {bbox[1]} AND {bbox[3]}
	) TO '{output_s3_uri}' (FORMAT 'parquet', COMPRESSION 'zstd');

ocr/ocr/input_datasets/vector/overture.py

Lines 236 to 241 in 1cf47d2

	console.log('Creating spatial indexes...')
	duckdb.sql(f"""
	CREATE TEMP TABLE buildings AS
	SELECT bbox, geometry FROM read_parquet('{buildings_s3_uri}');
	""")
	duckdb.sql('CREATE INDEX buildings_idx ON buildings USING RTREE (geometry);')

[andersy005]

• Maintaining a docs site that reflects the production status of OCR (i.e. wildfire-only)

this one is straightforward. currently, readthedocs defaults to latest (which builds from main). stable builds from the highest tag/release (production, wildfire-only). so, we just need to switch readthedocs default version to stable

[katamartin]

do we expect buildings to be the common denominator across the hazards, where the hazards meet only at the vector, joined on building id? if so, should we rely on overture's GERS id and carry it through the pipeline? my understanding is that right now a building is addressable only by its geometry. id gets dropped at the CONUS subset and again when the spatial-join table is built

I think that's right! @Shane98c reminded me that we were thinking of included GERS ids even just for wildfire, but then dropped. Maybe @norlandrhagen has a recollection of whether we hit a hiccup or just decided to drop?

[norlandrhagen]

Yup! From what I remember, we weren't using it, so dropped for pmtiles etc. space savings. Seems like an easy 1 liner to re-add.

[andersy005]

• Maintaining a docs site that reflects the production status of OCR (i.e. wildfire-only)

this one is straightforward. currently, readthedocs defaults to latest (which builds from main). stable builds from the highest tag/release (production, wildfire-only). so, we just need to switch readthedocs default version to stable

this is now live on https://open-climate-risk.readthedocs.io/