Geolocation Working Group Teleconference -- 04 Nov 2010

<trackbot> Date: 04 November 2010

<matt> Scribe: matt

LarsErik: We don't have many people here tomorrow. We could just do the meeting with the TAG.

-> http://www.w3.org/2008/geolocation/drafts/API/Implementation-Report template IR doc

<scribe> ACTION: Stephen to fill in IR report for Google [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action01]

<trackbot> Created ACTION-62 - Fill in IR report for Google [on Stephen Block - due 2010-11-11].

<scribe> ACTION: Dougt to fill in IR report for fx [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action02]

<trackbot> Created ACTION-63 - Fill in IR report for fx [on Doug Turner - due 2010-11-11].

<scribe> ACTION: LarsErik to fill in IR report for Opera [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action03]

<trackbot> Sorry, couldn't find user - LarsErik

<scribe> ACTION: lbolstad to fill in IR report for Opera [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action04]

<trackbot> Created ACTION-64 - Fill in IR report for Opera [on Lars Erik Bolstad - due 2010-11-11].

Implementation Report

lbolstad: We need to fill in the IR template

matt: I think it's pretty straightforward for the UAs, but the website conformance is a bit tricky.

Andrei: Facebook uses it on their iPhone website

lbolstad: Twitter

Andrei: Google search uses it
... Maps and buzz use it.

<inserted> lbolstad: Flickr

Andrei: Twitter.
... Is it worth pinging the websites themselves?

matt: Probably.

adrianba: They can be done anonymously too. You can say "a website meets the criteria".

-> http://lists.w3.org/Archives/Public/public-geolocation/2010Sep/0019.html

-> http://lists.w3.org/Archives/Public/public-geolocation/2010Sep/0018 exceptions

-> http://dev.w3.org/geo/api/test-suite/t00027.js test 27 src

<scribe> ACTION: Andrei to investigate what other APIs do on exceptions that aren't geo specific [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action05]

<trackbot> Created ACTION-65 - Investigate what other APIs do on exceptions that aren't geo specific [on Andrei Popescu - due 2010-11-11].

adrianba: These exceptions could be specified in WebIDL and if it's underspecified there we should give them feedback on that.

<andreip> glazou: no he is not.

<andreip> np

lbolstad: Any other requirements for that?

-> http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=pr-tr Proposed Rec requirements

matt: Basically review changes, and then review the IR report.

lbolstad: If we can get the IR report done in two weeks we can do the transition call.

-> http://www.w3.org/2008/geolocation/charter/charter-2.html charter 2

adrianba: If the LBS protocol is in scope we will object at the AC review.

matt: Why?

adrianba: We don't think it's something websites should be able to change.
... We don't want the liability to change.

matt: So how would we be able to cope with new location technologies, like indoor location? The providers may change and you may not be able to for say, legal reasons, share that information with a generic location provider.

adrianba: We don't see that as prevalent or a use case that is coming soon.

lbolstad: The background here was that it would be interesting for some institutions, say a University might want to provide location information.

andreip: I'm fine with dropping it, but we need to talk to Doug about it.

adrianba: My proposal would be that if there was interest but not enough resources, we could do it in the new Community Group process and if there is a large amount of interest, then we could transition it to a WG.

<scribe> ACTION: lbolstad to follow up with DougT on dropping Location Provider Protocol from charter [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action06]

<trackbot> Created ACTION-66 - Follow up with DougT on dropping Location Provider Protocol from charter [on Lars Erik Bolstad - due 2010-11-11].

matt: I wasn't going to put in a charter extension to force us to get the 2nd charter nailed down.

adrianba: My proposal would be for an extension to the end of the year, so we can get IR in and move to PR and have the new charter very clear that the V1 is in maintenance.
... And then aim to have the charter presented to the AC.

matt: OK no objections, lets do that.

<scribe> ACTION: matt to get charter extension until the end of the year [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action07]

<trackbot> Created ACTION-67 - Get charter extension until the end of the year [on Matt Womer - due 2010-11-11].

andreip: Any other concerns with the new charter?

adrianba: That was the main one. I don't have specific comments right now. I started the review within Microsoft, but it works much better when I can tell them this is the final charter and we have a date to work towards.
... In general vague charters make it difficult for us to do a good IP review.
... I suspect it's possible when we get into the detailed review that we might ask for a tighter scope on some things. I don't know what those are right now, but that's the process we have.
... We'll provide comments during the AC review. Don't have any big problems with what's there, there might be some minor things.

<lbolstad> Open issues: http://www.w3.org/2008/geolocation/track/issues/open

Open Issues

lbolstad: We should work today to close all V1 open issues.
... Either close them or move them to V2.
... A few weeks ago I went through the issues and tried to close a bunch. We recorded every issue that we found on the mailing list and the f2f meetings. The remaining ones are the ones that aren't obvious to me to close.

issue-34?

<trackbot> ISSUE-34 -- enableHighAccuracy may be an implementation detail -- open

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

lbolstad: We have discussed dropping it, discussed renaming it, etc.

issue-6?

