Metrication plan

[louh]

It's happening!

Starting from street schema version 30, we are updating the street data model and UI in Streetmix to use metric units by default, rather than the US-centric imperial measurement system. This fulfills a long-standing goal to better serve global needs by adopting an international standard of measurement, resolve long-standing issues with imprecision (#1952), and simplify some of the math used in rendering UI.

This work is currently being tested internally and may continue to evolve. If everything looks fine, metrication will roll out to the main branch next week at earliest (week of February 26, 2024), and be deployed to production shortly after. Note that this may impact external consumers of the Streetmix API. We're already communicating with those users, but if you have not heard from me yet, please drop a note here.

Data model changes:

• Schema version update to 30
• The units property will change its values so that 0 means metric, 1 means imperial (formerly 2 was metric)
• The width property on streets and segments, as well as computed properties occupiedWidth and remainingWidth, will be converted to values in the metric system, using the following conversion:
  • For streets currently using the metric system, values will be converted from imperial using the existing Streetmix lossy conversion rate (ft * 0.3). This preserves existing values for metric streets.
  • For streets currently using the imperial system, values will be converted to metric using the more precise conversion rate (ft * 0.3048), then stored as metric to 3 decimal points. (e.g. a 10' lane will be stored in Streetmix as 3.048 m).

Streetmix app changes:

• For metric users: no changes.
  • When converting from feet, rounding errors can appear in the UI. This is an existing problem and goes away as users fine tune their own streets. We are not automatically changing this because we can't assume what values users intended.
• For imperial users: the conversion rate to imperial from metric will change to the more precise formula (m * 3.2808) which works all the way up to values up to and over 200'
• UI scale: no changes currently proposed.
  • This might change in a future update if rounding errors become problematic (can create issues like gaps between polygons, etc).

[kfarr]

Thanks for this, is there any way to get an example json response in this new metric format with a new units value? (Yes received via Discord, pasted below)

The units property will change its values so that 0 means metric, 1 means imperial (formerly 2 was metric)

Maybe this means to say that formerly 2 was imperial? Right now the response includes units = 2 and it appears to be imperial units: https://streetmix.net/api/v1/streets/763d8b20-e519-11eb-9f95-39e599c09049 (this statement was incorrect, see below for clarification)

Here's my attempt to make sense of existing / new logic.

Current Behavior

Imperial units: 1

• Imperial test street https://streetmix.net/kfarr/125/imperial-test
• Imperial API response https://streetmix.net/api/v1/streets?namespacedId=125&creatorId=kfarr
• units: 1; schemaVersion: 28
• Database (JSON API response) width units are IMPERIAL
• Ask for front-end to display as-is as IMPERIAL

Metric units: 2

• Metric test street https://streetmix.net/kfarr/126/metric-test
• Metric API response https://streetmix.net/api/v1/streets?namespacedId=126&creatorId=kfarr
• units: 2; schemaVersion: 28
• Database (JSON API response) width units are IMPERIAL
• Ask for front-end to realtime convert to METRIC

New behavior

Metric units: 0

• New Metric API response Example - streetmix-metric-example-response.json
• units: 0; schemaVersion: 30
• Database (JSON API response) width units are METRIC
• Ask for front-end to display as-is METRIC

Imperial units: 1

• New Imperial API response Example - draft units-1-streetmix-metric-example-response.json
• units: 1; schemaVersion: 30
• Database (JSON API response) width units are METRIC
• Ask for front-end to realtime convert to IMPERIAL

units: 2 - deprecated

• units: 2; schemaVersion: 30 INVALID VALUE

[louh]

Resolved in #2933.