Feed Reader BotСсылка
this wrong and pins "drift" when you place them at anything other than 100% zoom — a classic and maddening bug. Getting the transform math right is what makes placement feel exact. Design decision #3: pins that don't grow when you zoom If the whole canvas scales by scale, the pins scale with it — zoom to 5× and your dots become giant blobs that cover the very defect they mark. The fix is to counter-scale each pin by the inverse of the zoom: transform: `translate(-50%, -50%) scale(${1 / scale})` The translate(-50%, -50%) centres the dot on its coordinate; the scale(1 / scale) cancels the parent's zoom so the pin stays a constant visual size at any zoom level. Small detail, big difference in how "solid" the tool feels. Design decision #4: one coordinate model for flat photos and 360° panoramas Inspectors also shoot 360° panoramas of whole rooms. A panorama isn't a flat plane — a point on it is really a direction (pitch and yaw) on a sphere. I could have built a second, separate hotspot system for panoramas... but I didn't want to.
Instead, the same normalized (x, y) is reinterpreted for 360° captures via a single mapping: const { pitch, yaw } = toPitchYaw(parseFloat(pin.x), parseFloat(pin.y)); A captures.is_360 boolean flag decides which lens to view the coordinate through. Flat image? (x, y) is a position. Panorama? The same (x, y) maps to a spherical direction. One storage format, one placement flow, two renderers. The data model didn't have to know about the difference, which kept the schema — and my head — clean. The data model: a hotspot is a defect Notice the hotspot row carries issueSeverity, issueStatus, notes, and resolvedPhoto. A hotspot isn't just a marker that points at a separate "issue" record — it is the defect, anchored in space. This is a deliberate denormalization: the issue's display fields live on the hotspot so the canvas can render every pin (with its severity colour) in a single query, without joining and re-fetching issue records for each dot. For a view that paints dozens of pins at once, that read-path simplicity is worth the redundancy.
Everything cascades on delete — remove a capture and its hotspots go with it (onDelete: "cascade"), so there are no orphaned pins pointing at images that no longer exist. What I'd do differently / open questions * Precision vs. storage: numeric(5,4) is precise but heavier than a real. At current scale it's irrelevant; at millions of hotspots I'd benchmark it.
* Denormalized issue fields speed up reads but mean an issue edit has to update the hotspot too. A single-writer inspection flow makes this safe today; a collaborative one would need more care.
* 360° math currently assumes an equirectangular projection. Other panorama formats would need their own toPitchYaw. Future work: the dataset nobody planned for Here's the part I find most interesting, and where I want to take this next.
Every hotspot an inspector places is a human-labeled training example: an image, a precise (x, y) location, a defect category, and a severity — "at this spot, there is a major tile hollowness." The app has been quietly accumulating a labeled, spatially-grounded defect dataset as a byproduct of normal use.
That opens a genuine research direction: can a computer-vision model learn to propose hotspots automatically? Given a fresh site photo, suggest "likely crack here, likely dampness there," and let the inspector confirm or reject — turning placement from fully-manual into human-in-the-loop verification. The normalized-coordinate design already gives model output and human labels the exact same representation, so predictions and ground truth are directly comparable.
[...]