<trackbot> ISSUE-6 -- Is enableHighAccuracy the right naming for this attribute? Should we have it at all? -- open

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

lbolstad: Issue-6 is also related.

andreip: I don't think we can drop it or change the name, it's in all the implementations.

matt: Just for background, who implements it and what do they do?

andreip: Basically the mobile implementations use it. Android does, I think iPhone does as well.

lbolstad: Should it be marked as a dupe then?

<andreip> Issue 6 should be a dupe of issue 34

matt: I'm glad to see it's implemented. Are any websites using it?

andreip: Google goes back and forth on it. I'm not sure what the current state is.

steveblock: With it being an implementation detail, I think the spec says that it's just a hint. I don't think there's value in dropping it.

<andreip> to clarify, that's Google Search on Android

issue-9?

<trackbot> ISSUE-9 -- Restricting API Access -- open

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

andreip: We came up with a different solution to this: in Chrome if an iframe gets access to location, then it's bound to the parent page's permission, so if the same iframe is used in another page it has to request permission again.

adrianba: Does this have to be specified? Or can it be a UA decision.

andreip: It's a UA decision.

<adrianba> Agreed.

andreip: I would close this. Doug raised the idea and didn't implement it.

matt: What does Opera do?

steveblock: The motivation here is that the doc talks about getting permission, but we could have multiple prompts for a web page based on iframes, which could be confusing to a user.

andreip: I'd say close it.

(others concur)

RESOLUTION: ISSUE-34 closed, will be tracked in ISSUE-6
... Close ISSUE-9

<steveblock> to clarify, the particular problem is that users may not even realise that they're granting permission to a domain different from what they see in their URL bar, and that the permission could be re-used by that domain when embedded elsewhere

ISSUE-38?

<trackbot> ISSUE-38 -- Multiple watchPositions simultaneously -- open

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

lbolstad: This goes back to June 2008... very old.

matt: Is having watchPosition with more complex criteria something we want to address in V2?

andreip: We've talked about it and it's easy enough to do such filters in javascript.

matt: I think we have a reasonable level of abstraction actually.

adrianba: We should close it, it's been decided in the spec.

matt: This one in particular I think we have use cases where multiple watches are needed, iframes for instance.

steveblock: And as andreip said it doesn't result in an increase in power consumption for the UAs.

RESOLUTION: Close ISSUE-38

ISSUE-47?

<trackbot> ISSUE-47 -- PositionError message values -- open

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

matt: I noted that we had discussed this but couldn't find the minutes. I think it was at the F2F, but not minuted.

andreip: We did try to put useful information in there, but it's all in English.

steveblock: These are aimed not at the users but at developers.

andreip: I think it says that in the spec.

RESOLUTION: Close ISSUE-47

ISSUE-40?

<trackbot> ISSUE-40 -- Error codes -- open

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

steveblock: This one is very old. I think we've come to the conclusion that yes, timeouts are part of it.

matt: This one is closed.

steveblock: We decided not to bubble up error codes.

andreip: We just have an error for position unavailable.

RESOLUTION: Close ISSUE-40

matt: I just thought back then when we were talking about proximity alarms that "watchPosition" would be a much more natural name for that. Obviously I lost :) Close it.

ISSUE-44?

<trackbot> ISSUE-44 -- watchPosition poorly named -- closed

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

RESOLUTION: Close ISSUE-44

ISSUE-37?

<trackbot> ISSUE-37 -- Distance threshold option to watchPosition -- open

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

matt: I split the original mail into two issues.

lbolstad: Is it useful, should we have it in v2?

adrianba: It's not going to change the power consumption.

matt: I think we're providing just the right level of abstraction, if a library or something wants to provide this functionality they can.

adrianba: We have the right set of primitives.

RESOLUTION: Close ISSUE-37

ISSUE-49?

<trackbot> ISSUE-49 -- Accuracy terminology -- open

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

[[The accuracy and altitudeAccuracy values returned by an implementation should correspond to a 95% confidence level.]]

andreip: We kept accuracy term as that was what most of the native APIs referred to it as.

issue-35?

<trackbot> ISSUE-35 -- getCurrentPosition/watchPosition 1 vs 2 calls -- open

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

-> http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0094.html Andrei's response

RESOLUTION: Close ISSUE-35

ISSUE-51?

<trackbot> ISSUE-51 -- Should the spec mandate a particular privacy-protection UI & mechanism? -- open

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

RESOLUTION: Close ISSUE-51

ISSUE-33?

<trackbot> ISSUE-33 -- Synchronous interface -- open

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

matt: This was back when we had a synchronous version of the methods.

RESOLUTION: Close ISSUE-33

[[The message attribute must return an error message describing the details of the error encountered. This attribute is primarily intended for debugging and developers should not use it directly in their application user interface.]]

-> http://www.w3.org/TR/2010/CR-geolocation-API-20100907/#position_error_interface PositionError Interfaces

-> http://dev.w3.org/geo/api/test-suite/ Test Suite

matt: I think must is right. It should be there.

adrianba: I think it's reasonable to have a debugging interface there.

ISSUE-18?

