<scribe> scribe: lbolstad

Device Orientation

<matt> http://www.w3.org/TR/2011/WD-orientation-event-20110628/

FPWD published today

<steveblock> http://lists.w3.org/Archives/Public/public-geolocation/2011May/0001.html

We'll first create issues from topics that have been brought up on the mailing list

Should we change the orientation axes?

http://www.w3.org/2008/geolocation/track/issues/88

<steveblock> http://developer.android.com/reference/android/hardware/SensorManager.html#getOrientation(float[], float[])

<matt> http://windowsteamblog.com/windows_phone/b/wpdev/archive/2010/09/08/using-the-accelerometer-on-windows-phone-7.aspx

<steveblock> http://developer.android.com/reference/android/hardware/SensorManager.html#getRotationMatrix(float[], float[], float[], float[])

<steveblock> http://lists.w3.org/Archives/Public/public-geolocation/2011Jun/0008.html

compassCalibrationEvent - when should it be fired? Should it require a listener?

http://www.w3.org/2008/geolocation/track/issues/89

<andreip> http://developer.apple.com/library/ios/#documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/MotionEvents/MotionEvents.html#//apple_ref/doc/uid/TP40009541-CH4-SW1

Frequency of the devicemotion event

http://www.w3.org/2008/geolocation/track/issues/90

<steveblock> http://lists.w3.org/Archives/Public/public-geolocation/2011Jun/0011.html

<steveblock> http://lists.w3.org/Archives/Public/public-geolocation/2011May/0017.html

Location of the origin. http://www.w3.org/2008/geolocation/track/issues/92

<matt> issue-92?

<trackbot> ISSUE-92 -- Should we specify the location of the origin ? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/92

Add window.ondevicemotion, window.ondeviceorientation ?

http://www.w3.org/2008/geolocation/track/issues/93

Approximate values in DeviceOrientation

http://www.w3.org/2008/geolocation/track/issues/94

Should we separate out compass heading?

http://www.w3.org/2008/geolocation/track/issues/95

So, issue 88

<matt> issue-88?

<trackbot> ISSUE-88 -- Should we change the orientation axes ? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/88

issue-88 ?

<trackbot> ISSUE-88 -- Should we change the orientation axes ? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/88

issue-88?

<trackbot> ISSUE-88 -- Should we change the orientation axes ? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/88

Steve: Android uses two different coordinate systems

Regarding compass heading, there's the "Augmented Reality" use case that may or may not be covered by the 6.1.3 Mapping use case

Steve: No, it's not

Should we add that as a fourth use case ?

AR: Hold the device in a non-horizontal, possibly non-vertical, orientation, then try to calculate the compass heading based on the current event values

it's hard

alternatively, we could provide example code in an appendix

The consensus in the room is that a code example in an appendix is our best option

<steveblock> Created http://www.w3.org/2008/geolocation/track/actions/79 for adding an example of the AR usecase

<matt> action-79?

<trackbot> ACTION-79 -- Stephen Block to add a worked example for finding the direction the screen is facing -- due 2011-07-05 -- OPEN

<trackbot> http://www.w3.org/2008/geolocation/track/actions/79

<andreip> http://msdn.microsoft.com/en-us/library/microsoft.devices.sensors.accelerometer(v=VS.92).aspx

Unclear what coordinate system Microsoft is using

Also unclear why we should align with the vehicle dynamics convention

http://doc.qt.nokia.com/qt-mobility-snapshot/sensors-api.html

<andreip> http://apidocs.meego.com/1.2/qtmobility/qaccelerometerreading.html

<matt> http://www.developer.nokia.com/Community/Wiki/S60_Sensor_Framework

so, it seems we're consistent with existing frameworks in the mobile industry at least

conclusion: We'll keep our current choice of orientation axes

<matt> ISSUE-88?

<trackbot> ISSUE-88 -- Should we change the orientation axes ? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/88

Steve will post a reply to the mailing list and close issue-88

issue-89?

<trackbot> ISSUE-89 -- Should we change how this event is fired? Should it require a listener? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/89

We agree with jgraham's comment and will change the wording in section 4.2 accordingly.

That is, the event will fire regardless of whether or not there are listeners registered.

issue-90?

<trackbot> ISSUE-90 -- How frequently should the devicemotion event be fired? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/90

Steve: From looking at Android and iOS the assumption is that the underlying HW updates the data at regular intervals.

We agree that we need to rephrase this sentence in section 4.3:

The event must fire at regular intervals and the interval property must provide this interval in milliseconds.

To better reflect the intention, which is that the interval at which the event is fired should be a best effort based on the underlying hardware interval.

