metric handling switch between MT and FT - #1530
Conversation
|
Thanks for working on this @atmobi998! I understand the goal -- when a StreetPlan project is set to FT, the 3DStreet labels should display in feet, and when it's MT, they should display in meters. That makes total sense as a user expectation. The issue with this PR is that it overwrites the user's global `unitsPreference` in Zustand/localStorage, which affects the entire app (measure line tool, other scenes, etc.) -- not just this one StreetPlan import. If a user opens a metric StreetPlan project, their preference gets silently changed for all future sessions too. This is a bigger change than it looks. There are some real design questions we'd need to answer before implementing:
I've been thinking through a few options at different levels of complexity: Option A — Prompt on import (simplest) When loading a StreetPlan scene whose `DispUnit` differs from the user's current setting, show a notification: "This StreetPlan project uses feet. Switch units to match?" The user clicks yes or no. No architectural changes — uses the existing toggle that's already in the toolbar. This covers the main use case with no new infrastructure. Option B — Scene-level units Each scene stores its own units setting. The toolbar toggle shows and controls the current scene's units (not a global preference). When importing from StreetPlan, the scene units are set automatically from `DispUnit`. Users can change it anytime via the toolbar. This means different scenes can have different units without interfering with each other. This requires changes to: scene metadata in store + JSON serialization, toolbar toggle behavior, StreetPlan import auto-set, and updating all display consumers (labels, measure tool). Option C — Scene-level units + user profile default Everything in Option B, plus a user-level preference for "create new scenes in metric/imperial" saved to the user's profile. New scenes inherit the user's preferred units. Existing scenes keep whatever they were set to. This additionally requires: profile/preferences UI, new scene creation logic, user profile storage, and migration handling. I'd suggest starting with Option A — it solves the immediate problem without any architectural risk. We can always upgrade to B or C later if the need is clear. Let me know your thoughts, and please close this PR for now. Regardless of which direction we go, please create an issue describing the problem and which option you think makes the most sense and we can discuss there. |
metric handling switch between MT and FT
Feet unit:
Meter unit: