See also: IRC log
<scribe> scribe: lbolstad
<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[])
<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
<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> 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.[End of scribe.perl diagnostic output]