<matt> (I'm worried about flooding of events, either with super fast hardware, or this whole sleep/wake thing)

issue-91?

<trackbot> ISSUE-91 -- Should we prefix these with Device* ? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/91

Yes, we will make that change

Steve will take this action, too.

issue-92?

<trackbot> ISSUE-92 -- Should we specify the location of the origin ? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/92

it is unclear how this is relevant to orientation

Steve will post a reply to the mailing list asking for clarification

<steveblock> http://lists.w3.org/Archives/Public/public-geolocation/2011Jun/0031.html

issue-93?

<trackbot> ISSUE-93 -- Add window.ondevicemotion, window.ondeviceorientation ? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/93

<andreip> http://dev.w3.org/html5/spec/Overview.html#handler-ontimeupdate

Andrei will take the action to clarify this issue wrt HTML5

issue-94?

<trackbot> ISSUE-94 -- Should implementations attempt to calculate values that are not determined by hardware devices? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/94

The consensus is no, we should not do that

issue-95?

<trackbot> ISSUE-95 -- Should we separate out compass heading? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/95

<steveblock> re issue 94 - http://lists.w3.org/Archives/Public/public-geolocation/2011Jun/0032.html

<matt> Charter 2

<matt> matt: As it stands, V2 we say it's v1 plus civic addressing

<matt> steveblock: And the vertical component of velocity

<matt> ISSUE-87?

<trackbot> ISSUE-87 -- Consider exposing the vertical component of velocity -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/87

Geolocation v2

<steveblock> http://www.w3.org/2008/geolocation/track/issues/97

issue-7?

<trackbot> ISSUE-7 -- Should heading & speed be moved out of the Coordinates interface? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/7

<matt> Allan's initial comments about heading

<matt> [[Heading/Direction (less so) and speed (more so) are not specific to

<matt> geospatial information AND are common to both civic as well as

<matt> geospatial location objects. Suggest heading/direction and speed should

<matt> be a separate object that can be referenced by both civic and geospatial

<matt> positions.]]

at the previous f2f we discussed the use case where an application wants just the velocity (and/or heading), and not the location

there's (arguably) no privacy concerns related to velocity/heading/altitude, which is an argument for separating them out

backwards compatibility with v1 is also important

andreip: We could simply make all attributes in the Coordinates interface optional

Wojciech: Proposal is to add two new optional attributes to PositionOptions:

requestCoordinates (default: true), requestAddress (default: false)

In the Position object, we make the coords attribute optional and add an address attribute, also optional

if requestCoordinates AND requestAddress are both absent in PositionOptions, an implementation MUST return coordinates

in order to preserve backwards compatibility

slightly different proposal from Steve: requireCoordinates (default: true) instead of requestCoordinates

third proposal from andreip: add getCurrenPositionv2() with the semantics of the above proposals, just to get rid of the additional flags in PositionOptions

requireLatLong is probably a better name than requireCoordinates, since an app could still get e.g. speed from the Coordinates if this flag is set to false

we have consensus in the meeting room that either a new method or requireLatitudeLongitudeAccuracy is a good resolution resolution to issue-7

Steve will write it up and post in on the mailing list

it also means that we won't do what's proposed in issue-96

<matt> Chair: Lars Erik

<matt> Meeting: Geolocation F2F 2011 Day 2

<matt> ISSUE-43?

<trackbot> ISSUE-43 -- Proximity interface -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/43

<matt> Proximity alarm end of thread

<matt> ACTION-70?

<trackbot> ACTION-70 -- Andrei Popescu to add use cases from F2F to V2 spec -- due 2010-11-11 -- OPEN

<trackbot> http://www.w3.org/2008/geolocation/track/actions/70

<matt> issue-85?

<trackbot> ISSUE-85 -- Replace the document origin URI requirement with something else? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/85

<steveblock> http://dev.w3.org/cvsweb/geo/api/spec-source.html.diff?r1=1.91;r2=1.92;f=h

<matt> NMEA string

Just quickly documenting what we decided on the issues...

issue-85: Closed. We already made the requested change in v1 and keep that in v2

<trackbot> ISSUE-85 Replace the document origin URI requirement with something else? notes added

issue-86?

<trackbot> ISSUE-86 -- There is no way to pass additional arguments to geolocation callbacks -- closed

<trackbot> http://www.w3.org/2008/geolocation/track/issues/86

<matt> CLOSE ISSUE-85

<trackbot> ISSUE-85 Replace the document origin URI requirement with something else? closed

Andre will close issue-86 based on f2f discussions with hixie

issue-81?

<trackbot> ISSUE-81 -- Civic address format transformations -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/81

<andreip> http://gpsinformation.net/main/gpsspeed.htm

Will be closed when Action-57 is.

issue-87?

<trackbot> ISSUE-87 -- Consider exposing the vertical component of velocity -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/87

<steveblock> http://www.w3.org/2008/geolocation/track/issues/99

issue-99?

<trackbot> ISSUE-99 -- Need to clarify whether speed property is magintude of velocity or horizontal component -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/99

so, the resolution to issue-87 is that we will expose the vertical component in v2

issue-97?

<trackbot> ISSUE-97 -- Do we need FunctionOnly attribute on the callback interfaces? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/97

<matt>

<matt> DAP mail about FunctionOnly

<matt> Added FunctionOnly

<matt> Ollie's email

The consensus is that we'll change [FunctionOnly] to [Callback] in v2, not in v1.

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/this is a good/either a new method or requireLatitudeLongitudeAccuracy is a good resolution/
Found Scribe: lbolstad
Inferring ScribeNick: lbolstad
Present: Matt Lars_Erik Steve Andrei Wojciech Diana
Agenda: http://lists.w3.org/Archives/Member/member-geolocation/2011Jun/0005.html
Got date from IRC log name: 28 Jun 2011
Guessing minutes URL: http://www.w3.org/2011/06/28-geolocation-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.