Prototype

2026-06-26 11:23:09 -05:00
commit 2a52e0546e
19 changed files with 1406 additions and 0 deletions
@@ -0,0 +1,97 @@
+# Yard Map Agent Notes
+
+This file is a fast handoff for future coding agents working in this repo.
+
+## What this project is
+
+Static client-side yard mapping app.
+
+- Rendering: Leaflet.
+- Basemap: public OSM raster tiles.
+- Yard data: authored in JavaScript modules, converted to GeoJSON in the browser.
+- Runtime: plain ES modules, no bundler.
+
+## Current architecture
+
+Core files:
+
+- `src/lib/geometry.js`: absolute points, local offsets, feet conversion, per-anchor rotation support.
+- `src/lib/feature-types.js`: feature-kind style defaults.
+- `src/lib/yard-features.js`: typed feature classes, stable ids, groups, parent-child relationships, GeoJSON export.
+- `src/data/*.js`: yard content split by domain.
+- `src/main.js`: Leaflet map, legend, popup rendering.
+
+Top-level exported data shape from `src/data/yard.js`:
+
+- `type: "FeatureCollection"`
+- `features: [...]`
+- `groups: [...]`
+
+Each feature currently exports:
+
+- `properties.id`
+- `properties.kind`
+- `properties.label`
+- `properties.name`
+- `properties.parentId`
+- `properties.groupIds`
+- `properties.details`
+- `properties.style`
+
+## Important decisions already made
+
+1. Data is JS-authored on purpose.
+   This allows mixing exact imported geometry with expressions like `offset(anchor, east(ft(10)))`.
+
+2. Styling belongs to feature types, not individual features by default.
+   If you need a new semantic type, prefer adding a new typed feature or feature-type definition rather than hand-styling scattered instances.
+
+3. Local rotation is per anchor.
+   `offset(...)` reads `assumedNorthClockwiseDegrees` from the anchor point used as the origin. Do not reintroduce a global lot rotation unless there is a strong reason.
+
+4. Grouping and parent-child metadata are already part of the data model.
+   Future visibility controls should consume `groupIds` and `parentId` rather than inventing a second relationship system.
+
+5. The GPKG was only a seed source.
+   The app does not depend on GIS tooling at runtime.
+
+## Known data caveat
+
+`buildings.gpkg` has a CRS issue in `lot_boundary`.
+
+- The usable lot polygon was `fid = 2`.
+- It had to be treated as `EPSG:26914` during extraction.
+- Do not trust that layer's metadata blindly if you re-import from the GPKG.
+
+## What is already modeled
+
+- Porch and deck are children of the main house and also part of the `House Parts` group.
+- Medora junipers are part of the `Juniper Trees` group.
+- A test tree exists that is offset from the top-left lot corner using per-anchor rotation.
+
+## Likely next steps
+
+1. Add show/hide controls driven by `yardGeoJSON.groups` and possibly `parentId`.
+2. Decide whether toggles should be by feature kind, by group, by parent object, or a combination.
+3. If closer basemap zoom fidelity matters, migrate from raster OSM tiles to a vector tile or self-hosted basemap.
+
+## Useful validation commands
+
+Validate data export:
+
+```bash
+node -e "import('./src/data/yard.js').then(({ yardGeoJSON }) => console.log(yardGeoJSON.features.length))"
+```
+
+Run local server:
+
+```bash
+python3 -m http.server 4173
+```
+
+## Editing guidance
+
+- Preserve the typed-feature pattern.
+- Prefer adding semantic types or groups over ad hoc properties when possible.
+- Keep authored geometry readable; avoid generated noise unless the user explicitly wants bulk-import output.
+- If adding new anchors, attach rotation metadata to the anchor itself.