Garden map: draw plot/bed boxes to define places (consolidates #1 + #4) #11

New Issue

tonym · 2026-07-12T20:04:06Z

tonym commented

2026-07-12 20:04:06 +00:00

Consolidates #1 (draw boxes on a map to define garden plots) and #4 (yard/garden taxonomy isn't great). #4 depends on #1 — a good visual editor is what fixes the taxonomy — so tracking them as one piece of work.

Goal

A map/plot view of the property where you draw boxes (beds, zones, plots) to lay out the garden visually, and each box is a Location in the existing tree. Drawing a bed creates/edits a Location; plants placed in that bed show on the map. farmOS-style, homestead-scale.

How it maps to what exists

Location already models places (self-ref tree, LocationKind, unlimited depth). Plants are leaves in a Place. So the map is a spatial editor over Location, not a new domain.
New: Locations need geometry. Today Location has no coordinates. Add optional geometry (e.g. x/y/w/h for simple boxes, or GeoJSON polygon for irregular beds) — nullable, so non-garden places (Basement, Shelf B) are unaffected. LocationKind.AREA is the obvious "drawable" kind.
The #4 taxonomy fix falls out of this: a canonical garden hierarchy (Property › Yard/Area › Bed/Plot › row?) that the map makes obvious and enforceable, instead of the current flat/ad-hoc AREA soup left over after the HomeBox import.

Open questions (need Tony's decisions before building)

Boxes or polygons? Rectangles only (simpler, snap-to-grid) vs. free polygons (irregular beds, more work).
Backdrop — blank grid, or a real image (satellite/drone photo of the property) to trace over? Image backdrop needs an upload + scale/anchor step.
Scale — do we care about real dimensions (sq ft, spacing math, "how many tomatoes fit") or is it just a visual layout?
Depth — does a plot nest sub-boxes (rows/sections), or is one level of beds enough for v1?
Mobile — draw on phone in the garden, or desktop-only layout tool?

Rough phases (once decisions are made)

A. Data model — geometry column(s) on Location + migration; decide box vs GeoJSON.
B. Taxonomy pass (#4) — settle the canonical garden hierarchy, clean up existing AREA locations to fit it.
C. Map editor — canvas/SVG view: draw/move/resize a box → create/edit Location; label + kind; delete guard (already blocked while a place holds active plants/items).
D. Read view — plants rendered in their bed; click a bed → its plants/logs.

Out of scope (for now)

GPS/real coordinates, multi-property, planting-density automation — revisit after v1 lands.

Filed from a wrap-up session (2026-07-12) to capture the parked #1+#4 work with requirements written down. Not started.

**Consolidates #1 (draw boxes on a map to define garden plots) and #4 (yard/garden taxonomy isn't great).** #4 depends on #1 — a good visual editor is what fixes the taxonomy — so tracking them as one piece of work. ## Goal A **map/plot view** of the property where you draw boxes (beds, zones, plots) to lay out the garden visually, and each box **is** a `Location` in the existing tree. Drawing a bed creates/edits a Location; plants placed in that bed show on the map. farmOS-style, homestead-scale. ## How it maps to what exists - `Location` already models places (self-ref tree, `LocationKind`, unlimited depth). **Plants are leaves in a Place.** So the map is a spatial editor over `Location`, not a new domain. - **New:** Locations need geometry. Today `Location` has no coordinates. Add optional geometry (e.g. `x/y/w/h` for simple boxes, or GeoJSON polygon for irregular beds) — nullable, so non-garden places (Basement, Shelf B) are unaffected. `LocationKind.AREA` is the obvious "drawable" kind. - The **#4 taxonomy fix** falls out of this: a canonical garden hierarchy (Property › Yard/Area › Bed/Plot › row?) that the map makes obvious and enforceable, instead of the current flat/ad-hoc AREA soup left over after the HomeBox import. ## Open questions (need Tony's decisions before building) 1. **Boxes or polygons?** Rectangles only (simpler, snap-to-grid) vs. free polygons (irregular beds, more work). 2. **Backdrop** — blank grid, or a real image (satellite/drone photo of the property) to trace over? Image backdrop needs an upload + scale/anchor step. 3. **Scale** — do we care about real dimensions (sq ft, spacing math, "how many tomatoes fit") or is it just a visual layout? 4. **Depth** — does a plot nest sub-boxes (rows/sections), or is one level of beds enough for v1? 5. **Mobile** — draw on phone in the garden, or desktop-only layout tool? ## Rough phases (once decisions are made) - **A. Data model** — geometry column(s) on `Location` + migration; decide box vs GeoJSON. - **B. Taxonomy pass (#4)** — settle the canonical garden hierarchy, clean up existing AREA locations to fit it. - **C. Map editor** — canvas/SVG view: draw/move/resize a box → create/edit Location; label + kind; delete guard (already blocked while a place holds active plants/items). - **D. Read view** — plants rendered in their bed; click a bed → its plants/logs. ## Out of scope (for now) GPS/real coordinates, multi-property, planting-density automation — revisit after v1 lands. --- _Filed from a wrap-up session (2026-07-12) to capture the parked #1+#4 work with requirements written down. Not started._

tonym referenced this issue

2026-07-12 20:04:51 +00:00

Maos liek farm OS #1

tonym referenced this issue

2026-07-12 20:04:51 +00:00

Yard/garden area #4

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bonna61/Moonbase#11