Consider creating separate fields for units of measure

[ghobona]

One of the observations made by participants of the March 2022 sprint was that attaching the units of a value to a property name (e.g. length_m) could potentially lead to ambiguity (e.g. whether the _m stands for meters or miles).

A possible solution could be to create separate fields for the units of measure. For example:

    {
      "id": 3,
      "type": "Feature",
      "properties": {
        "featureType": "segment",
        "levelOfDetail": "visualization",
        "length": 70,
        "length_units": "http://www.opengis.net/def/uom/OGC/1.0/metre",
        "duration": 46,
        "duration_units": "(http://www.opengis.net/def/uom/SI/second",
        "instructions": "continue",
        "text": "Head north on North Rd. Go for 70 m."
      },
      "geometry": {
        "type": "Point",
        "coordinates": [-77.0721011, 38.9308998]
      }
    }

[cportele]

That approach was rejected, because separate properties for the unit (which implies that everyone can use the units that they want) just pushes the burden to those processing routes to be able to convert between units. This is an obstacle for interoperability. The units should be fixed to a unit, which should be based on SI units.

In addition, separate properties with a URI unit also make the route document larger and more verbose - with content that is identical from segment to segment.

[skyNacho]

I agree to simplify the standard and to avoid unnecessary fields in the route content. However, we cannot ignore the fact that route data are typically encoded and consumed differently in the US than in Europe.

To start with, when importing the road data, it will probably be in local units: for example, OSM encodes speed limits in mph for the US and in kph for Europe. Forcing a conversion to a standard unit in REM (such as kph) will lead to weird user interfaces ("the speed limit is now 56.33 kph") or to unnecessary conversions (convert from mph in OSM to kph in REM, and then the client will convert back from kph in REM to mph in the user interface).

Another example could be the indications: probably an indication of "drive straight 2 miles" would be more understandable to a typical American than "drive straight 3 kilometers", but the server should prepare these texts already with the user preferences in mind. I suffered some of these problems recently when driving in the US and it made me think about the limitations that we might be setting in the standard.

[cportele]

Meeting 2022-09-20: We agreed that the current approach is correct (fixed unit for length/duration/height/weight and use speed unit as used on the speed limit sign). It is up to the client to present this according to the preferences of the user. We can probably improve the documentation to explain this better. @cportele will review and make a proposal.