Screen and Device local coordinates #31

pozdnyakov · 2018-01-31T10:10:45Z

This patch introduces definition for 'device' and 'screen'
coordinate systems as possible local coordinates options
for spatial sensor classes.

The SpatialSensorOptions dictionary and the
"construct spatial sensor object" are added, so that
the client can set the local coordinate system for a
Sensor instance from the constructor.

This patch is a part of fix for w3c/sensors#257

Preview | Diff

pozdnyakov · 2018-01-31T10:44:35Z

@kenchris, @alexshalamov, @anssiko PTAL

kenchris · 2018-01-31T10:46:11Z

index.bs


-<img src="images/accelerometer_coordinate_system.png" srcset="images/accelerometer_coordinate_system.svg" style="display: block;margin: auto;" alt="Accelerometer coordinate system.">
+The [=local coordinate system=] for the spatial sensor classes in this specification


defined in this specification

kenchris · 2018-01-31T10:46:54Z

index.bs

+can be defined as either [=device coordinate system=] or [=screen coordinate system=].
+
+The <dfn export>device coordinate system</dfn> is defined as a three dimensional
+Cartesian coordinate system (x, y, z) which is bound to the physical device.


, before which (that is English grammar, if you don't like ", which", then use "that"

kenchris · 2018-01-31T10:47:31Z

index.bs

+The <dfn export>device coordinate system</dfn> is defined as a three dimensional
+Cartesian coordinate system (x, y, z) which is bound to the physical device.
+For devices with display the origin of the [=device coordinate system=] is in the center
+of the device display. If the device is held in a default position the Y-axis points


"a default position" sounds wake... will it have multiple? in its default position

kenchris · 2018-01-31T10:48:03Z

index.bs

+the X-axis points towards the right of the [=dom-screen=] and Z-axis is a
+vector product of X and Y axes and it points towards the [=dom-screen=] viewer.
+
+The main difference between the [=device coordinate system=] and the [=screen coordinate system=]


, before is

kenchris · 2018-01-31T10:48:15Z

index.bs

+vector product of X and Y axes and it points towards the [=dom-screen=] viewer.
+
+The main difference between the [=device coordinate system=] and the [=screen coordinate system=]
+is that the [=screen coordinate system=] always follows [=dom-screen=] orientation, i.e. it


follows THE

kenchris · 2018-01-31T10:48:46Z

index.bs

+The main difference between the [=device coordinate system=] and the [=screen coordinate system=]
+is that the [=screen coordinate system=] always follows [=dom-screen=] orientation, i.e. it
+will swap X and Y axes in relation to the device if the [=current orientation type=]
+changes. In contrast, the [=device coordinate system=] will always remain the same.


Should you mention use-cases?

yep, and we're also planning to add some illustrations, however I'd like it to be in follow up patches.

kenchris · 2018-01-31T10:50:59Z

index.bs

+  enum LocalCoordinateSystem { "device", "screen" };
+
+  dictionary SpatialSensorOptions :  SensorOptions  {
+    LocalCoordinateSystem localCoordinates = "device";


I think it might be clearer if we call it "referenceFrame" or so?

LocalCoordinateSystem referenceFrame = "device";

Thanks for this comment! it is exactly what I'm thinking right now :) also we can probably mention at w3c/sensors#340, that 'local coordinate system' represents frame of reference for the sensor readings..

pozdnyakov · 2018-01-31T13:22:53Z

@kenchris I've updated the patch, could you take another look?

kenchris · 2018-01-31T14:18:55Z

index.bs

+
+The <dfn export>device coordinate system</dfn> is defined as a three dimensional
+Cartesian coordinate system (x, y, z), which is bound to the physical device.
+For devices with display the origin of the [=device coordinate system=] is in the


For devices with A display COMMA, the origin

is REMOVE IN the center

kenchris · 2018-01-31T14:19:08Z

index.bs

+The <dfn export>device coordinate system</dfn> is defined as a three dimensional
+Cartesian coordinate system (x, y, z), which is bound to the physical device.
+For devices with display the origin of the [=device coordinate system=] is in the
+center of the device display. If the device is held in its default position the Y-axis


position, COMMA

kenchris · 2018-01-31T14:22:07Z

index.bs

+For devices with display the origin of the [=device coordinate system=] is in the
+center of the device display. If the device is held in its default position the Y-axis
+points towards the top of the display, the X-axis points towards the right of the
+display and Z-axis is a vector product of X and Y axes and it points towards the


... is THE vector product of the X- and Y-axes and it points OUTWARDS from the display, and towards the VIEWER.

anssiko · 2018-01-31T14:19:47Z

index.bs

@@ -33,6 +33,10 @@ urlPrefix: https://w3c.github.io/sensors; spec: GENERIC-SENSOR
    text: default sensor
    text: construct a sensor object; url: construct-sensor-object
    text: sensor type
+urlPrefix: https://w3c.github.io/screen-orientation; spec: SCREEN-ORIENTATION
+  type: dfn
+    text: current orientation type


text: current orientation type, url: dfn-current-orientation-type

(Or whatever it takes to fix the link.)

kenchris · 2018-01-31T14:22:22Z

index.bs

+display viewer.
+
+The <dfn export>screen coordinate system</dfn> is defined as a three dimensional
+Cartesian coordinate system (x, y, z), which is bound to [=dom-screen=].


kenchris · 2018-01-31T14:22:51Z

index.bs

+Cartesian coordinate system (x, y, z), which is bound to [=dom-screen=].
+The origin of the [=screen coordinate system=] is in the center
+of the [=dom-screen=]. The Y-axis always points towards the top of the [=dom-screen=],
+the X-axis points towards the right of the [=dom-screen=] and Z-axis is a


kenchris · 2018-01-31T14:25:14Z

index.bs

+Reference Frame {#reference-frame}
+----------------
+
+The [=local coordinate system=] for the [=spatial sensor=] classes defined


Maybe

The reference frame for the sensor classes defined in this specification, is a local coordinate system, which can be defined as either THE device coordinate system, or THE screen coordinate system

Reference frame also includes time, while 'local coordinate system' omits time component.

can be rephrased: "The reference frame for the sensor classes defined in this specification,
is expressed in a [=local coordinate system=]"

alexshalamov · 2018-01-31T14:41:30Z

index.bs

+urlPrefix: https://w3c.github.io/screen-orientation; spec: SCREEN-ORIENTATION
+  type: dfn
+    text: current orientation type
+    text: dom-screen; url: dom-screen


I think, if text and link are the same, you can leave just 'text:' part

Usually that works, but in this case text: current orientation type creates a link to https://w3c.github.io/screen-orientation/#current-orientation-type that does not exist. Should go to https://w3c.github.io/screen-orientation/#dfn-current-orientation-type thus explicit text: current orientation type; url: dfn-current-orientation-type needed. ReSpec bug perhaps.

alexshalamov · 2018-01-31T14:43:34Z

index.bs

+Reference Frame {#reference-frame}
+----------------
+
+The [=local coordinate system=] for the [=spatial sensor=] classes defined


Reference frame also includes time, while 'local coordinate system' omits time component.

alexshalamov · 2018-01-31T14:45:42Z

index.bs

+  enum LocalCoordinateSystem { "device", "screen" };
+
+  dictionary SpatialSensorOptions :  SensorOptions  {
+    LocalCoordinateSystem referenceFrame = "device";


I would prefer LocalCoordinateSystem coordinateSystem = "device";

IMO, referenceFrame would be more understandable for the API user (even though coordinateSystem is a more accurate term from the physics point of view). WDYT?

alexshalamov · 2018-01-31T14:47:17Z

index.bs

+
+The main difference between the [=device coordinate system=] and the [=screen coordinate system=],
+is that the [=screen coordinate system=] always follows the [=dom-screen=] orientation,
+i.e. it will swap X and Y axes in relation to the device if the [=current orientation type=]


should we use term from generic sensor spec? Instead of saying 'swap' use remap readings?

here is no remap happening, we're just describing the coordinate system per se (apart from readings transformation)

kenchris · 2018-02-01T09:25:21Z

"In physics, a frame of reference (or reference frame) consists of an abstract coordinate system and the set of physical reference points that uniquely fix (locate and orient) the coordinate system and standardize measurements." (wikipedia)

I don't think it necessarily includes times, though I does in Einsteinian relativity.

In a way, a 4 component system with time included is also a coordinate system

kenchris · 2018-02-01T09:29:17Z

Found this online: https://www.physicsforums.com/threads/frame-of-reference-vs-coordinate-system.110090/

This patch introduces definition for 'device' and 'screen' coordinate systems as possible local coordinates options for spatial sensor classes. The `SpatialSensorOptions` dictionary and the "construct spatial sensor object" are added, so that the client can set the local coordinate system for a Sensor instance from the constructor.

pozdnyakov · 2018-02-01T11:04:20Z

PTAL at the updated patch

pozdnyakov · 2018-02-01T11:20:39Z

From https://www.quora.com/What-is-a-reference-frame-and-how-does-one-determine-where-a-frame-of-reference-begins-and-where-it-ends :

A reference frame is really just a coordinate system for spacetime, i.e., history. It has to take every event in history and assign it time (t) and space (x, y, z or the like) coordinates.

kenchris · 2018-02-01T11:23:52Z

Lgtm

kenchris

Ah have to make a review and not comments

kenchris · 2018-02-01T11:51:10Z

index.bs

@@ -33,6 +33,10 @@ urlPrefix: https://w3c.github.io/sensors; spec: GENERIC-SENSOR
    text: default sensor
    text: construct a sensor object; url: construct-sensor-object
    text: sensor type
+urlPrefix: https://w3c.github.io/screen-orientation; spec: SCREEN-ORIENTATION


Trying to find out how I approve :)

pozdnyakov · 2018-02-01T11:56:48Z

Thank you for review!

pozdnyakov requested review from anssiko and alexshalamov January 31, 2018 10:10

kenchris reviewed Jan 31, 2018

View reviewed changes

pozdnyakov force-pushed the screen_coordinates branch from 75aacaa to 67b649c Compare January 31, 2018 13:21

kenchris reviewed Jan 31, 2018

View reviewed changes

anssiko requested changes Jan 31, 2018

View reviewed changes

kenchris reviewed Jan 31, 2018

View reviewed changes

alexshalamov reviewed Jan 31, 2018

View reviewed changes

pozdnyakov force-pushed the screen_coordinates branch from 67b649c to 182d910 Compare February 1, 2018 11:03

alexshalamov approved these changes Feb 1, 2018

View reviewed changes

anssiko approved these changes Feb 1, 2018

View reviewed changes

kenchris approved these changes Feb 1, 2018

View reviewed changes

pozdnyakov merged commit a7455d3 into w3c:gh-pages Feb 1, 2018


		<img src="images/accelerometer_coordinate_system.png" srcset="images/accelerometer_coordinate_system.svg" style="display: block;margin: auto;" alt="Accelerometer coordinate system.">
		The [=local coordinate system=] for the spatial sensor classes in this specification

Screen and Device local coordinates #31

Screen and Device local coordinates #31

Conversation

pozdnyakov commented Jan 31, 2018 • edited by pr-preview bot Loading

pozdnyakov commented Jan 31, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pozdnyakov commented Jan 31, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pozdnyakov Feb 1, 2018 • edited Loading

Choose a reason for hiding this comment

kenchris commented Feb 1, 2018 • edited Loading

kenchris commented Feb 1, 2018

pozdnyakov commented Feb 1, 2018

pozdnyakov commented Feb 1, 2018

kenchris commented Feb 1, 2018

kenchris left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pozdnyakov commented Feb 1, 2018

pozdnyakov commented Jan 31, 2018 •

edited by pr-preview bot

Loading

pozdnyakov Feb 1, 2018 •

edited

Loading

kenchris commented Feb 1, 2018 •

edited

Loading