<trackbot> ISSUE-18 -- Data 'fuzzing' to a bounding box or a municipal region -- open

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

ISSUE-68?

<trackbot> ISSUE-68 -- PositionError.message clarification -- closed

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

RESOLUTION: Close ISSUE-68

ISSUE-32?

<trackbot> ISSUE-32 -- Should heading be included in the API -- open

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

lbolstad: It is included.

RESOLUTION: Close ISSUE-32

ISSUE-31?

<trackbot> ISSUE-31 -- Should velocity be included in the API -- open

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

RESOLUTION: Close ISSUE-31

ISSUE-70?

<trackbot> ISSUE-70 -- Position Logging -- open

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

andreip: This use case is doable with what we've provided.

RESOLUTION: Close ISSUE-70

[[The altitudeAccuracy attribute is specified in meters. If the implementation cannot provide altitude information, the value of this attribute must be null. Otherwise, the value of the altitudeAccuracy attribute must be a non-negative real number.]]

-> http://www.w3.org/TR/2010/CR-geolocation-API-20100907/#coordinates_interface altitudeAccuracy section

RESOLUTION: Close ISSUE-??

ISSUE-30?

<trackbot> ISSUE-30 -- Reuse the DOM -- open

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

andreip: This is a rather early mail. Providing a DOM document for location.

adrianba: They were proposing that the position object would be a document fragment and using the document APIs to extract information from it.

lbolstad: We didn't and aren't planning to.

RESOLUTION: Close ISSUE-30

ISSUE-28?

<trackbot> ISSUE-28 -- Elevation issues with WGS84 -- open

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

steveblock: We specify it's WGS-84 for everything now.

RESOLUTION: Close ISSUE-28

ISSUE-73?

<trackbot> ISSUE-73 -- Getting the user's position vs an arbitrary position -- open

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

andreip: I think we changed the spec to make sure it is possible.

RESOLUTION: Close ISSUE-73

ISSUE-27?

<trackbot> ISSUE-27 -- Geodetic system -- open

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

andreip: We included it in the spec now.

RESOLUTION: Close ISSUE-27

ISSUE-72?

<trackbot> ISSUE-72 -- Multiple altitude measurements -- open

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

andreip: This is because you can measure altitude in different ways.

steveblock: This is similar to using different methods to determine location. The UA just does best effort.

lbolstad: Do we have any implementations that provide this?

andreip: Yes, we do in Android.

steveblock: I don't know any devices that have a barometer, but it'd be up to them to convert it to WGS-84

lbolstad: We left it up to implementations to determine the best value.

steveblock: We decided at the beginning for this to be a high level API and not expose all these details.

RESOLUTION: Close ISSUE-72

ISSUE-26?

<trackbot> ISSUE-26 -- MUST vs SHOULD on privacy/security -- open

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

andreip: I think we actually did that except for a few cases where we didn't.

lbolstad: We did this

RESOLUTION: Close ISSUE-26

ISSUE-29?

<trackbot> ISSUE-29 -- What is a position? -- open

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

lbolstad: That's in scope for v2

RESOLUTION: Close ISSUE-29

steveblock: This is an implementation detail.

matt: The onchange event comes from the initial skeleton proposal.

RESOLUTION: Close ISSUE-24

ISSUE-45?

<trackbot> ISSUE-45 -- clearWatchAll function -- open

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

RESOLUTION: Close ISSUE-45

ISSUE-22?

<trackbot> ISSUE-22 -- onChange vs re-register -- open

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

steveblock: This is looking at DOM events rather than javascript.

andreip: We talked about this extensively and one problem is that we need to be able to pass options.

adrianba: There's been talk about adding parameters to addEventListener
... So this may be addressed elsewhere and we might look at this again in the future if it comes to fruition.

RESOLUTION: Close ISSUE-22

ISSUE-17?

<trackbot> ISSUE-17 -- Client-side logging of what information was given to whom -- open

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

lbolstad: This is another very old one. Keeping a log of what information was given to whom.

adrianba: These are ideas given at the beginning.

lbolstad: Good ideas and discussion points, but outside the scope of the API.

rahul: Like browser history.

lbolstad: Good idea, but not in the API.

RESOLUTION: Close ISSUE-17

ISSUE-75?

<trackbot> ISSUE-75 -- Location providers -- open

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

lbolstad: This is again outside the scope.

ISSUE-83?

<trackbot> ISSUE-83 -- Define "cached position"? -- open

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

steveblock: This really refers to last position.
... I imagine this is addressed in the timeout and max age sections.

[[The API is designed to enable both "one-shot" position requests and repeated position updates, as well as the ability to explicitly query the cached positions. ]]

matt: Is that confusing?
... I'm fine with closing it, it's just that cached is a loaded term.

steveblock: The wording is consistent with what we say in maximumAge.

andreip: That defines what we mean by cached.

RESOLUTION: Close ISSUE-83

ISSUE-82?

<trackbot> ISSUE-82 -- "Repeated" vs. "Asynchronous" updates -- open

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

adrianba: It's in the non-normative introduction.
... It'd be a potential editorial change. I think it's clear enough that it's differentiated between the two.

