15:42:30 RRSAgent has joined #geolocation 15:42:30 logging to http://www.w3.org/2011/10/31-geolocation-irc 15:42:32 RRSAgent, make logs member 15:42:32 Zakim has joined #geolocation 15:42:34 Zakim, this will be GEO 15:42:35 I do not see a conference matching that name scheduled within the next hour, trackbot 15:42:35 Meeting: Geolocation Working Group Teleconference 15:42:35 Date: 31 October 2011 15:42:38 zakim, room for 5? 15:42:40 ok, matt; conference Team_(geolocation)15:42Z scheduled with code 26631 (CONF1) for 60 minutes until 1642Z; however, please note that capacity is now overbooked 15:43:10 zakim, dial sierra 15:43:10 ok, matt; the call is being made 15:43:11 Team_(geolocation)15:42Z has now started 15:43:12 +Sierra 15:43:34 zakim, code? 15:43:34 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), matt 15:43:46 Hi Matt 15:43:55 give me 5 mins please... 15:48:46 dialing... 15:49:11 + +49.173.537.aaaa 15:50:10 andreip has joined #geolocation 15:51:06 it breaks up... 15:51:50 lbolstad has joined #Geolocation 15:52:04 a lot... 15:54:36 ill try dialing again, as it breaks up just too much 15:54:39 - +49.173.537.aaaa 15:54:59 -> http://msdn.microsoft.com/en-us/ie/hh410106#_HTML5_geolocation dev guide for IE9 15:56:21 + +49.173.537.aabb 15:56:23 -> http://ie.microsoft.com/testdrive/HTML5/Geolocation/Default.html test drive 15:56:33 zakim, aabb is dcheng3 15:56:33 +dcheng3; got it 16:01:52 the quality is really bad...it breaks up too much to follow. Sometimes there's just silence like for 10 seconds straight... :-/ 16:02:25 Not sure if we can do something. Otherwise I'll just do my best to follow... 16:02:51 ernesto_jimenez has joined #geolocation 16:06:17 steveblock has joined #geolocation 16:08:20 stakagi has joined #geolocation 16:10:04 Present: Lars Erik, Doug, Steve, Satoru Takagi, Don Brutzman, Ernesto Jimenez 16:10:17 scribe: Matt 16:10:29 Topic: Introductions 16:11:09 Ernesto: I work for Vodafone R&D in the standards team. I'm in DAP too. 16:11:21 Doug: I'm here for the Mozilla foundation, I work on Gecko stuff. 16:11:31 lbolstad: I work at Opera, charing the group. 16:12:03 steveblock: I'm from Google, I work in Chrome, and on the Geolocation stuff. 16:12:05 stakagi: I work at KDDI, I'm in the SVG WG and working on SVG map. 16:12:22 Don: I'm from Web3D Consortium, we work on 3d, AR and such. 16:12:32 Topic: Agenda 16:12:57 lbolstad: The only specific thing we have on the agenda is for Neil Trevett to present to us from the Khronos Group about StreamInput. 16:16:03 matt: The V1 is just awaiting the transition call. lbolstad and I will schedule that for next week. 16:16:19 matt: V2 I just haven't had a chance to publish in the last month or so since the last edits. Will publish ASAP. 16:17:01 matt: Have we received any feedback on DeviceOrientation? 16:17:12 steveblock: As near as I can tell the initial event problem is the only open one. 16:19:35 lbolstad: We have a bunch of old actions. In terms of how to spend time in this meeting, the goal is to close the open issues obviously. 16:19:44 steveblock: I think we could benefit from time spent on initial event. 16:20:04 matt: Especially if we could loop back with them this week. 16:20:44 doug: We're already violating this in Gecko now, we send a cached position. 16:20:54 doug: I would think he probability of them telling us not to do this is high. 16:22:03 steveblock: The V2 status, did we finish? 16:22:05 matt: I can publish as soon as we are out of the moratorium. 16:22:20 lbolstad: V2 does have an issue on the address interface. 16:22:43 lbolstad: Robin Berjon sent an email proposing that someone have a discussion with him during TPAC, Andrei volunteered. 16:23:14 -> http://lists.w3.org/Archives/Public/public-geolocation/2011Oct/0004.html Robin on Address interface 16:24:11 steveblock: There's also the question of what do we do in the spec about when the DOM is torn down? I don't think we've resolved that. 16:24:17 doug: The alternative is to not to? 16:24:30 steveblock: No, but is it automatically assumed, etc. Spec clarity issue. 16:25:34 matt: Do we want to have Robin here to discuss it or should he and Andrei do it themselves? 16:25:38 lbolstad: meeting would be best. 16:27:48 matt: So, we've got: Open Issues and Actions, Last Call details, Neil meeting, issue on initial event, address interface w/DAP 16:29:14 lbolstad: And we could move faster on device orientation by having a zero day CR, right? 16:29:17 matt: Yes, if we have our IR. 16:29:27 matt: I haven't mined the list for DeviceOrientation issues, has anyone? 16:30:02 lbolstad: Haven't seen any. The DAP Sensor API has one that covers raw sensor data from compass and orientation. 16:32:22 -> http://dev.w3.org/2009/dap/system-info/Sensors.html 16:33:03 lbolstad: There might be an issue about delivery rate of data. 16:34:39 doug: We've taken a position that we don't need to do it until someone says they need it. 16:34:39 matt: Has anyone tried just blasting it? 16:34:57 doug: You could probably hang UAs. 16:35:13 brutzman has joined #geolocation 16:35:27 help 16:35:28 steveblock: It's a UA defined regular interval. 16:38:53 Topic: V2 Issues 16:39:15 -> http://dev.w3.org/geo/api/spec-source-v2 V2 Editor's Draft 16:39:48 -> http://www.w3.org/2008/geolocation/track/issues/open V2 open issues 16:40:07 ISSUE-7? 16:40:07 ISSUE-7 -- Should heading & speed be moved out of the Coordinates interface? -- open 16:40:07 http://www.w3.org/2008/geolocation/track/issues/7 16:40:29 steveblock: I made the change, but there's an outstanding action to add requirements on andreip. 16:40:46 doug: The issue was moving velocity stuff out of the address interface? 16:40:59 steveblock: It wasn't about it being lossy, but how to handle UAs that only handle civic address. 16:41:11 steveblock: We resolved that by adding requiringCoords. 16:41:13 action-82? 16:41:13 ACTION-82 -- Stephen Block to update V2 spec with requireCoords and send diff to list -- due 2011-09-14 -- CLOSED 16:41:13 http://www.w3.org/2008/geolocation/track/actions/82 16:41:28 steveblock: So, I did action-82, but action-72 was still there. 16:41:30 action-72? 16:41:30 ACTION-72 -- Andrei Popescu to to add the new requirements talked about at the f2f to the requirement section -- due 2010-11-11 -- OPEN 16:41:30 http://www.w3.org/2008/geolocation/track/actions/72 16:42:05 doug: So the flag will make it - 16:42:20 steveblock: It's called requireCoords, if it's set to true, any callback will have lat/lng/velocity, and others are optional. 16:43:08 s/velocity/accuracy/ 16:43:11 rrsagent, draft minutes 16:43:11 I have made the request to generate http://www.w3.org/2011/10/31-geolocation-minutes.html matt 16:43:16 rrsagent, make logs public 16:43:18 rrsagent, draft minutes 16:43:18 I have made the request to generate http://www.w3.org/2011/10/31-geolocation-minutes.html matt 16:43:44 lbolstad: The commenter wanted it to work with out having geospatial info per se. 16:43:46 steveblock: Right. 16:44:53 issue-79? 16:44:53 ISSUE-79 -- Civic address use cases needed -- open 16:44:53 http://www.w3.org/2008/geolocation/track/issues/79 16:45:21 same :-/ But I'm trying to follow 16:46:08 ACTION-70? 16:46:08 ACTION-70 -- Andrei Popescu to add use cases from F2F to V2 spec -- due 2010-11-11 -- OPEN 16:46:08 http://www.w3.org/2008/geolocation/track/actions/70 16:46:14 pure silence 16:47:23 matt: Does Chaals' rule of thumb was if we don't want to compare we don't care much about format. 16:47:34 s/format/format, do we care about comparing?/ 16:48:39 lbolstad: We've said we will add the additional information field. And we'd add some text about mapping. 16:49:05 doug: We don't have addtionalInformation use right now. Interop there is wonky. 16:49:45 doug: It's also optional. 16:49:57 steveblock: The use case we get back to is always this campus information location network that has lots of info. 16:50:42 doug: You can also just put your own customized address object in there. 16:53:14 matt: I kind of want to make sure there's no trap in the requirements, where we might end up realizing it's not doable with this interface. 16:53:21 matt: Could we do that here? 16:53:25 steveblock: Sounds good. 16:53:34 steveblock: Andrei is on his way too. 16:54:15 lbolstad: The use cases we listed are things like form filling, order pizza, etc. 16:54:26 Minutes from last year's tpac f2f: http://www.w3.org/2010/11/04-geolocation-minutes.html#item04 16:55:40 steveblock: Let's write those use cases down. 16:56:18 steveblock: Pizza delivery one: you visit an online pizza ordering service and it fills in the address sufficiently to deliver a pizza. 16:56:47 steveblock: And we phrase it in a way that it's form filling and can be edited too. 16:56:53 steveblock: So you can get third floor type stuff. 16:57:02 doug: You could get that without editing. 16:57:33 lbolstad: So that is use case 1. 16:57:40 lbolstad: Search near address, is that any different? 16:58:21 matt: Is it any different than search with lat/lng info? 16:58:32 steveblock: It's typing in "near
" in a search field. 16:59:17 doug: Not seeing how it's different. 16:59:36 steveblock: Fundamentally, they're all about sending address to the server. 17:00:07 lbolstad: Wouldn't several or all of these be the same use case? 17:00:22 dougt has joined #geolocation 17:01:18 matt: If the use cases aren't different, why are we doing this, one could ask? 17:01:26 lbolstad: Because a pizza needs an address. 17:02:07 Present+ Andrei 17:02:37 steveblock: These two: pizza and nearby search is good. 17:02:59 lbolstad: Then there's the indoor position use case. 17:03:04 steveblock: That's worth adding. 17:03:28 andreip has joined #geolocation 17:03:41 matt: Is there some non-controversial use case we can have for indoor? 17:03:57 dougt: Coords isn't appropriate for indoor positioning. 17:04:25 steveblock: The use case would be office/campus environment and it finds the nearest printer via your desk number. 17:05:01 matt: There's three: indoor positioning, pizza delivery and nearby search. 17:06:27 -> http://lists.w3.org/Archives/Public/public-geolocation/2011May/0014.html Robin's mail 17:07:29 andreip has joined #geolocation 17:10:05 dcheng has joined #geolocation 17:10:25 andreip: I can just talk to Robin, no need for the group. 17:10:42 matt: We can work on test cases for V2 and orientation so we can do LC/CR. 17:10:53 lbolstad: So, we have three use cases. 17:11:25 steveblock: So we need requirements. 17:11:33 andreip: We've got those spelled out by Adrian too. 17:11:36 action-70? 17:11:36 ACTION-70 -- Andrei Popescu to add use cases from F2F to V2 spec -- due 2010-11-11 -- OPEN 17:11:36 http://www.w3.org/2008/geolocation/track/actions/70 17:12:05 ACTION-72? 17:12:05 ACTION-72 -- Andrei Popescu to to add the new requirements talked about at the f2f to the requirement section -- due 2010-11-11 -- OPEN 17:12:05 http://www.w3.org/2008/geolocation/track/actions/72 17:13:49 matt: Just because you requested an address doesn't mean it's an error if it fails to get one. 17:14:39 -> http://dev.w3.org/geo/api/spec-source-v2#requirements_section V2 Requirements 17:15:02 steveblock: So we have 6.2.1 that says lat/long we would say "have a human readable civic address" 17:17:24 -> http://www.w3.org/TR/contacts-api/#contactaddress-interface DAP 17:18:03 andreip: Civic address doesn't sound quite right to me. 17:18:35 matt: I think it came from advice of the Geopriv folks as a less ambiguous. 17:18:43 dougt: Does it imply the georpiv address block? 17:18:56 matt: I've heard it used elsewhere, like in AR, where it's not related to geopriv at all. 17:19:03 ^ it does not. 17:19:19 steveblock: Let's put a note explaining it. 17:26:04 steveblock: Let's add the phrase used in the later requirements: "must allow an application" to all of the earlier ones to make it clear it's a requirement on the API and not the UA. 17:26:45 andreip: I'll add the three Adrian listed. 17:30:55 andreip: They are in there now. 17:31:02 -> http://dev.w3.org/geo/api/spec-source-v2#requirements_section V2 Requirements 17:32:09 ACTION-72? 17:32:09 ACTION-72 -- Andrei Popescu to to add the new requirements talked about at the f2f to the requirement section -- due 2010-11-11 -- CLOSED 17:32:09 http://www.w3.org/2008/geolocation/track/actions/72 17:32:16 andreip: I closed ACTION-72. 17:32:47 ACTION-70? 17:32:47 ACTION-70 -- Andrei Popescu to add use cases from F2F to V2 spec -- due 2010-11-11 -- OPEN 17:32:47 http://www.w3.org/2008/geolocation/track/actions/70 17:33:04 rrsagent, draft minutes 17:33:04 I have made the request to generate http://www.w3.org/2011/10/31-geolocation-minutes.html matt 17:33:38 lbolstad has joined #Geolocation 17:34:35 Chair: Lars Erik Bolstad 17:35:43 rrsagent, draft minutes 17:35:43 I have made the request to generate http://www.w3.org/2011/10/31-geolocation-minutes.html matt 17:41:25 lbolstad has joined #Geolocation 17:41:29 stakagi has joined #geolocation 17:41:50 ernesto_jimenez has joined #geolocation 17:42:26 steveblock has joined #geolocation 17:42:29 andreip has joined #geolocation 17:47:06 lbolstad has joined #Geolocation 17:53:51 lbolstad has joined #Geolocation 18:02:38 stakagi has joined #geolocation 18:03:14 dougt has joined #geolocation 18:03:53 andreip has joined #geolocation 18:04:44 zakim, who is on the phone? 18:04:44 On the phone I see Sierra, dcheng3 18:05:26 lbolstad has joined #Geolocation 18:05:50 -> http://www.w3.org/2008/geolocation/track/issues/open open issues 18:06:15 ISSUE-7? 18:06:15 ISSUE-7 -- Should heading & speed be moved out of the Coordinates interface? -- open 18:06:15 http://www.w3.org/2008/geolocation/track/issues/7 18:06:52 ACTION-70? 18:06:52 ACTION-70 -- Andrei Popescu to add use cases from F2F to V2 spec -- due 2010-11-11 -- OPEN 18:06:52 http://www.w3.org/2008/geolocation/track/actions/70 18:07:05 CLOSE ISSUE-7 18:07:05 ISSUE-7 Should heading & speed be moved out of the Coordinates interface? closed 18:07:59 andreip has joined #geolocation 18:09:29 ACTION-57? 18:09:29 ACTION-57 -- Andrei Popescu to put field mapping information into the spec -- due 2009-11-10 -- CLOSED 18:09:29 http://www.w3.org/2008/geolocation/track/actions/57 18:15:19 ACTION-91? 18:15:19 ACTION-91 -- Diana Cheng to to collect feedback from developers about location accuracy and present at the next f2f -- due 2011-09-14 -- OPEN 18:15:19 http://www.w3.org/2008/geolocation/track/actions/91 18:15:20 dcheng3 has joined #geolocation 18:16:14 dcheng3: We'll work on it. 18:23:34 -> http://lists.w3.org/Archives/Public/public-geolocation/2011Oct/0011.html 18:29:34 lbolstad has joined #Geolocation 18:31:43 lbolstad has joined #Geolocation 18:35:31 dcheng3 has joined #geolocation 18:37:11 18:37:32 dougt: I would be happier to have a vendor name field, so people can say "is this a cisco object?" 18:37:47 steveblock: That then requires coordination from the location provider and the browser to plumb through. 18:38:35 dougt: Any new location provider doesn't come for free from the location provider. They'll use another protocol, someone has to write that code that produces a location object. Whoever writes that code can add those additional fields and the plumbing required. 18:38:59 dougt: The plumbing we have now in fx and Opera is to use Google, but whenever we get anew one we'll get new code to support it. 18:39:29 andreip: "When in doubt, leave it out" 18:39:43 dougt: We're looking for a use case. It's some vendor specific undefined string. 18:40:13 matt: No one is worried about populating the top level of the address object? 18:40:17 dougt: It'll happen. 18:41:52 ernesto_jimenez: From reading the spec, I would expect maybe that there's indoor positioning, or something but I don't know that I would use it. 18:41:58 andreip: What would you expect to find in it? 18:42:04 ernesto_jimenez: From what I read, it'd be human readable. 18:42:41 matt: I think that was in a requirement somewhere. 18:43:36 andreip: The only sensible thing you could do with it is display it to a human. 18:43:41 dougt: How would you know you could even? 18:43:55 andreip: Let's do the right thing and if it's sufficiently common we'll add it to the spec. 18:44:24 dougt: Adding a new field to the location provider stuff takes minutes. I worry that in a year or two we'll want to support indoor positioning, add 15 fields, and then what would additionalInfo mean. 18:46:21 matt: Temp check, who will implement it? 18:46:32 18:46:53 lbolstad: We did say at one point we could dump the extra info from that rfc into the additional info field. 18:48:03 dougt: There was code for LO-PDIF in fx, but I told Richard I'd remove it and to make it an add-on and he seemed fine. 18:50:11 dougt: I think we're saying we should drop it. 18:50:55 RESOLUTION: We will drop the additionalInfo field from address interface. 18:51:09 lbolstad has joined #Geolocation 18:51:29 rrsagent, draft minutes 18:51:29 I have made the request to generate http://www.w3.org/2011/10/31-geolocation-minutes.html matt 18:52:14 ACTION: andrei to remove additionalInfo from address field 18:52:15 Created ACTION-92 - Remove additionalInfo from address field [on Andrei Popescu - due 2011-11-07]. 18:52:19 close ACTION-92 18:52:19 ACTION-92 Remove additionalInfo from address field closed 18:53:57 lbolstad: So our recommendation could be for others to write add-ons? 18:54:06 dougt: Can you create dom objects that can get exposed to contents? 18:54:10 andreip: Not to shadow existing ones. 18:54:15 dougt: Replace? 18:55:00 andreip: No. 18:55:09 lbolstad: We should expect some questioning around it. 18:56:08 action-70? 18:56:08 ACTION-70 -- Andrei Popescu to add use cases from F2F to V2 spec -- due 2010-11-11 -- OPEN 18:56:08 http://www.w3.org/2008/geolocation/track/actions/70 18:56:34 action-90? 18:56:34 ACTION-90 -- Andrei Popescu to clarify with hixie what the Geolocation spec should say about stopping watchPosition processes on document unload -- due 2011-09-14 -- OPEN 18:56:34 http://www.w3.org/2008/geolocation/track/actions/90 18:59:27 -> http://lists.w3.org/Archives/Public/public-geolocation/2011Oct/0013.html Don's questions 19:00:50 don: We don't say anything about data format in XML for instance. It's not covered here? 19:00:58 andreip: I think there are other schemas that already include lat/lng. 19:01:28 matt: There's geoRSS too. 19:02:03 don: What discussions have occurred around altitude? 19:02:10 andreip: We had the skiing use case. 19:03:01 andreip: It's in the spec. 19:03:03 don: OK, thank you. 19:03:21 don: [[PositionError interface is pretty terse, any intentions regarding representation of positional uncertainty? It remains possible for GPS precision to vary widely.]] 19:03:37 don: Think of conditional location. 19:03:50 don: Altitude accuracy, location accuracy is just a radius? 19:03:53 andreip: Yes. 19:04:09 steveblock: We don't make any effort to say why an error occurred because we set out to be source agnostic. 19:04:33 I would like to propose a new theme such as usage of geolocation for non-programmer not API-based geolocation. Probably it might be generic element or property or IRI for HTML5, SVG and CSS etc. 19:04:34 don: And other ellipsoids was just impractical? 19:04:37 steveblock: Right. 19:04:54 don: Open source impls? 19:05:00 andreip: Chromium and Firefox. 19:05:12 ACTION: Matt to update group page to reference new implemenations 19:05:12 Created ACTION-93 - Update group page to reference new implemenations [on Matt Womer - due 2011-11-07]. 19:05:27 don: Java? 19:06:33 matt: The AR CG, I think it is idle right now. 19:07:39 don: External device protocols? 19:07:54 matt: Everyone here is using a remote service, but something that's just a device, not a service? 19:08:17 lbolstad: In Opera we have Unite, we could write a web app in that that gets the device location. 19:08:44 lbolstad: But, our spec says it is independent of how the location is acquired. 19:09:36 [[As mentioned in the initial charter as a potential work item, the Working Group will explore exposing location information via markup or sending it via HTTP headers as non-Recommendation track work.]] 19:09:42 -> http://www.w3.org/2008/geolocation/charter/charter-2 Geo charter 2 19:10:19 matt: Temperature check on those two things, are we still not going to look at those? 19:10:21 19:12:03 -dcheng3 19:12:22 -Sierra 19:12:23 Team_(geolocation)15:42Z has ended 19:12:25 Attendees were Sierra, +49.173.537.aaaa, +49.173.537.aabb, dcheng3 20:07:30 ernesto_jimenez has joined #geolocation 20:08:45 zakim, room for 5 for 4 hours? 20:08:45 I don't understand your question, matt. 20:08:50 zakim, room for 5 for 4h 20:08:50 I don't understand 'room for 5 for 4h', matt 20:08:58 zakim, room for 5 for 240 minutes? 20:08:59 ok, matt; conference Team_(geolocation)20:08Z scheduled with code 26631 (CONF1) for 240 minutes until 0008Z 20:09:38 Team_(geolocation)20:08Z has now started 20:09:44 +tpac 20:10:07 steveblock has joined #geolocation 20:10:42 lbolstad has joined #Geolocation 20:11:07 +dcheng3 20:12:47 andreip has joined #geolocation 20:16:47 andreip has joined #geolocation 20:22:43 Topic: StreamInput 20:23:05 lbolstad: I saw it presented last week at the AR standards meeting. It's a Khronos spec, about having all sensors use one API. 20:23:18 lbolstad: Neil suggested he could stop by. 20:24:04 matt: Is it generically about sensors, or all known ones at this time? 20:24:17 lbolstad: Not sure what the range is per se. Accelerometer and geo were on there. 20:24:23 dougt: Camera, lots of things. 20:24:34 lbolstad: They want them to map to Web standards. 20:24:56 dougt has joined #geolocation 20:27:08 matt: We've got this threshold we have been working around in the group about easy of use and such. Would we ever be interested in working below that threshold and exposing more advanced things, or ceding that ground to other WGs? 20:28:40 issue-81? 20:28:40 ISSUE-81 -- Civic address format transformations -- open 20:28:40 http://www.w3.org/2008/geolocation/track/issues/81 20:28:49 -> http://www.w3.org/2008/geolocation/track/issues/open Open Issues 20:33:18 issue-97? 20:33:18 ISSUE-97 -- Do we need FunctionOnly attribute on the callback interfaces? -- closed 20:33:18 http://www.w3.org/2008/geolocation/track/issues/97 20:35:13 matt: The webidl changed slightly between v1 and v2, callback=functiononly vs just callback. 20:35:31 steveblock: It's a relaxation in v2. 20:36:37 matt: We should be able to go to PR, even without WebIDL ready as a special exception. May stay in PR until WebIDL advances though. 20:39:28 stakagi has joined #geolocation 20:40:42 Topic: Action item review 20:41:18 matt: It feels strange that I might have an address but then there could be a coords with no lat/lng but accuracy could be there? 20:41:21 steveblock: Yes. 20:41:46 dougt: Do we want to make note of this stuff in the spec? 20:42:02 dougt: Missing fields in address could imply accuracy. 20:42:06 http://www.w3.org/wiki/GeoOnion 20:43:26 matt: It wasn't obvious to me that accuracy from coords could be applied on address. 20:43:31 steveblock: We could make that clear. 20:43:51 dougt: It seems weird that we would put that in the spec. In reality you'll see lat/lng/accuracy and an address. 20:44:05 dougt: You probably wouldn't have an accuracy on the civic address from the location provider. 20:44:28 steveblock: It doesn't hurt to say that, does it? 20:44:33 dougt: No, you could spec. 20:46:37 s/spec/put it in the spec/ 20:46:39 ACTION-59? 20:46:39 ACTION-59 -- Lars Erik Bolstad to ask RBarnes about civic address accuracy -- due 2009-11-10 -- OPEN 20:46:39 http://www.w3.org/2008/geolocation/track/actions/59 20:48:04 dougt: If I pass requiredcoords to false, does that mean every attribute in the coords structure is optional? 20:48:06 steveblock: Yes. 20:48:13 dougt: So you can have a state where you just return lat? 20:48:16 I think that the meaning of this definition (Geo Onion) is being able to introduce an enumeration type into a accuracy. 20:48:16 steveblock: Yes, or accuracy. 20:50:07 andreip: But the grouping implies the accuracy is for the coords. 20:50:33 steveblock: Speed and address are useful too. We just didn't break it out. 20:50:48 andreip: We could pull speed out and deprecate it. Can we deprecate them? 20:50:58 dougt: We could, not remove them, just deprecate them and duplicate. 20:51:08 steveblock: Is it worth adding a deprecated field to the spec? 20:51:15 dougt: It's not especially when it's not hooked up to anything. 20:51:27 steveblock: We need to decide if we want accuracy and such to just the coordinates or the concept of the location. 20:51:31 steveblock: I assumed the latter. 20:51:48 dougt: If you mean address that applies to the address object, you promote it up to timestamp. 20:52:39 dougt: We could pull them all out. 20:52:50 andreip: Let's just limit it to accuracy for now. 20:54:19 andreip: Speed by itself stands, accuracy by itself is meaningless. 20:54:29 lbolstad: How useful is it to have accuracy related to an address? 20:54:39 andreip: You could still display that address and display a circle around it. 20:54:50 dougt: What does it mean to give a zip code and an accuracy of 10km. 20:55:01 s/km/km?/ 20:55:03 andreip: I don't know. 20:55:51 steveblock: Accuracy distinguishes an important distinction in a civic address. Conceptually if you knew you were in a circle of 10km, and you could be absolutely sure you're in there, unlike accuracy on a zipcode. 20:56:08 lbolstad: Implicit in the dropped fields, right? 20:56:37 steveblock: No, you could say you're in the UK with an accuracy of 10km but be in the North Sea. 20:56:39 andreip: In practice you wouldn't. 20:56:58 lbolstad: If there is an application that wants to know the location, but chooses to request the address but not coords, isn't it so that the number of populated fields in this object pretty much gives you the accuracy. 20:57:03 dougt: That's what we've been working on. 20:57:14 steveblock: That's a reasonable assumption, but doesn't have to be the case. 20:58:10 steveblock: You could use an address to define a point, and then accuracy to define the bounds. 21:02:44 matt: If we leave it as accuracy is just on lat/lng and you request an address can the developer know anything about the accuracy? 21:02:56 steveblock: We should say something about not returning an accuracy on null lat/lng. 21:04:00 ACTION: steveblock to write new text to disallow just accuracy or just lat or just lng 21:04:00 Created ACTION-94 - Write new text to disallow just accuracy or just lat or just lng [on Stephen Block - due 2011-11-07]. 21:05:18 steveblock: When requireCoords is true, we should restrict it. 21:05:29 dougt: Why not? You could have rings. 21:06:08 steveblock: We've agreed to keep accuracy as just lat/lng. In terms of the three, we are saying if ... 21:06:37 dougt: This would be so much easier if we factor it out and deprecate the old stuff. 21:06:39 steveblock: To have accuracy you have to have lat/lng. 21:06:55 andreip: Just invoke the error callback. 21:07:01 steveblock: but you could have just an address. 21:09:49 ACTION-94? 21:09:50 ACTION-94 -- Stephen Block to write new text to disallow just accuracy or just lat or just lng -- due 2011-11-07 -- OPEN 21:09:50 http://www.w3.org/2008/geolocation/track/actions/94 21:10:00 ACTION-61? 21:10:00 ACTION-61 -- Matt Womer to follow up with erik wilde about other location representations -- due 2009-11-10 -- OPEN 21:10:00 http://www.w3.org/2008/geolocation/track/actions/61 21:10:09 close ACTION-61 21:10:10 ACTION-61 Follow up with erik wilde about other location representations closed 21:11:04 action-65? 21:11:04 ACTION-65 -- Andrei Popescu to investigate what other APIs do on exceptions that aren't geo specific -- due 2010-11-11 -- OPEN 21:11:04 http://www.w3.org/2008/geolocation/track/actions/65 21:11:09 andreip: We don't throw exceptions. 21:11:39 dougt: We throw programmatic errors, e.g. if wrong number of parameters are passed. 21:11:50 andreip: We only throw a type error and match the IDL. 21:13:16 close ACTION-65 21:13:16 ACTION-65 Investigate what other APIs do on exceptions that aren't geo specific closed 21:13:38 ACTION-75? 21:13:38 ACTION-75 -- Andrei Popescu to update address field to RFC mapping and add it to spec -- due 2010-11-11 -- OPEN 21:13:38 http://www.w3.org/2008/geolocation/track/actions/75 21:14:07 ISSUE-90? 21:14:07 ISSUE-90 -- How frequently should the devicemotion event be fired? -- closed 21:14:07 http://www.w3.org/2008/geolocation/track/issues/90 21:15:55 ernesto_jimenez: Talking with Robin he seems okay with us not being aligned. 21:16:06 lbolstad: Some others though said they thought it was stupid to not align. 21:16:37 ernesto_jimenez: The origin for the addresses are different, and the use cases are different. 21:16:44 ernesto_jimenez: In DAP in the ContactsAPI, we're talking about user input. In geo it's from a geocoded. 21:17:11 ernesto_jimenez: There's not much sense of imposing a format in DAP. Some are even saying not have another format but dump everything. 21:17:20 ernesto_jimenez: Robin and I agree that there's no need to align. 21:17:53 lbolstad: This came internally and from some twitter messages. 21:21:52 -dcheng3 21:22:33 +dcheng3 21:23:03 http://my.opera.com/karlcow/blog/2011/06/29/two-apis-for-address 21:24:01 dougt: We got some feedback about this, saying we could do better. So far, no one has proven it. 21:25:10 steveblock_ has joined #geolocation 21:25:55 lbolstad: We've got nothing left on v2 issues then? 21:26:00 dougt: Yes, we're closing the two. 21:26:08 ACTION-90? 21:26:08 ACTION-90 -- Andrei Popescu to clarify with hixie what the Geolocation spec should say about stopping watchPosition processes on document unload -- due 2011-09-14 -- OPEN 21:26:08 http://www.w3.org/2008/geolocation/track/actions/90 21:31:35 -> http://dev.w3.org/html5/spec/Overview.html#unloading-documents Unloading documents 21:31:51 -dcheng3 21:32:27 +dcheng3 21:48:00 -dcheng3 21:48:01 -tpac 21:48:01 Team_(geolocation)20:08Z has ended 21:48:02 Attendees were tpac, dcheng3 22:07:19 stakagi has joined #geolocation 22:08:47 Topic: Khronos Group update 22:09:04 Neil: Khronos Group has been working on some sensor APIs. 22:09:15 Neil: We've got a lot of insight into sensor APIs. 22:09:48 lbolstad has joined #Geolocation 22:10:04 Ian_Cheng: Sensor Fusion is about getting data. Jim has been working on our code as an app. 22:10:43 Jim_Steele: StreamInput is the way we enforce an API for Sensor Fusion. Android has done a good job of putting in virtual sensor for instance. 22:10:57 Jim: (shows example Android app) 22:11:23 Jim: (demo has a dot representing heading and it's jumping around all over the place) 22:11:51 Jim: (Blue arrow has 9 axis fusion of sensors together, moves much smoother and more reactive) 22:12:16 Jim: There's not much in terms of mobile standards about how you'll fuse the sensors together. 22:12:31 Jim: Example, walking in an elevator, I want to know when a user exits an elevator for a mall map app. 22:13:09 Jim: (Puts phone near tablet representing magnets of elevator, red dot goes jumping around) 22:13:59 Jim: So we can get sensors and raw values and then interpret that for what the user wants. They don't want to know if there's a magnetic field around, they just want to know what direction someone is pointing. 22:14:49 Jim: Right now we're using 9 axis, gyro uses 5ma all the time. accel and mag are very low power. 22:15:08 Jim: But you don't get as accurate a reading. Turn off the gyro and the fusion is lagging the red dot. 22:15:22 Jim: But if the app doesn't care about extra fast updates, then there's no reason to burn battery on gyro. 22:15:36 Jim: "Standing still, turn off gyro. Move, turn it on." 22:16:37 Jim: Being able to switch between two algorithms that are redundant, maybe different accuracy in different regimes, and different power usages is good. 22:16:45 Jim: Sensors can tell you location using dead reckoning, but that diverges over time. 22:17:59 Jim: You'll need to combine GPS with wifi, it'd be a huge power savings to just get GPS every one minute when wifi is good. 22:17:59 andreip: Are you providing the algorithms? 22:18:17 Jim: Yes. We don't care about the different sensors. 22:18:59 Jim: We'd like an open standard so app developers can figure out things like I'm in an elevator. 22:19:20 Jim: Thinking APIs at the Android java level and Metro API level. 22:19:37 steveblock: ?? 22:19:51 Jim: We see developers looking at tradeoffs: high accuracy vs power. 22:20:40 andreip: So this is open source? 22:20:58 Jim: We've got things we could open source. I'm looking to emphasize ?? and mobile power use. 22:21:07 Jim: Doing the whole reference design has let us hone in on problems. 22:21:34 Ian: What we've had to resolve immediately was hardware fragmentation, even on same chipset. Time sync is the next thing they'll put their heads around. 22:21:50 Ian: We're lucky if all of the sensors are synchronized, for the most part they are not. Then, how do you synch with a camera and microphone? 22:21:59 andreip: Where do you see the algorithms going? 22:22:23 Jim: Right above the kernel. The interface is open and Android and Windows 8 both have 3rd party sensor stuff. 22:23:09 Jim: New Nexus has 10 axis, including pressure. That might think we jumped a floor when HVAC turns on, but accel tells us we didn't move. 22:23:25 don: Common filters? 22:23:32 Jim: Yes, somewhat?? 22:23:37 steveblock: What timestep? 22:24:13 Jim: Developer can set. 100hz, but if you're using it for say updates by user motion you could do it at 12hz. 22:24:22 andreip: You run the hardware all the time, just in case? 22:24:31 Jim: No, but we could imagine a future where you'd want to track movement all the time. 22:24:58 Jim: Our resource manager can turn them on in 10ms, or one sample. Accel takes a bit longer, but we can bridge that with others. 22:25:15 Ian: If you want initial compass accuracy to be under 3 degrees, you have to have it on and need history for that. 22:26:37 Ian: When we work with sensor hardware makers, our advice is to have smart sensors run as fast as possible, but to do some filter stuff that doesn't leave the chip until higher level resources call for it. 22:26:40 andreip: This is interesting for implementing device orientation. 22:27:06 Neil: Most app developers won't have this level of insight into sensors. If it's too low level, people can do it, but won't. 22:27:27 steveblock: We tried to abstract the sensor details and present that to the web developer. We've had pushback on that though to expose more information. 22:27:35 steveblock: You've shown there is a way to do that and still be useful. 22:27:46 Ian: What if I want a sensor that says "tell me if I'm in a car" -- 22:27:57 Jim: There's no such sensor there, but you could figure it out. 22:28:03 Ian: Runs slowly in the background figuring it out. 22:28:27 Neil: It would enable competition to provide the best possible sensor data processing. 22:29:42 Ian: We find it's easier to provide a minimal level of information. It's almost impossible to second source sensors, whatever you care about isn't in the data sheet, but combining the data together, it becomes feasible. 22:30:25 Zakim has left #geolocation 22:30:35 steveblock: We had comments that a Web app needed direction actions on how to filter. And that only with that direct access could it make reasonable filtering decisions. 22:30:47 Mauro has joined #geolocation 22:30:49 steveblock: We pushed back saying that it's feasible that hardware could filter it. 22:30:59 Neil: The API you currently have is positional? 22:31:08 andreip: Let's go through Orientation. 22:35:28 Jim: You may want to add a fourth vector to handle the singularity problems with euler. 22:35:43 Ian: It makes a difference if you're doing AR, you're holding the phone in that singularity hole. 22:36:37 Don: This is where having an API is useful, where you can fork in the road to have both as part of the API without contradiction. 22:37:00 Don: Maybe rename from alpha/beta/gamma to euler angles to be more intuitive. 22:37:25 steveblock: The angles were used based on common mobile implementations. 22:38:21 steveblock: We don't use straight euler angles. 22:38:32 Jim: The compassneedscalibration event, who decides? open? 22:38:33 lbolstad: Yes. 22:38:49 lbolstad: Spec doesn't say how these values are calculated. 22:39:16 Ian: Is there an API to query whether the device thinks it is calibrated? 22:39:18 lbolstad: No. 22:40:04 Ian: We had a lot of developers come to us ask if there was a way to know if it is calibrated. We know there are issues with calibrating the magnetometer. Perfectly calibrated, but then walk into an elevator and it need calibration. The sensor didn't drift, someone made the wrong decision. 22:40:28 Ian: Should be a way to prompt for a calibration rather than arbitrarily calibrating or not. 22:40:35 andreip: Keep track of when the event is fired. 22:41:01 Ian: If you look at the residual error you can decide if it's needed. Knowing how soon a calibration error occurred may have no relevance on whether it needs one or not. 22:41:37 dougt: The way this event works is that the implementation decides whether we need to calibrate or not. If anything needs to be calibrated the system tells it. 22:41:57 steveblock: We also allow the app to override that. The UA can't force UI on the user, but has a callback that the app can ignore or not. 22:42:37 dougt: I looked at this and thought it would be interesting to know if what we specced out here could be used to produce higher level APIs that Web apps could use. 22:42:50 andreip: In my mind, it's contrary, what we have are abstractions, not individual streams. 22:42:56 dougt: There's an intersection there for sure. 22:43:07 andreip: It would be nice if this was part of all the operating systems as an implementer. 22:43:26 lbolstad: So StreamInput is an API or algorithm? 22:43:33 Jim: No implementation just API. 22:43:47 Jim: Is this extensible to new sensors? 22:44:09 dougt: The point was to have some very easy to use API that was kind of generic, where stuff could be built on top of it. If you had a pressure sensor it'd be another API. 22:44:59 dougt: We haven't exposed the primitives you would need to build an elevator sensor. It would be good to get input on how to do that with our stuff. 22:45:14 Neil: StreamInput is pretty new. We're hoping for end of next year. The idea is to connect sensors to apps. 22:45:37 s/fourth vector/fourth vector of quaternions/ 22:46:06 Neil: The idea is that a sensor graph is created, with connections between the nodes and API, but not the processing. 22:46:45 http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#stream-api 22:47:22 s/end of next year/September of next year/ 22:47:38 Neil: We have critical mass, the guys who made Kinnect and their competitor for instance. 22:48:04 Neil: AR is a prime use case. There's no point in having a camera sensor and a location sensor if you can't sync them together. 22:48:19 Neil: In OpenML(?) we timestamped everything. 22:49:08 Neil: We have a meeting with Jeff later in the week, working with the model we've had with OpenGL/WebGL, where everything is open and free, but find a way to bind it into JavaScript in a productive way. 22:49:20 Neil: We've kind of done that with OpenCL/WebCL, parallel computation. 22:49:54 Neil: If we can work together to make sure your requirements are met by StreamInput, and vice versa, we could make things beter. 22:49:57 s/beter/better/ 22:50:07 dougt: How does a Web app ask the question of "am I in an elevator?" 22:50:19 dougt: I know we can't pass all of the data into script to answer that question at the timescales you need. 22:50:53 Neil: I imagine this would be in the browser in the Web case. From an app point of view the API would say "is there anyone out there that can tell me if I'm in an elevator", and then get a callback when you are. 22:51:11 Neil: Then under the hood, the browser uses StreamInput to connect the pipes. 22:51:24 dougt: And what defines an elevator? StreamInput would know what that meant? 22:51:35 Neil: Yes. We're just defining a list at the moment. Semantic information you can ask for. 22:52:23 dougt: It sounds out of scope for our current work, but sounds interesting. 22:52:42 Neil: Perhaps v2 we can converge. 22:53:16 Ian: We don't have capabilities today necessarily, but we're building towards it. Sensors let you not look at the screen, and they're expensive so they've got to be able to do other things, tell me I'm walking, running, elevator, whatever. 22:53:41 Jim: And it is powerful to have at an HTML5 level too. Talking at Android conference, people wanted it at JavaScript. 22:53:57 dougt: What came up recently was that the API we have is too difficult to understand for most people. 22:54:07 dougt: Having that type of APIs would be of interest to Mozilla. 22:54:48 Neil: The JavaScript impl is interesting. 22:54:55 dougt: 200hz info is too fast for us. 22:55:10 Ian: Processing may happen that fast, but it might just be an update per minute. 22:55:28 dougt: You would hope there would be enough primitives in JavaScript to answer the elevator question. 22:56:41 dougt: We don't necessarily want to bake some of this stuff in the browser. You say there's 100 sensors listed already, but maybe it's the 101st that's the most important. 22:56:55 Jim: The browser can do the power stuff, and the JS library can do the rest? 22:56:56 dougt: Yes. 22:57:42 Ian: For instance to determine whether the device is in the hand requires knowing hand tremor, which requires a lot of data, 200hz, but you might only say you're in the hand once every five minutes. 22:59:06 dougt: It would be useful if you guys could look at the spec for a bit and tell us if it's useful. 22:59:29 s/Ian_Cheng/Ian_Chen/ 23:01:11 http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#video-conferencing-and-peer-to-peer-communication 23:03:06 -> http://dev.w3.org/2011/webrtc/editor/webrtc.html Editor's draft RTC 23:03:23 This spec defines Getting a multimedia stream (video, audio, or both) from local devices 23:03:43 "local device" is local video or microphone 23:04:11 but local device can be accepted jyro gpe etc. 23:04:20 s/gpe/gps/ 23:04:54 s/jyro/gyro/ 23:08:01 andreip: WebRTC says media, just video/audio 23:08:12 ernesto_jimenez: There's the Sensors stuff from DAP. 23:08:23 lbolstad: This is just raw data. 23:08:32 Neil: Could you use that for virtual sensors then? 23:08:33 Jim: Yes. 23:14:19 http://blog.whatwg.org/whatwg-weekly-device-we-hardly-knew-ye-2 23:14:52 >? has been replaced with a Geolocation-style API for requesting user access to local media devices (such as cameras). 23:19:48 Mauro has left #geolocation 23:34:49 lbolstad: We need to talk about agenda for after this f2f. 23:39:21 lbolstad: ADJOURNED! 23:57:04 steveblock has joined #geolocation 23:57:37 Mauro has joined #geolocation