Merge remote-tracking branch 'origin/main'
# Conflicts: # AGENTS.md # README.md # index.html # package.json # src/data/buildings.js # src/data/grid.js # src/data/pavement.js # src/data/plants.js # src/data/yard.js # src/lib/feature-types.js # src/lib/yard-features.js # src/main.js # styles.css
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# Yard Map
|
||||
# A Plot of Plants
|
||||
|
||||
Static yard mapping site built with MapLibre, PMTiles, and plain browser modules.
|
||||
Static garden and yard mapping site built with MapLibre, PMTiles, and plain browser modules.
|
||||
|
||||
## Status
|
||||
|
||||
@@ -11,11 +11,9 @@ The project currently has:
|
||||
- Typed feature classes with centralized styling.
|
||||
- Schema-versioned yard data with a top-level feature type catalog.
|
||||
- Per-anchor local coordinate rotation for offset-based authoring.
|
||||
- Feature relationship metadata (`id`, `parentId`, `groupIds`) and a top-level group catalog for future visibility controls.
|
||||
- Feature relationship metadata (`id`, `parentId`, `groupIds`) and checkbox-tree visibility controls.
|
||||
- Example yard data mostly copied from `buildings.gpkg` and then preserved as JS modules.
|
||||
|
||||
The next likely product direction is map-layer visibility controls driven by the existing feature groups and parent-child relationships.
|
||||
|
||||
## Authoring model
|
||||
|
||||
Geometry stays in JavaScript, then gets converted to GeoJSON client-side at load time.
|
||||
@@ -34,13 +32,13 @@ The example yard is now split by concern:
|
||||
- `src/data/plants.js`
|
||||
- `src/data/irrigation.js`
|
||||
|
||||
The typed feature registry lives in `src/lib/feature-types.js`, feature classes live in `src/lib/yard-features.js`, and shared coordinate helpers live in `src/lib/geometry.js`. Feature type definitions include the label, required geometry type, known detail fields, and default map style.
|
||||
The typed feature registry lives in `src/lib/feature-types.js`, feature classes live in `src/lib/yard-features.js`, and shared coordinate helpers live in `src/lib/geometry.js`. Feature type definitions include the top-level category, label, required geometry type, known detail fields, and default map style.
|
||||
|
||||
Local `north`, `south`, `east`, and `west` offsets are rotated per anchor. In this example, `topLeftLotCorner` in `src/data/anchors.js` carries `assumedNorthClockwiseDegrees` from `src/data/settings.js`. A negative value means that anchor's local north is counterclockwise from true north, so local east drifts a bit toward true north.
|
||||
|
||||
Most example geometry was copied from `buildings.gpkg` and preserved as JS-authored coordinates. Tree records also carry custom attributes like canopy diameter, height, and lifecycle dates for popup rendering.
|
||||
|
||||
Feature relationships are exported with each GeoJSON feature as stable `id`, `parentId`, and `groupIds` properties. Each feature also exports universal `plantedDate` and `removedDate` lifecycle fields for timeline filtering. The collection exposes `schemaVersion`, `lifecycleFields`, `featureTypes`, and `groups` at the top level. Style is resolved from the feature type registry at render time rather than stored on each exported feature. The current sample marks the porch and deck as part of the house and groups the Medora junipers under `Juniper Trees`.
|
||||
Feature relationships are exported with each GeoJSON feature as stable `id`, `parentId`, and `groupIds` properties. Each feature also exports universal `plantedDate` and `removedDate` lifecycle fields for timeline filtering. The collection exposes `schemaVersion`, `lifecycleFields`, `featureCategories`, `featureTypes`, and `groups` at the top level. Categories use stable IDs such as `plants`, `structures`, `infrastructure`, and `reference`; feature types and groups refer to them with `categoryId`. Style is resolved from the feature type registry at render time rather than stored on each exported feature. The current sample marks the porch and deck as part of the house and groups the Medora junipers under `Junipers`.
|
||||
|
||||
## Project structure
|
||||
|
||||
@@ -55,7 +53,7 @@ Feature relationships are exported with each GeoJSON feature as stable `id`, `pa
|
||||
- `src/data/plants.js`: flower beds, trees, and tree groups.
|
||||
- `src/data/irrigation.js`: sprinkler features.
|
||||
- `src/data/yard.js`: top-level yard collection assembly.
|
||||
- `src/main.js`: MapLibre rendering, legend generation, and popup rendering.
|
||||
- `src/main.js`: MapLibre rendering, visibility controls, and popup rendering.
|
||||
- `tiles/mandan.pmtiles`: locally served vector basemap for the Mandan area.
|
||||
- `scripts/extract-mandan-pmtiles.sh`: reproducible Mandan tile extraction.
|
||||
- `docs/vector-tiles.md`: tile update and hosting notes.
|
||||
@@ -107,6 +105,5 @@ of 24.
|
||||
|
||||
## Future direction
|
||||
|
||||
- Add UI controls for toggling groups and possibly parent-linked feature clusters.
|
||||
- Decide whether toggles should operate on feature groups, feature kinds, parent-child trees, or all three.
|
||||
- Decide whether parent-child feature relationships should further affect the visibility hierarchy.
|
||||
- If more data import is needed from GIS sources, prefer one-time extraction into JS-authored modules rather than making the app depend on runtime GIS tooling.
|
||||
|
||||
Reference in New Issue
Block a user