andreip: We say in the spec what a significant change in position is, it's left to the implementation.

RESOLUTION: Close ISSUE-82

lbolstad: That leaves us with 0 open issues!

*cheer*

Next Face to Face

lbolstad: We've typically had only one meeting per year.
... At least before this meeting, my feeling has been we've been quite efficient when we've met, made good progress, more so than in between. I'd suggest having one face to face at next year's TPAC and also have one more in between, say six months from now.
... Anyone disagree?

rahul: My experience is that F2F meetings are really productive. The question of whether I attend the other meeting for me is up in the air, as I don't really participate. At the TPAC I will probably attend. Just setting expectations.

lbolstad: The milestones in the charter are pretty close.

matt: WIth the exception of orientation, which can't be FPWD until the new charter.

<scribe> ACTION: matt to update milestones section in new charter, particularly orientation [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action08]

<trackbot> Created ACTION-68 - Update milestones section in new charter, particularly orientation [on Matt Womer - due 2010-11-11].

lbolstad: If we follow this, having a meeting around last call and go to CR is good.
... We're depending on someone hosting. China Unicom could potentially host.

zhang-chinaunicom: There's a good chance for China Unicom to get involved in W3C. For China Unicom it's good to be involved in geolocation to know what we could do.

lbolstad: Hearing interest from some in the room here, hopefully Doug or someone from Mozilla too.
... Don't have to decide now. Depending on attendance, we can look at where too.
... Let's discuss this on the member mailing list.

<scribe> ACTION: lbolstad to start discussion of another F2F in six months or so [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action09]

<trackbot> Created ACTION-69 - Start discussion on member mailing list of another F2F in six months or so [on Lars Erik Bolstad - due 2010-11-11].

<adrianba> +1

lbolstad: This would be in the May/June time frame.

Use Cases and Requirements New Documents

andreip: Use cases for orientation are quite straight forward.
... Current V2 is just a copy of V1 wrt UCR.

lbolstad: Let's do civic addressing around 3. I don't think we'll need too much time on orientation.
... RFC-4119, 5139 and 4776 have civic addresses defined.
... I'm assuming the same use cases and requirements for V1 are applicable to V2.

andreip: Yes, we'll have a superset.
... We use that feature to some degree, for instance in Google search. We show your neighborhood.
... On just regular google.com

steveblock: So another use case would be room stuff.

andreip: Form filling.

steveblock: We've been making an effort to use common terms rather than being precise, so I'd say drop civic, make it just "address"

adrianba: There's got to be some mandatory bits, so it can be tested. If you're going to support it you have to do it the right way.

andreip: The use case wouldn't be "get an address", but like "get a pizza".

steveblock: We've mentioned filling in a form, and situations where lat/long doesn't mean anything like a campus. Also search.

andreip: Search relevant to a specific address.

steveblock: You can search for text of the address, rather than have the database tagged with lat/long.

andreip: You can search on google with "near <address>".

lbolstad: "It must be possible to order pizza"

adrianba: The use cases are assistive things, where you don't have to type the data.
... If you phrase it that way then it doesn't have to be a must.

andreip: Indoor positioning could be a use case.

lbolstad: We had a brief talk about this last year.
... Had a lot of discussion around emergency services not being a use case.

<andreip> https://developer.mozilla.org/en/nsIDOMGeoPositionAddress

matt: Looks the same to me.
... Does Andrei want to be editor for v2?

andreip: Sure, but let's have Steve be co-author.

<scribe> ACTION: andreip to add use cases from F2F to V2 spec [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action10]

<trackbot> Created ACTION-70 - Add use cases from F2F to V2 spec [on Andrei Popescu - due 2010-11-11].

lbolstad: What are the new requirements?

matt: Is this the only new feature

andreip: Yes.

sblock2: Oh, but we may add the vertical component of velocity.
... I'm not sure supporting an address is a feature in the requirements.

andreip: The only must we have is lat/long.

adrianba: We could have a should in the requirements.
... These are requirements for the API

sblock2: Right, not on the implementor.
... We might want to change some of the wording. Might change "must provide lat/lng" to providing address or lat/long or both.

adrianba: Make it a requirement to not have to support multiple types of positions.
... The type of position is up to the application.

sblock2: Right but an implementation may support one or the other and be compliant.

andreip: Then we should change the scope as well. It mentions WGS coordinates.

adrianba: The Scope could say "... WGS84 or address".

sblock2: Must provide address in requirements.

adrianba: Another requirement is that the applications can select the type of position.

<scribe> ACTION: andreip to update the scope section to reflect addition of addresses [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action11]

<trackbot> Created ACTION-71 - Update the scope section to reflect addition of addresses [on Andrei Popescu - due 2010-11-11].

<scribe> ACTION: andreip to add the two new requirements talked about at the f2f to the requirement section [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action12]

<trackbot> Created ACTION-72 - to add the two new requirements talked about at the f2f to the requirement section [on Andrei Popescu - due 2010-11-11].

-> http://lists.w3.org/Archives/Public/public-geolocation/2009Nov/0004.html more on fuzzing

andreip: Don't see how this is in the API anyway.

adrianba: Even if you have fuzzing that's secure, you can still be uniquely identified by your movement patterns.

andreip: Fuzzing on a highway with nothing else around, it's still pretty obvious where you are.

lbolstad: Conclusion last year was that it doesn't have any influence on the API itself.
... You can fuzz, but not tell the application.

ACTION-52?

<trackbot> ACTION-52 -- Stephen Block to figure out correct term for 'elevation angle' -- due 2009-11-10 -- OPEN

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

ACTION-46?

<trackbot> ACTION-46 -- Matt Womer to figure out where to put the test files cvs vs wiki, etc -- due 2009-11-09 -- CLOSED

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

sblock2: ISSUE-46 is a dupe of the orientation bug.

ISSUE-67?

<trackbot> ISSUE-67 -- Device orientation -- open

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

<adrianba> ISSUE-46?

<trackbot> ISSUE-46 -- Declination missing from API -- open

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

-> http://lists.w3.org/Archives/Public/public-geolocation/2010Feb/0002.html Angel's thoughts

sblock2: Express velocity as three components: speed on the tangent plane, heading of that speed on the tangent plane, and the vertical speed.

andreip: We have heading today.
... And speed. We're only missing the vertical component.

sblock2: I don't believe the spec says wether it's the velocity or the ...

adrianba: That's an interop ambiguity.

andreip: It says "ground speed"

sblock2: We should change ground speed.

rahul: Is that what you want?
... So on an incline you would have to compute the horiztonal component?

sblock2: Right, so v2 would add the vertical speed.

rahul: What's more useful?
... Magnitude along the plane or speed along the horizontal plane?

sblock2: That's the debate we're having. Speed being the magnitude of horizontal velocity is the speed along the map. Unless you're say, skiing or rock climbing.

adrianba: Hard to see a use case for having the speed be the ... being useful without the vertical component.
... The use case in v1 is mapping. If you did it the other way without the horizontal then you can't do mapping.

sblock2: I think it makes sense that in v1 we were only concerned with speed in the horizontal plane. v2 adds vertical.

adrianba: How common is it that people will actually want the speed and direction of movement? Is it worth having that?

andreip: Could have all three...

sblock2: I don't think there's any need, it's just a few lines of javascript to switch between the two.

adrianba: But it's easy to do and it's just there.

sblock2: If you wanted them to have a speed that is magnitude of velocity, what would you provide?
... all three plus speed?

adrianba: We can bikeshed over the name, but I don't care what it's called. The key is that in v2 it's additive, it adds the vertical component and the calculated component.

sblock2: If you had four components: x,y,z and magnitude.
... As we agreed, lets have v1 be only ?? and have v2 add vertical speed whether we add magniitude as well, who cares.

s/mangniitude/magnitude/

adrianba: So then in ISSUE-7...

<adrianba> 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

action-52?

<trackbot> ACTION-52 -- Stephen Block to figure out correct term for 'elevation angle' -- due 2009-11-10 -- OPEN

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

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

adrianba: Moving it out will make compatibility hard. And then should they be optional or not?

sblock2: I think all of the speed stuff is optional.

adrianba: Should an app be able to decide whether we get speed information?
... In case there is an extra cost.

andreip: In our implementation if you don't do enablehighaccuracy you don't get speed information.
... If you say you want more accurate position you start getting these as well.

sblock2: From a pragmatic point of view is there a device that provides speed that you can turn off that information?
... I thought in GPSes it's there or not.

adrianba: The high accuracy thing is not intuitive.
... Some apps may not care about accuracy, just how fast I'm going.

andreip: It's just extra configuration in the API.

ISSUE-6?

<trackbot> ISSUE-6 -- Is enableHighAccuracy the right naming for this attribute? Should we have it at all? -- open

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

sblock2: I thought we agreed at the last meeting that the right name would have been requireHighAccuracy, but we agreed not to change it.

adrianba: enableHighAccuracy to get speed seems weird.

andreip: And we're adding a separate flag anyway.

adrianba: There may be multiple different aspect of location that you might want to request. lat/long, address, and maybe speed is another. Whatever mechanism we come up with, well, maybe it's an option in that. Keep it extensible in the future, but maybe those three should be three separate things in the request.

andreip: It would make sense to decouple it from lat/long.

sblock2: I'm not sure that follows. While yes, you might want to be able to request each independent of one another, but it's hard to imagine a use case.

adrianba: I didn't see any value to move them into a new thing, they're optional already. I think just in the second version you indicate in the request that you'd like that.

matt: So you might request an address and speed, so you'd get back a coords section that has speed and you'd ignore lat/lng or have it empty?

andreip: Yes.

adrianba: It's ugly, but it's not the ugliest thing.

RESOLUTION: We won't move heading/speed out of Coordinates, but we will add functionality to specifically request that information
... Close ISSUE-7

adrianba: This can be part of the discussion around implementing the requirements.

matt: We have this unstated requirement that we're not going to break V1 applications.

adrianba: It would help to state it.

<scribe> NEW REQUIREMENT: V2 will be backwards compatible with V1

http://www.w3.org/2008/geolocation/track/actions/72

adrianba: Just add it to ACTION-72

<scribe> ACTION: matt to update all references to chairs to reflect Angel leaving [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action13]

<trackbot> Created ACTION-73 - Update all references to chairs to reflect Angel leaving [on Matt Womer - due 2010-11-11].

-> http://geouri.org/ GeoURI

andreip: We don't have a use case for this.

matt: I can't really picture one.

adrianba: Could embed a location in a page and then have the UA take you to a map or something.
... I would suggest closing it saying that API provides the primitives. A library could easily make a transformation from the API to geo strings. If it becomes a popular URI type we could consider adding it to the API.

<adrianba> ISSUE-74?

<trackbot> ISSUE-74 -- Location URIs -- open

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

<tlr> Alexey will be a few minutes late.

<tlr> ok

matt: I always thought proximity alarms would be a popular usage, but I haven't seen it yet. We've got the primitives to do this, I'd say there isn't a pressing need to do it yet, but if it becomes a common thing perhaps.

Luca: I don't see how it'd be possible on the desktop without polling too.

adrianba: It could be useful to be able to navigate to your todo webpage and this be a relatively privacy sensitive way to alert you.
... Maybe we could ask on the list?

matt: We could ask on the DAP list too where there are more scenarios for long running/background apps

adrianba: We could have the choice for having a new doc, or agree to it in v2.
... If we could do it soon, then in the doc, and if it's not high priority we'll close it until later.

<scribe> ACTION: lbolstad to ask geolocation and DAP about proximity use cases and determine if there's a pressing need [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action14]

<trackbot> Created ACTION-74 - Ask geolocation and DAP about proximity use cases and determine if there's a pressing need [on Lars Erik Bolstad - due 2010-11-11].

<adrianba> ISSUE-43?

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

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

ISSUE-67?

<trackbot> ISSUE-67 -- Device orientation -- open

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

sblock2: This spawned the Device Orientation spec. So this should be closed.

ISSUE-65?

<trackbot> ISSUE-65 -- Are there usecases where location information expressed as (lat,long) is enough? -- open

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

sblock2: I think we've proved this with maps.

issue-54?

<trackbot> ISSUE-54 -- Should the spec contain an API for reverse-geocoding? -- open

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

matt: I think he's saying within the API having methods to convert from lat/lng to addresses, not just supporting addresses as a result type.

RESOLUTION: Close ISSUE-54

-> http://lists.w3.org/Archives/Public/public-poiwg/2010Nov/0012.html Facebook Places POI format

<scribe> scribe: andreip

lbolstad: address initially came from Gears as Google Search on mobile used it

andreip: what is now in the spec is based on Alec Berntson's proposal in http://lists.w3.org/Archives/Public/public-geolocation/2009Feb/0000.html

lbolstad: ietf geopriv proposed we adopt 4119 ietf spec instead

lbolsdtad: we actually discussed rfc5139

lbolstad: which adds even more field.

Alexey: are you concerned about the API aspect of address or the underlying format

sblock: just the API

adrianba: what is the point of having an "additionalInformation" field in the Address object if the contents are not specified

lbolstad: another reason listed for using rfc5139 is that some emergency services in US use it

adrianba: do any popular reverse geocoding services on the Web use it?

andreip: not that I know of

<matt> Luca: room, street, city, postal code, floor, corridor, country, subdivision, country code, continent code, placetype (more information that isn't civil address, e.g. a placename, "home", "office")

Luca: but we're not actually using rfc5139

lbolstad: we tried to map from rfc5139 to Alec's proposal
... and additionalInformation was the field that would capture the fields in 5139 that do not directly map to W3C Geolocation Address field

<matt> scribe: Matt

lbolstad: I talked to Mike about this last night, he has some strong feelings about addresses in Japan.
... How widely used is this format?

<MikeSmith> my strong feelings are that we don't need an overengineered set of fields to represent Japanese civic addresses in Japan

Alexey: You're probably asking the wrong person. It's used by HELD, which is part of GeoPRIV. There is a patch for firefox to support HELD.

matt: It's a patch not just an extension?

Alexey: I'm proxying back and forth.

<MikeSmith> I think the simpler set of fields that andreip or whoever specced out last year or year before are adequate

<MikeSmith> I can come by and speak if you all want me to

<alexey> From Richard: Firefox already supports civic addresses, in the limited-field form. It also supports a profile of HELD (only the <Circle> shape) as an option (geo.wifi.protocol=1; geo.wifi.uri=<HELD server>):

<alexey> https://bugzilla.mozilla.org/show_bug.cgi?id=545001

MikeSmith: At the time someone was claiming it couldn't support addresses in Japan. I don't think that's true. There may be other places that have more arcane systems, but in Japan it's fine.

matt: The weird addresses we were discussing was I think Germany where there were ones like: "Next door to School XYZ"

andreip: I don't think we have to cover every case.

adrianba: And they can be coerced into this format.

MikeSmith: What's "additionalInformation"?

lbolstad: A place to put all the other info.

andreip: In retrospect it probably doesn't have to be in there.

steveblock: going back to the campus example, you might have desk number.

MikeSmith: If you look at Japanese addresses, it's typically one string. Within it, there's characters that indicate things like "city", it's almost already marked up.

andreip: Could one take the format we have and make it produce that string?

MikeSmith: Yes. Though there aren't streets. There's street numbers, but not street names.

matt: Just out of curiosity, what is used in place of street names?

MikeSmith: It's understood that there's a number a dash and a number.

matt: So, it's just a number?

MikeSmith: Yeah, it's just a number, like a street address, it's a number in your block.

lbolstad: What about China and Korea?

??: We're changing our address codes actually.

rahul: Is the additionalInformation field enough?

??: It's not enough for us.

s/??: It/Jaehyuk/

s/??: We/Jaehyuk/

andreip: What are we missing?

Jaehyuk: It's very similar to the Japanese system.

MikeSmith: Is it co-centric circles?

Jaehyuk: Yes.

MikeSmith: My point is that in Japan we don't have streets, so you could map things to these fields.

matt: Do you think it's intuitive, that people would map the fields consistently?

MikeSmith: I think so yes, it's unambiguous
... Not sure about China or Korea, but in Tokyo there's exceptions. If you modeled all the exceptions you'd end up with something much bigger.

lbolstad: Looking at Opera offices in Japan: 1-24-12 Meguro, Meguro-ku, Tokyo, 153-0063.

MikeSmith: Meguro is the sub division. Meguro-ku...
... Tokyo is biggest, Meguro-ku is the next biggest, Meguro is smaller, then the 1-24-12

rahul: Maybe house number instead of street, which would be ambiguous as to which location on the street vs the number of the street itself.
... India has two types of addresses, including one that has a number that isn't a street number, but rather a number that's unique in a neighborhood.

-> http://lists.w3.org/Archives/Public/public-geolocation/2009Mar/0043.html Mike's address

<zhang-chinaunicom> In China we just has the street name rather than street number

matt: So how does a person enter a Japanese address in a non-Japanese localized address form? Do they include the markup stuff?

MikeSmith: Typically I think it's just one field in Japan.

Nobu: Typically three fields: street number (1-24-5), city name + area name, building name/room number.
... In Mike's example we'd have: "東京都新宿区" in one field, then "西新宿6-16-11" then "三井ビル605"

[[I think I got that wrong, fix it later @@]]

Nobu: There are 47 prefecture's in Japan.

Steve: Sounds like we need another level of granularity between city and street.

MikeSmith: There is no county-level thing in Japan.

Zhang: Do you have district?

lbolstad: Not in this proposal.

adrianba: For a mailing address you wouldn't put the county in there, but voting or taxes it's relevant.

MikeSmith: In Japan the block would be the last number.
... The three numbers the first one is "chou" or town, the second is like the name of the area, and the third ...

rahul: The objective would be to come up with something that is sufficient for everywhere, but I think the additionalInformation field will help.

<Nobu> an example of Web form for Japnese address: https://store.willcom-inc.com/ec/faces/support/material/entry.jsp?bc=0

Alexey: You don't want to do this country by country. If you want anything that fits the common cases, I would think you'd want to define what's in the field, or add some kind of tagging to it.

MikeSmith: Have the field names in the interface be opaque.

sblock: That's what the RFC did, but it became non-obvious to the JavaScript developer

MikeSmith: The trade off is that it's not obvious to those outside of the English speaking world.

<adrianba> http://msdn.microsoft.com/en-us/library/cc514470.aspx

matt: Maybe we can also preserve the unparsed address.

rahul: In India there's things like "near the Golden Temple".

lbolstad: We could add a "raw" field. And maybe add another level between city and street.

sblock: And rename street number.

<Nobu> s/東京都新宿区/東京都/

adrianba: The Cisco case has the option of detailed information.

<Nobu> s/西新宿6-16-11/6-16-11/

rahul; The additional information is the logical union of all the things we've talked about.

lbolstad: You'd still want raw?

rahul: Yes.

adrianba: Maybe informative text to encourage location providers to specify what it is they'll put in additionalInformation
... Thinking of the Cisco case, they'll have the ability to store say, ethernet addresses, that information may be available based on DHCP, then I can write a Web app to Cisco's customers, if I want that to work interoperably, then that information needs to be consistent.
... So, if we're not going to decide what it should be, we should encourage them to document what it is.

andreip: We should encourage them to populate as much as they can in these fields.

adrianba: And include a suggested mapping to the RFC in an appendix or something.

<scribe> ACTION: andreip to update address field to RFC mapping and add it to spec [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action15]

<trackbot> Created ACTION-75 - Update address field to RFC mapping and add it to spec [on Andrei Popescu - due 2010-11-11].

<Nobu> I agree with Alexey, I think each country has it's own exception, so we had better to define the rule how to map each country's address to determined field.

MikeSmith: District seems better than ward.

adrianba: Should include in the spec what the size of each is relatively.

sblock: Do we need street number and premises?

andreip: Yes, for my case I have "Kings Court" and a street number.

sblock: Which is larger there?

andreip: The list in the spec is in order of decreasing size.

adrianba: I think this is good, we can get an indication in CR if this is working or not.

i/Berntson/Topic: Civic Addresses/

Civic Address Open Issue Review

ISSUE-3

ISSUE-3?

<trackbot> ISSUE-3 -- Exposing civic addresses in the API -- open

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

ISSUE-8?

<trackbot> ISSUE-8 -- Add civic address field(s) for indoor locations -- open

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

sblock: We could respond that this would go in the additionalInformation field

<scribe> ACTION: andreip to make sure additionalInfo and additionalInformation are in sync [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action16]

<trackbot> Created ACTION-76 - Make sure additionalInfo and additionalInformation are in sync [on Andrei Popescu - due 2010-11-11].

rahul: My preference would be for unparsed rather than raw.

ISSUE-78?

<trackbot> ISSUE-78 -- Civic address field name -- open

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

RESOLUTION: Close ISSUE-78

ISSUE-77?

<trackbot> ISSUE-77 -- Civic address format -- open

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

RESOLUTION: Close ISSUE-77

matt: I could see a use case for comparing addresses: "meet me at foo bar"
... But we don't have to address them here. The other address might not even come from this API, and we can't force this format on others.
... I'm just saying a use case does exist, but maybe is out of scope.

lbolstad: I think the comparison case was supporting the use of more fields.

adrianba: The opposite could also be true, the more fields the more chance that they're wrongly used.

andreip: Do you get requests for comparing addresses in your software adrianba?

adrianba: I can ask.
... The one API I showed you is for @@, the other one is just a string, the server side does the parsing to turn it into something useful.

sblock: I'm not sure you can compare without the domain knowledge of the application.
... If you just want the distance, you can take two lat/lng pairs and work it out yourself.

RESOLUTION: Close ISSUE-80

ISSUE-81?

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

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

adrianba: We have to accept that it would be a lossy conversion.

andreip: We'll map the obvious fields to theirs and leave the others blank.

adrianba: If we have the appendix mapping then that's sufficient. Then they can make their own conclusion on how to map back.

sblock: Then we've got our raw field, which should not be lossy.

lbolstad: We have an action from our last f2f asking them to map back.
... In most cases this will be a Web browser hooked into a location provider database, and they typically store addresses in a format like ours.
... Thinking about converting from say a Google address to the RFC format...

adrianba: We have a clear use case for taking an RFC formatted address and making it available in the API, but we don't have a use case for going back.

sblock: I think the Cisco guys were very keen to retrieve an RFC version of the address.

andreip: If someone uses geolocation API and wants to pass information to the emergency services, they only receive the RFC format.

adrianba: That's a risky use case.

<scribe> PENDING RESOLUTION: Close ISSUE-81 once andreip closes associated action.

ISSUE-3?

<trackbot> ISSUE-3 -- Exposing civic addresses in the API -- open

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

RESOLUTION: Close ISSUE-3

ACTION-1?

<trackbot> ACTION-1 -- Lars Erik Bolstad to circulate proposed F2F agenda to member-geolocation -- due 2008-11-17 -- CLOSED

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

ACTION-57?

<trackbot> ACTION-57 -- Andrei Popescu to put field mapping information into the spec -- due 2009-11-10 -- OPEN

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

s/closes associated action/closes ACTION-57/

Open Issues for Device Orientation

sblock: There was a request for absolute property, to say the orientations are absolute.
... You can imagine something being able to detect changes, but not absolute values, they're still useful for say games
... And another for "is compass calibrated".

lbolstad: The use cases for orientation?

andreip: Games

lbolstad: AR

<scribe> ACTION: sblock to update orientation spec with use cases [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action17]

<trackbot> Sorry, couldn't find user - sblock

<scribe> ACTION: steve to update orientation spec with requirements [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action18]

<trackbot> Sorry, couldn't find user - steve

<scribe> ACTION: stephen to update orientation spec with requirements [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action19]

<trackbot> Created ACTION-77 - Update orientation spec with requirements [on Stephen Block - due 2010-11-11].

<scribe> ACTION: stephen to update orientation spec with use cases [recorded in http://www.w3.org/2010/11/04-geolocation-minutes.html#action20]

<trackbot> Created ACTION-78 - Update orientation spec with use cases [on Stephen Block - due 2010-11-11].

matt: Remember there's the W3C meetup tonight: http://www.w3.org/2010/11/TPAC/meetup-Lyon

- DRAFT -

Geolocation Working Group Teleconference
04 Nov 2010

Attendees

Contents

Implementation Report

Open Issues

Next Face to Face

Use Cases and Requirements New Documents

Civic Address Open Issue Review

Open Issues for Device Orientation

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Geolocation Working Group Teleconference 04 Nov 2010

Attendees

Contents

Implementation Report

Open Issues

Next Face to Face

Use Cases and Requirements New Documents

Civic Address Open Issue Review

Open Issues for Device Orientation

Summary of Action Items

Scribe.perl diagnostic output

Geolocation Working Group Teleconference
04 Nov 2010