IRC log of geolocation on 2010-11-04

Timestamps are in UTC.

08:05:52 [RRSAgent]
RRSAgent has joined #geolocation
08:05:52 [RRSAgent]
logging to
08:05:54 [trackbot]
RRSAgent, make logs member
08:05:54 [Zakim]
Zakim has joined #geolocation
08:05:56 [trackbot]
Zakim, this will be GEO
08:05:56 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
08:05:57 [trackbot]
Meeting: Geolocation Working Group Teleconference
08:05:57 [trackbot]
Date: 04 November 2010
08:06:00 [matt]
Scribe: matt
08:06:05 [matt]
08:06:38 [matt]
LarsErik: We don't have many people here tomorrow. We could just do the meeting with the TAG.
08:12:12 [lbolstad]
lbolstad has joined #geolocation
08:12:16 [steveblock]
steveblock has joined #geolocation
08:12:20 [Luca]
Luca has joined #geolocation
08:14:16 [alexey]
alexey has joined #geolocation
08:15:36 [matt]
Present: Lars_Erik, Matt, Andrei, Stephen, Chengyan, Jaehyuk, Luca, Alexi
08:15:43 [matt]
08:17:24 [matt]
matt has changed the topic to: Orientation:"> V1: V2:
08:19:11 [matt]
-> template IR doc
08:20:13 [matt]
Present+ Adrian
08:22:09 [matt]
ACTION: Stephen to fill in IR report for Google
08:22:09 [trackbot]
Created ACTION-62 - Fill in IR report for Google [on Stephen Block - due 2010-11-11].
08:22:16 [matt]
ACTION: Dougt to fill in IR report for fx
08:22:16 [trackbot]
Created ACTION-63 - Fill in IR report for fx [on Doug Turner - due 2010-11-11].
08:22:28 [matt]
ACTION: LarsErik to fill in IR report for Opera
08:22:28 [trackbot]
Sorry, couldn't find user - LarsErik
08:22:45 [matt]
ACTION: lbolstad to fill in IR report for Opera
08:22:46 [trackbot]
Created ACTION-64 - Fill in IR report for Opera [on Lars Erik Bolstad - due 2010-11-11].
08:22:53 [matt]
Topic: Implementation Report
08:23:04 [matt]
lbolstad: We need to fill in the IR template
08:23:24 [matt]
matt: I think it's pretty straightforward for the UAs, but the website conformance is a bit tricky.
08:23:40 [matt]
Andrei: Facebook uses it on their iPhone website
08:23:43 [matt]
lbolstad: Twitter
08:23:46 [matt]
Andrei: Google search uses it
08:23:52 [matt]
Andrei: Maps and buzz use it.
08:24:02 [matt]
Andrei: Twitter.
08:24:56 [BoChen_]
BoChen_ has joined #geolocation
08:26:38 [matt]
Andrei: Is it worth pinging the websites themselves?
08:26:48 [matt]
matt: Probably.
08:27:41 [matt]
adrianba: They can be done anonymously too. You can say "a website meets the criteria".
08:28:24 [matt]
i/Twitter/lbolstad: Flckr/
08:28:28 [matt]
rrsagent, draft minutes
08:28:28 [RRSAgent]
I have made the request to generate matt
08:28:38 [andreip]
andreip has joined #geolocation
08:28:42 [matt]
rrsagent, make logs member
08:30:13 [matt]
08:31:08 [adrianba]
08:32:07 [matt]
-> exceptions
08:33:33 [matt]
-> test 27 src
08:34:31 [glazou]
glazou has joined #geolocation
08:34:33 [matt]
ACTION: Andrei to investigate what other APIs do on exceptions that aren't geo specific
08:34:34 [trackbot]
Created ACTION-65 - Investigate what other APIs do on exceptions that aren't geo specific [on Andrei Popescu - due 2010-11-11].
08:35:22 [matt]
adrianba: These exceptions could be specified in WebIDL and if it's underspecified there we should give them feedback on that.
08:35:36 [andreip]
glazou: no he is not.
08:35:57 [andreip]
08:35:59 [glazou]
glazou has left #geolocation
08:36:13 [matt]
lbolstad: Any other requirements for that?
08:36:19 [matt]
-> Proposed Rec requirements
08:38:10 [matt]
matt: Basically review changes, and then review the IR report.
08:38:23 [matt]
lbolstad: If we can get the IR report done in two weeks we can do the transition call.
08:39:02 [matt]
-> charter 2
08:41:03 [matt]
adrianba: If the LBS protocol is in scope we will object at the AC review.
08:41:06 [matt]
matt: Why?
08:41:30 [matt]
adrianba: We don't think it's something websites should be able to change.
08:41:40 [matt]
adrianba: We don't want the liability to change.
08:43:05 [matt]
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.
08:43:24 [matt]
adrianba: We don't see that as prevalent or a use case that is coming soon.
08:43:52 [matt]
lbolstad: The background here was that it would be interesting for some institutions, say a University might want to provide location information.
08:45:10 [matt]
andreip: I'm fine with dropping it, but we need to talk to Doug about it.
08:45:48 [matt]
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.
08:46:17 [matt]
ACTION: lbolstad to follow up with DougT on dropping Location Provider Protocol from charter
08:46:17 [trackbot]
Created ACTION-66 - Follow up with DougT on dropping Location Provider Protocol from charter [on Lars Erik Bolstad - due 2010-11-11].
08:48:03 [matt]
matt: I wasn't going to put in a charter extension to force us to get the 2nd charter nailed down.
08:48:45 [matt]
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.
08:48:59 [matt]
adrianba: And then aim to have the charter presented to the AC.
08:49:07 [matt]
matt: OK no objections, lets do that.
08:49:15 [matt]
ACTION: matt to get charter extension until the end of the year
08:49:15 [trackbot]
Created ACTION-67 - Get charter extension until the end of the year [on Matt Womer - due 2010-11-11].
08:49:21 [matt]
andreip: Any other concerns with the new charter?
08:49:54 [matt]
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.
08:50:28 [matt]
adrianba: In general vague charters make it difficult for us to do a good IP review..
08:50:30 [matt]
08:50:56 [matt]
adrianba: 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.
08:51:45 [matt]
adrianba: We'll provide comments during the AC review. Don't have any big problems with what's there, there might be some minor things.
08:56:29 [lbolstad]
Open issues:
08:56:33 [matt]
Topic: Open Issues
08:57:49 [matt]
lbolstad: We should work today to close all V1 open issues.
08:57:53 [matt]
lbolstad: Either close them or move them to V2.
08:58:59 [matt]
lbolstad: 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.
08:59:35 [matt]
08:59:35 [trackbot]
ISSUE-34 -- enableHighAccuracy may be an implementation detail -- open
08:59:35 [trackbot]
08:59:58 [matt]
lbolstad: We have discussed dropping it, discussed renaming it, etc.
09:00:05 [matt]
09:00:05 [trackbot]
ISSUE-6 -- Is enableHighAccuracy the right naming for this attribute? Should we have it at all? -- open
09:00:05 [trackbot]
09:00:11 [matt]
lbolstad: Issue-6 is also related.
09:00:34 [matt]
andreip: I don't think we can drop it or change the name, it's in all the implementations.
09:01:16 [matt]
matt: Just for background, who implements it and what do they do?
09:01:33 [matt]
andreip: Basically the mobile implementations use it. Android does, I think iPhone does as well.
09:01:43 [matt]
lbolstad: Should it be marked as a dupe then?
09:01:49 [matt]
Present+ Rahul
09:02:18 [andreip]
Issue 6 should be a dupe of issue 34
09:02:46 [matt]
matt: I'm glad to see it's implemented. Are any websites using it?
09:03:02 [matt]
andreip: Google goes back and forth on it. I'm not sure what the current state is.
09:03:40 [matt]
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.
09:04:05 [andreip]
to clarify, that's Google Search on Android
09:05:03 [matt]
09:05:03 [trackbot]
ISSUE-9 -- Restricting API Access -- open
09:05:03 [trackbot]
09:06:44 [matt]
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.
09:07:00 [matt]
adrianba: Does this have to be specified? Or can it be a UA decision.
09:07:04 [matt]
andreip: It's a UA decision.
09:07:36 [adrianba]
09:09:04 [matt]
andreip: I would close this. Doug raised the idea and didn't implement it.
09:09:27 [matt]
matt: What does Opera do?
09:10:10 [adrianba]
rrsagent, make minutes
09:10:10 [RRSAgent]
I have made the request to generate adrianba
09:11:08 [matt]
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.
09:11:34 [matt]
andreip: I'd say close it.
09:11:37 [matt]
(others concur)
09:12:20 [rahul]
rahul has joined #geolocation
09:12:22 [matt]
RESOLUTION: ISSUE-6 closed, will be tracked in ISSUE-34
09:12:36 [matt]
09:12:46 [adrianba]
s/ISSUE-6 closed, will be tracked in ISSUE-34/ISSUE-34 closed, will be tracked in ISSUE-6/
09:13:29 [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
09:13:30 [matt]
09:13:30 [trackbot]
ISSUE-38 -- Multiple watchPositions simultaneously -- open
09:13:30 [trackbot]
09:17:26 [matt]
lbolstad: This goes back to June 2008... very old.
09:17:41 [matt]
matt: Is having watchPosition with more complex criteria something we want to address in V2?
09:17:53 [matt]
andreip: We've talked about it and it's easy enough to do such filters in javascript.
09:18:05 [matt]
matt: I think we have a reasonable level of abstraction actually.
09:18:14 [matt]
adrianba: We should close it, it's been decided in the spec.
09:19:12 [matt]
matt: This one in particular I think we have use cases where multiple watches are needed, iframes for instance.
09:19:27 [matt]
steveblock: And as andreip said it doesn't result in an increase in power consumption for the UAs.
09:19:49 [matt]
09:20:10 [matt]
09:20:10 [trackbot]
ISSUE-47 -- PositionError message values -- open
09:20:10 [trackbot]
09:21:10 [matt]
matt: I noted that we had discussed this but couldn't find the minutes. I think it was at the F2F, but not minuted.
09:21:25 [matt]
andreip: We did try to put useful information in there, but it's all in English.
09:21:32 [matt]
steveblock: These are aimed not at the users but at developers.
09:21:40 [matt]
andreip: I think it says that in the spec.
09:22:23 [matt]
matt has changed the topic to: Orientation:"> V1: V2:
09:22:31 [matt]
09:22:54 [matt]
09:22:54 [trackbot]
ISSUE-40 -- Error codes -- open
09:22:54 [trackbot]
09:23:26 [matt]
steveblock: This one is very old. I think we've come to the conclusion that yes, timeouts are part of it.
09:25:31 [matt]
matt: This one is closed.
09:25:45 [matt]
steveblock: We decided not to bubble up error codes.
09:26:44 [matt]
andreip: We just have an error for position unavailable.
09:26:50 [matt]
09:27:38 [matt]
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.
09:27:47 [matt]
09:27:47 [trackbot]
ISSUE-44 -- watchPosition poorly named -- closed
09:27:47 [trackbot]
09:27:49 [matt]
09:27:55 [matt]
09:27:55 [trackbot]
ISSUE-37 -- Distance threshold option to watchPosition -- open
09:27:55 [trackbot]
09:28:22 [matt]
matt: I split the original mail into two issues.
09:29:05 [matt]
lbolstad: Is it useful, should we have it in v2?
09:29:13 [matt]
adrianba: It's not going to change the power consumption.
09:29:48 [matt]
matt: I think we're providing just the right level of abstraction, if a library or something wants to provide this functionality they can.
09:29:54 [matt]
adrianba: We have the right set of primitives.
09:30:02 [matt]
09:30:39 [matt]
09:30:39 [trackbot]
ISSUE-49 -- Accuracy terminology -- open
09:30:39 [trackbot]
09:31:32 [matt]
[[The accuracy and altitudeAccuracy values returned by an implementation should correspond to a 95% confidence level.]]
09:31:56 [matt]
andreip: We kept accuracy term as that was what most of the native APIs referred to it as.
09:32:45 [matt]
09:32:45 [trackbot]
ISSUE-35 -- getCurrentPosition/watchPosition 1 vs 2 calls -- open
09:32:45 [trackbot]
09:34:04 [matt]
-> Andrei's response
09:35:01 [matt]
09:35:25 [matt]
09:35:25 [trackbot]
ISSUE-51 -- Should the spec mandate a particular privacy-protection UI & mechanism? -- open
09:35:25 [trackbot]
09:36:39 [matt]
09:37:32 [matt]
09:37:32 [trackbot]
ISSUE-33 -- Synchronous interface -- open
09:37:32 [trackbot]
09:37:52 [matt]
matt: This was back when we had a synchronous version of the methods.
09:38:01 [matt]
09:38:39 [matt]
[[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.]]
09:39:02 [matt]
-> PositionError Interfaces
09:39:38 [matt]
-> Test Suite
09:43:52 [matt]
matt: I think must is right. It should be there.
09:44:07 [matt]
adrianba: I think it's reasonable to have a debugging interface there.
09:46:58 [matt]
09:46:58 [trackbot]
ISSUE-18 -- Data 'fuzzing' to a bounding box or a municipal region -- open
09:46:58 [trackbot]
09:47:23 [matt]
09:47:23 [trackbot]
ISSUE-68 -- PositionError.message clarification -- closed
09:47:23 [trackbot]
09:47:28 [matt]
10:16:48 [andreip]
andreip has joined #geolocation
10:17:36 [Zakim]
Zakim has left #geolocation
10:19:31 [adrianba]
adrianba has joined #geolocation
10:19:33 [matt]
10:19:33 [trackbot]
ISSUE-32 -- Should heading be included in the API -- open
10:19:33 [trackbot]
10:19:58 [matt]
lbolstad: It is included.
10:20:03 [matt]
10:20:22 [matt]
10:20:22 [trackbot]
ISSUE-31 -- Should velocity be included in the API -- open
10:20:22 [trackbot]
10:20:54 [matt]
10:21:37 [matt]
10:21:37 [trackbot]
ISSUE-70 -- Position Logging -- open
10:21:37 [trackbot]
10:23:30 [matt]
andreip: This use case is doable with what we've provided.
10:23:34 [matt]
10:24:26 [matt]
[[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.]]
10:25:02 [matt]
-> altitudeAccuracy section
10:25:23 [matt]
10:25:30 [matt]
10:25:30 [trackbot]
ISSUE-30 -- Reuse the DOM -- open
10:25:30 [trackbot]
10:25:54 [matt]
andreip: This is a rather early mail. Providing a DOM document for location.
10:26:23 [matt]
adrianba: They were proposing that the position object would be a document fragment and using the document APIs to extract information from it.
10:27:28 [matt]
lbolstadt: We didn't and aren't planning to.
10:27:36 [matt]
10:27:47 [matt]
10:27:57 [matt]
10:27:57 [trackbot]
ISSUE-28 -- Elevation issues with WGS84 -- open
10:27:57 [trackbot]
10:29:07 [matt]
steveblock: We specify it's WGS-84 for everything now.
10:29:16 [matt]
10:29:19 [matt]
10:29:19 [trackbot]
ISSUE-73 -- Getting the user's position vs an arbitrary position -- open
10:29:19 [trackbot]
10:29:34 [matt]
andreip: I think we changed the spec to make sure it is possible.
10:30:00 [matt]
10:30:06 [matt]
10:30:06 [trackbot]
ISSUE-27 -- Geodetic system -- open
10:30:06 [trackbot]
10:30:13 [matt]
andreip: We included it in the spec now.
10:30:18 [matt]
10:30:31 [matt]
10:30:31 [trackbot]
ISSUE-72 -- Multiple altitude measurements -- open
10:30:31 [trackbot]
10:30:54 [matt]
andreip: This is because you can measure altitude in different ways.
10:31:11 [matt]
steveblock: This is similar to using different methods to determine location. The UA just does best effort.
10:31:30 [matt]
lbolstad: Do we have any implementations that provide this?
10:31:34 [matt]
andreip: Yes, we do in Android.
10:31:56 [matt]
steveblock: I don't know any devices that have a barometer, but it'd be up to them to convert it to WGS-84
10:32:17 [matt]
lbolstad: We left it up to implementations to determine the best value.
10:32:43 [matt]
steveblock: We decided at the beginning for this to be a high level API and not expose all these details.
10:33:09 [matt]
10:34:06 [matt]
10:34:06 [trackbot]
ISSUE-26 -- MUST vs SHOULD on privacy/security -- open
10:34:06 [trackbot]
10:34:19 [matt]
andreip: I think we actually did that except for a few cases where we didn't.
10:35:02 [matt]
lbolstad: We did this
10:35:04 [matt]
10:35:06 [matt]
10:35:06 [trackbot]
ISSUE-29 -- What is a position? -- open
10:35:06 [trackbot]
10:35:33 [matt]
lbolstad; That's in scope for v2
10:35:43 [matt]
10:35:50 [adrianba]
10:36:16 [rahul]
rahul has left #geolocation
10:36:50 [matt]
steveblock: This is an implementation detail.
10:38:57 [matt]
matt: The onchange event comes from the initial skeleton proposal.
10:39:11 [matt]
10:39:17 [matt]
10:39:17 [trackbot]
ISSUE-45 -- clearWatchAll function -- open
10:39:17 [trackbot]
10:39:29 [matt]
10:39:40 [matt]
10:39:40 [trackbot]
ISSUE-22 -- onChange vs re-register -- open
10:39:40 [trackbot]
10:40:05 [matt]
steveblock: This is looking at DOM events rather than javascript.
10:40:52 [matt]
andreip: We talked about this extensively and one problem is that we need to be able to pass options.
10:41:22 [matt]
adrianba: There's been talk about adding parameters to addEventListener
10:41:45 [jorlow]
jorlow has joined #geolocation
10:42:08 [matt]
adrianba: So this may be addressed elsewhere and we might look at this again in the future if it comes to fruition.
10:42:23 [matt]
10:43:51 [matt]
10:43:51 [trackbot]
ISSUE-17 -- Client-side logging of what information was given to whom -- open
10:43:51 [trackbot]
10:44:07 [matt]
lbolstad: This is another very old one. Keeping a log of what information was given to whom.
10:44:24 [matt]
adrianba: These are ideas given at the beginning.
10:44:33 [matt]
lbolstad: Good ideas and discussion points, but outside the scope of the API.
10:45:14 [matt]
rahul: Like browser history.
10:45:23 [matt]
lbolstad: Good idea, but not in the API.
10:45:28 [matt]
10:46:10 [matt]
10:46:13 [trackbot]
ISSUE-75 -- Location providers -- open
10:46:13 [trackbot]
10:47:27 [matt]
lbolstad: This is again outside the scope.
10:47:32 [matt]
10:47:36 [matt]
10:47:36 [trackbot]
ISSUE-83 -- Define "cached position"? -- open
10:47:36 [trackbot]
10:48:02 [matt]
steveblock: This really refers to last position.
10:48:14 [matt]
steveblock: I imagine this is addressed in the timeout and max age sections.
10:49:04 [matt]
[[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. ]]
10:50:16 [matt]
matt: Is that confusing?
10:51:08 [matt]
matt: I'm fine with closing it, it's just that cached is a loaded term.
10:51:42 [matt]
steveblock: The wording is consistent with what we say in maximumAge.
10:51:48 [matt]
andreip: That defines what we mean by cached.
10:52:07 [matt]
10:52:09 [matt]
10:52:09 [trackbot]
ISSUE-82 -- "Repeated" vs. "Asynchronous" updates -- open
10:52:09 [trackbot]
10:53:23 [matt]
adrianba: It's in the non-normative introduction.
10:54:32 [matt]
adrianba: It'd be a potential editorial change. I think it's clear enough that it's differentiated between the two.
10:55:46 [matt]
andreip: We say in the spec what a significant change in position is, it's left to the implementation.
10:55:58 [matt]
10:56:22 [matt]
lbolstad: That leaves us with 0 open issues!
10:56:25 [matt]
10:57:00 [matt]
Topic: Next Face to Face
10:57:10 [matt]
lbolstad: We've typically had only one meeting per year.
10:57:48 [matt]
lbolstad: 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.
10:58:05 [matt]
lbolstad: Anyone disagree?
10:58:44 [matt]
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.
10:59:35 [matt]
lbolstad: The milestones in the charter are pretty close.
10:59:48 [matt]
matt: WIth the exception of orientation, which can't be FPWD until the new charter.
11:00:00 [matt]
ACTION: matt to update milestones section in new charter, particularly orientation
11:00:00 [trackbot]
Created ACTION-68 - Update milestones section in new charter, particularly orientation [on Matt Womer - due 2010-11-11].
11:00:21 [kensaku]
kensaku has joined #geolocation
11:00:35 [matt]
lbolstad: If we follow this, having a meeting around last call and go to CR is good.
11:01:10 [matt]
lbolstad: We're depending on someone hosting. China Unicom could potentially host.
11:01:50 [matt]
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.
11:02:13 [matt]
lbolstad: Hearing interest from some in the room here, hopefully Doug or someone from Mozilla too.
11:02:32 [matt]
lbolstad: Don't have to decide now. Depending on attendance, we can look at where too.
11:02:48 [matt]
lbolstad: Let's discuss this on the member mailing list.
11:03:04 [matt]
ACTION: lbolstad to start discussion of another F2F in six months or so
11:03:04 [trackbot]
Created ACTION-69 - Start discussion of another F2F in six months or so [on Lars Erik Bolstad - due 2010-11-11].
11:03:12 [adrianba]
11:03:14 [matt]
s/discussion/discussion on member mailing list/
11:03:29 [matt]
lbolstad: This would be in the May/June time frame.
11:03:56 [lbolstad]
lbolstad has joined #geolocation
11:04:06 [matt]
rrsagent, draft minutes
11:04:06 [RRSAgent]
I have made the request to generate matt
11:04:19 [matt]
Chair: Lars Erik Bolstad
11:04:26 [matt]
Regrets: Doug
11:05:00 [matt]
Topic: Use Cases and Requirements V2
11:05:04 [matt]
s/V2/New Documents/
11:05:14 [matt]
andreip: Use cases for orientation are quite straight forward.
11:05:20 [matt]
andreip: Current V2 is just a copy of V1 wrt UCR.
11:05:56 [matt]
lbolstad: Let's do civic addressing around 3. I don't think we'll need too much time on orientation.
12:26:13 [andreip]
andreip has joined #geolocation
12:31:41 [Luca]
Luca has joined #geolocation
12:31:58 [kensaku]
kensaku has joined #geolocation
12:34:24 [Jaehyuk]
Jaehyuk has joined #GeoLocation
12:36:34 [lbolstad]
lbolstad has joined #geolocation
12:40:26 [jorlow]
jorlow has joined #geolocation
12:40:51 [matt]
rrsagent, draft minutes
12:40:51 [RRSAgent]
I have made the request to generate matt
12:41:33 [adrianba]
adrianba has joined #geolocation
12:44:36 [matt]
lbolstad: RFC-4119, 5139 and 4776 have civic addresses defined.
12:45:07 [matt]
lbolstad: I'm assuming the same use cases and requirements for V1 are applicable to V2.
12:45:14 [matt]
andreip: Yes, we'll have a superset.
12:45:32 [matt]
andreip: We use that feature to some degree, for instance in Google search. We show your neighborhood.
12:45:44 [matt]
andreip: On just regular
12:46:44 [matt]
steveblock: So another use case would be room stuff.
12:48:12 [matt]
andreip: Form filling.
12:49:54 [matt]
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"
12:50:52 [matt]
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.
12:51:04 [matt]
andreip: The use case wouldn't be "get an address", but like "get a pizza".
12:51:23 [matt]
steveblock: We've mentioned filling in a form, and situations where lat/long doesn't mean anything like a campus. Also search.
12:51:35 [matt]
andreip: Search relevant to a specific address.
12:51:54 [matt]
steveblock: You can search for text of the address, rather than have the database tagged with lat/long.
12:52:19 [matt]
andreip: You can search on google with "near <address>".
12:53:03 [matt]
lbolstad: "It must be possible to order pizza"
12:53:08 [sblock2]
sblock2 has joined #geolocation
12:53:55 [matt]
adrianba: The use cases are assistive things, where you don't have to type the data.
12:54:09 [matt]
adrianba: If you phrase it that way then it doesn't have to be a must.
12:55:35 [matt]
andreip: Indoor positioning could be a use case.
12:56:17 [matt]
lbolstad: We had a brief talk about this last year.
12:56:31 [matt]
lbolstad: Had a lot of discussion around emergency services not being a use case.
12:57:31 [andreip]
12:58:52 [matt]
matt: Looks the same to me.
12:59:30 [matt]
matt: Does Andrei want to be editor for v2?
12:59:30 [Nobu]
Nobu has joined #geolocation
12:59:37 [matt]
andreip: Sure, but let's have Steve be co-author.
12:59:55 [matt]
ACTION: andreip to add use cases from F2F to V2 spec
12:59:55 [trackbot]
Created ACTION-70 - Add use cases from F2F to V2 spec [on Andrei Popescu - due 2010-11-11].
13:00:23 [matt]
lbolstad: What are the new requirements?
13:00:47 [zhang-chinaunicom]
zhang-chinaunicom has joined #geolocation
13:00:58 [matt]
matt: Is this the only new feature
13:01:01 [matt]
andreip: Yes.
13:01:10 [matt]
sblock2: Oh, but we may add the vertical component of velocity.
13:01:10 [kensaku]
kensaku has joined #geolocation
13:02:01 [matt]
sblock2: I'm not sure supporting an address is a feature in the requirements.
13:02:06 [matt]
andreip: The only must we have is lat/long.
13:02:14 [matt]
adrianba: We could have a should in the requirements.
13:02:35 [matt]
adrianba: These are requirements for the API
13:02:39 [matt]
sblock2: Right, not on the implementor.
13:03:02 [matt]
sblock2: We might want to change some of the wording. Might change "must provide lat/lng" to providing address or lat/long or both.
13:03:15 [matt]
adrianba: Make it a requirement to not have to support multiple types of positions.
13:03:30 [matt]
adrianba: The type of position is up to the application.
13:04:00 [matt]
sblock2: Right but an implementation may support one or the other and be compliant.
13:04:26 [matt]
andreip: Then we should change the scope as well. It mentions WGS coordinates.
13:05:26 [matt]
adrianba: The Scope could say "... WGS84 or address".
13:05:52 [matt]
sblock2: Must provide address in requirements.
13:06:01 [matt]
adrianba: Another requirement is that the applications can select the type of position.
13:06:30 [bochen_]
bochen_ has joined #geolocation
13:06:37 [matt]
ACTION: andreip to update the scope section to reflect addition of addresses
13:06:37 [trackbot]
Created ACTION-71 - Update the scope section to reflect addition of addresses [on Andrei Popescu - due 2010-11-11].
13:06:54 [matt]
ACTION: andreip to add the two new requirements talked about at the f2f to the requirement section
13:06:55 [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].
13:09:22 [matt]
-> more on fuzzing
13:10:01 [matt]
andreip: Don't see how this is in the API anyway.
13:10:52 [matt]
adrianba: Even if you have fuzzing that's secure, you can still be uniquely identified by your movement patterns.
13:11:38 [matt]
andreip: Fuzzing on a highway with nothing else around, it's still pretty obvious where you are.
13:12:39 [matt]
lbolstad: Conclusion last year was that it doesn't have any influence on the API itself.
13:12:47 [matt]
lbolstad: You can fuzz, but not tell the application.
13:13:53 [matt]
13:13:53 [trackbot]
ACTION-52 -- Stephen Block to figure out correct term for 'elevation angle' -- due 2009-11-10 -- OPEN
13:13:53 [trackbot]
13:15:17 [matt]
13:15:17 [trackbot]
ACTION-46 -- Matt Womer to figure out where to put the test files cvs vs wiki, etc -- due 2009-11-09 -- CLOSED
13:15:17 [trackbot]
13:15:33 [matt]
sblock2: Action 46 is a dupe of the orientation bug.
13:15:48 [matt]
13:15:48 [trackbot]
ISSUE-67 -- Device orientation -- open
13:15:48 [trackbot]
13:15:57 [adrianba]
13:15:57 [trackbot]
ISSUE-46 -- Declination missing from API -- open
13:15:57 [trackbot]
13:16:13 [matt]
s/Action 46/ISSUE-46/
13:16:38 [matt]
-> Angel's thoughts
13:17:15 [matt]
sblock2: Express velocity as three components: speed on the tangent plane, heading of that speed on the tangent plane, and the vertical speed.
13:17:19 [matt]
andreip: We have heading today.
13:17:29 [matt]
andreip: And speed. We're only missing the vertical component.
13:17:45 [matt]
sblock2: I don't believe the spec says wether it's the velocity or the ...
13:17:52 [matt]
adrianba: That's an interop ambiguity.
13:17:56 [matt]
andreip: It says "ground speed"
13:18:30 [matt]
sblock2: We should change ground speed.
13:18:39 [matt]
rahul: Is that what you want?
13:19:10 [seungjae]
seungjae has joined #geolocation
13:19:22 [matt]
rahul: So on an incline you would have to compute the horiztonal component?
13:19:24 [matt]
sblock2: Right, so v2 would add the vertical speed.
13:19:26 [matt]
rahul: What's more useful?
13:19:28 [matt]
rahul: Magnitude along the plane or speed along the horizontal plane?
13:20:04 [matt]
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.
13:20:28 [matt]
adrianba: Hard to see a use case for having the speed be the ... being useful without the vertical component.
13:20:53 [matt]
adrianba: The use case in v1 is mapping. If you did it the other way without the horizontal then you can't do mapping.
13:21:17 [matt]
sblock2: I think it makes sense that in v1 we were only concerned with speed in the horizontal plane. v2 adds vertical.
13:21:42 [matt]
adrianba: How common is it that people will actually want the speed and direction of movement? Is it worth having that.
13:21:50 [matt]
13:22:40 [matt]
andreip: Could have all three...
13:22:54 [matt]
sblock2: I don't think there's any need, it's just a few lines of javascript to switch between the two.
13:23:03 [matt]
adrianba: But it's easy to do and it's just there.
13:24:12 [matt]
sblock2: If you wanted them to have a speed that is magnitude of velocity, what would you provide?
13:24:19 [matt]
sblock2: all three plus speed?
13:24:44 [matt]
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.
13:25:05 [matt]
sblock2: If you had four components: x,y,z and magnitude.
13:25:41 [matt]
sblock2: As we agreed, lets have v1 be only ?? and have v2 add vertical speed whether we add magniitude as well, who cares.
13:25:48 [matt]
13:25:57 [matt]
adrianba: So then in ISSUE-7...
13:26:49 [adrianba]
13:26:49 [trackbot]
ISSUE-7 -- Should heading & speed be moved out of the Coordinates interface? -- open
13:26:49 [trackbot]
13:27:37 [matt]
13:27:37 [trackbot]
ACTION-52 -- Stephen Block to figure out correct term for 'elevation angle' -- due 2009-11-10 -- OPEN
13:27:37 [trackbot]
13:28:32 [matt]
13:28:32 [trackbot]
ISSUE-7 -- Should heading & speed be moved out of the Coordinates interface? -- open
13:28:32 [trackbot]
13:29:22 [matt]
adrianba: Moving it out will make compatibility hard. And then should they be optional or not?
13:29:24 [matt]
sblock2: I think all of the speed stuff is optional.
13:29:33 [matt]
adrianba: Should an app be able to decide whether we get speed information?
13:29:38 [matt]
adrianba: In case there is an extra cost.
13:30:16 [matt]
andreip: In our implementation if you don't do enablehighaccuracy you don't get speed information.
13:30:25 [matt]
andreip: If you say you want more accurate position you start getting these as well.
13:30:40 [matt]
sblock2: From a pragmatic point of view is there a device that provides speed that you can turn off that information?
13:30:46 [matt]
sblock2: I thought in GPSes it's there or not.
13:31:00 [matt]
adrianba: The high accuracy thing is not intuitive.
13:31:24 [matt]
adrianba: Some apps may not care about accuracy, just how fast I'm going.
13:31:41 [matt]
andreip: It's just extra configuration in the API.
13:31:43 [matt]
13:31:43 [trackbot]
ISSUE-6 -- Is enableHighAccuracy the right naming for this attribute? Should we have it at all? -- open
13:31:43 [trackbot]
13:32:37 [matt]
sblock2: I thought we agreed at the last meeting that the right name would have been requireHighAccuracy, but we agreed not to change it.
13:32:52 [matt]
adrianba: enableHighAccuracy to get speed seems weird.
13:33:00 [matt]
andreip: And we're adding a separate flag anyway.
13:34:01 [matt]
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.
13:34:10 [matt]
andreip: It would make sense to decouple it from lat/long.
13:34:53 [matt]
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.
13:35:24 [matt]
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.
13:36:39 [matt]
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?
13:36:42 [matt]
andreip: Yes.
13:36:48 [matt]
adrianba: It's ugly, but it's not the ugliest thing.
13:37:36 [matt]
RESOLUTION: We won't move heading/speed out of Coordinates, but we will add functionality to specifically request that information
13:37:49 [matt]
13:38:04 [matt]
13:39:28 [matt]
adrianba: This can be part of the discussion around implementing the requirements.
13:40:04 [matt]
matt: We have this unstated requirement that we're not going to break V1 applications.
13:40:08 [matt]
adrianba: It would help to state it.
13:40:23 [matt]
NEW REQUIREMENT: V2 will be backwards compatible with V1
13:40:54 [matt]
13:41:01 [matt]
adrianba: Just add it to ACTION-72
13:41:26 [matt]
ACTION: matt to update all references to chairs to reflect Angel leaving
13:41:26 [trackbot]
Created ACTION-73 - Update all references to chairs to reflect Angel leaving [on Matt Womer - due 2010-11-11].
13:49:29 [matt]
-> GeoURI
13:53:27 [matt]
andreip: We don't have a use case for this.
13:53:32 [matt]
matt: I can't really picture one.
13:53:51 [matt]
adrianba: Could embed a location in a page and then have the UA take you to a map or something.
13:54:40 [matt]
adrianba: 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.
13:55:23 [matt]
rrsagent, draft minutes
13:55:23 [RRSAgent]
I have made the request to generate matt
13:56:03 [adrianba]
13:56:03 [trackbot]
ISSUE-74 -- Location URIs -- open
13:56:03 [trackbot]
13:59:32 [jorlow]
jorlow has joined #geolocation
13:59:42 [jorlow_]
jorlow_ has joined #geolocation
14:00:50 [tlr]
tlr has joined #geolocation
14:00:58 [tlr]
Alexey will be a few minutes late.
14:03:28 [tlr]
14:03:41 [matt]
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.
14:04:39 [matt]
Luca: I don't see how it'd be possible on the desktop without polling too.
14:05:08 [matt]
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.
14:05:29 [MikeSmith]
MikeSmith has joined #geolocation
14:05:36 [matt]
adrianba: Maybe we could ask on the list?
14:06:12 [matt]
matt: We could ask on the DAP list too where there are more scenarios for long running/background apps
14:06:51 [MikeSmith]
RRSAgent, make minutes
14:06:51 [RRSAgent]
I have made the request to generate MikeSmith
14:06:52 [matt]
adrianba: We could have the choice for having a new doc, or agree to it in v2.
14:07:06 [matt]
adrianba: If we could do it soon, then in the doc, and if it's not high priority we'll close it until later.
14:07:48 [matt]
ACTION: lbolstad to ask geolocation and DAP about proximity use cases and determine if there's a pressing need
14:07:48 [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].
14:07:51 [adrianba]
14:07:51 [trackbot]
ISSUE-43 -- Proximity interface -- open
14:07:51 [trackbot]
14:08:13 [matt]
14:08:13 [trackbot]
ISSUE-67 -- Device orientation -- open
14:08:13 [trackbot]
14:08:42 [matt]
sblock2: This spawned the Device Orientation spec. So this should be closed.
14:09:37 [matt]
14:09:37 [trackbot]
ISSUE-65 -- Are there usecases where location information expressed as (lat,long) is enough? -- open
14:09:37 [trackbot]
14:09:42 [matt]
sblock2: I think we've proved this with maps.
14:13:20 [matt]
14:13:20 [trackbot]
ISSUE-54 -- Should the spec contain an API for reverse-geocoding? -- open
14:13:20 [trackbot]
14:13:40 [matt]
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.
14:13:55 [matt]
14:17:58 [matt]
-> Facebook Places POI format
14:35:41 [andreip]
andreip has joined #geolocation
14:36:36 [Luca]
Luca has joined #geolocation
14:39:00 [matt]
scribe: andreip
14:39:03 [lbolstad]
lbolstad has joined #geolocation
14:39:54 [jorlow]
jorlow has joined #geolocation
14:41:11 [andreip]
lbolstad: address initially came from Gears as Google Search on mobile used it
14:42:52 [andreip]
andreip: what is now in the spec is based on Alec Berntson's proposal in
14:43:29 [andreip]
lbolstad: ietf geopriv proposed we adopt 4119 ietf spec instead
14:43:30 [tlr]
tlr has joined #geolocation
14:44:29 [tlr]
tlr has joined #geolocation
14:44:31 [andreip]
lbolsdtad: we actually discussed rfc5139
14:44:43 [andreip]
lbolstad: which adds even more field.
14:46:13 [andreip]
Alexey: are you concerned about the API aspect of address or the underlying format
14:46:25 [andreip]
sblock: just the API
14:48:34 [andreip]
adrianba: what is the point of having an "additionalInformation" field in the Address object if the contents are not specified
14:50:39 [andreip]
lbolstad: another reason listed for using rfc5139 is that some emergency services in US use it
14:50:53 [andreip]
adrianba: do any popular reverse geocoding services on the Web use it?
14:51:02 [andreip]
andreip: not that I know of
14:51:29 [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")
14:52:00 [andreip]
Luca: but we're not actually using rfc5139
14:52:32 [andreip]
lbolstad: we tried to map from rfc5139 to Alec's proposal
14:53:42 [andreip]
lbolstad: and additionalInformation was the field that would capture the fields in 5139 that do not directly map to W3C Geolocation Address field
14:54:48 [matt]
scribe: Matt
14:55:15 [matt]
lbolstad: I talked to Mike about this last night, he has some strong feelings about addresses in Japan.
14:55:47 [matt]
lbolstad: How widely used is this format?
14:56:13 [MikeSmith]
my strong feelings are that we don't need an overengineered set of fields to represent Japanese civic addresses in Japan
14:56:22 [matt]
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.
14:56:28 [matt]
matt: It's a patch not just an extension?
14:56:54 [matt]
Alexey: I'm proxying back and forth.
14:57:10 [MikeSmith]
I think the simpler set of fields that andreip or whoever specced out last year or year before are adequate
14:57:36 [alexey]
alexey has joined #geolocation
14:57:42 [MikeSmith]
I can come by and speak if you all want me to
14:57:48 [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>):
15:00:00 [alexey]
15:01:07 [matt]
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.
15:02:03 [zhang-chinaunicom]
zhang-chinaunicom has joined #geolocation
15:02:05 [matt]
matt: The weird addresses we were discussing was I think Germany where there were ones like: "Next door to School XYZ"
15:02:14 [matt]
andreip: I don't think we have to cover every case.
15:02:22 [matt]
adrianba: And they can be coerced into this format.
15:02:28 [matt]
MikeSmith: What's "additionalInformation"?
15:02:36 [matt]
lbolstad: A place to put all the other info.
15:02:57 [matt]
andreip: In retrospect it probably doesn't have to be in there.
15:03:21 [matt]
steveblock: going back to the campus example, you might have desk number.
15:04:08 [matt]
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.
15:04:42 [matt]
andreip: Could one take the format we have and make it produce that string?
15:04:57 [matt]
MikeSmith: Yes. Though there aren't streets. There's street numbers, but not street names.
15:05:41 [matt]
matt: Just out of curiosity, what is used in place of street names?
15:06:22 [matt]
MikeSmith: It's understood that there's a number a dash and a number.
15:06:24 [matt]
matt: So, it's just a number?
15:06:26 [matt]
MikeSmith: Yeah, it's just a number, like a street address, it's a number in your block.
15:06:40 [matt]
lbolstad: What about China and Korea?
15:07:15 [matt]
??: We're changing our address codes actually.
15:07:29 [matt]
rahul: Is the additionalInformation field enough?
15:07:35 [matt]
??: It's not enough for us.
15:07:42 [matt]
rrsagent, draft minutes
15:07:42 [RRSAgent]
I have made the request to generate matt
15:08:08 [matt]
s/??: It/Jaehyuk/
15:08:13 [matt]
s/??: We/Jaehyuk/
15:08:20 [matt]
andreip: What are we missing?
15:08:45 [matt]
Jaehyuk: It's very similar to the Japanese system.
15:08:59 [matt]
MikeSmith: Is it co-centric circles?
15:09:03 [matt]
Jaehyuk: Yes.
15:09:17 [matt]
MikeSmith: My point is that in Japan we don't have streets, so you could map things to these fields.
15:10:24 [matt]
matt: Do you think it's intuitive, that people would map the fields consistently?
15:10:29 [matt]
MikeSmith: I think so yes, it's unambiguous
15:11:10 [matt]
MikeSmith: 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.
15:12:06 [matt]
lbolstad: Looking at Opera offices in Japan: 1-24-12 Meguro, Meguro-ku, Tokyo, 153-0063.
15:12:54 [matt]
MikeSmith: Meguro is the sub division. Meguro-ku...
15:13:19 [matt]
MikeSmith: Tokyo is biggest, Meguro-ku is the next biggest, Meguro is smaller, then the 1-24-12
15:13:43 [matt]
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.
15:14:45 [matt]
rahul: 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.
15:15:23 [matt]
-> Mike's address
15:15:32 [zhang-chinaunicom]
In China we just has the street name rather than street number
15:17:03 [matt]
matt: So how does a person enter a Japanese address in a non-Japanese localized address form? Do they include the markup stuff?
15:17:10 [matt]
MikeSmith: Typically I think it's just one field in Japan.
15:17:38 [matt]
Present+ Nobu
15:17:43 [matt]
Present+ Alexey
15:18:18 [matt]
Nobu: Typically three fields: street number (1-24-5), city name + area name, building name/room number.
15:20:30 [matt]
Nobu: In Mike's example we'd have: "東京都新宿区" in one field, then "西新宿6-16-11" then "三井ビル605"
15:20:49 [matt]
[[I think I got that wrong, fix it later @@]]
15:20:57 [matt]
Nobu: There are 47 prefecture's in Japan.
15:21:36 [matt]
Steve: Sounds like we need another level of granularity between city and street.
15:21:56 [matt]
MikeSmith: There is no county-level thing in Japan.
15:22:15 [matt]
Zhang: Do you have district?
15:22:22 [matt]
lbolstad: Not in this proposal.
15:23:02 [matt]
adrianba: For a mailing address you wouldn't put the county in there, but voting or taxes it's relevant.
15:25:18 [matt]
MikeSmith: In Japan the block would be the last number.
15:27:08 [matt]
MikeSmith: The three numbers the first one is "chou" or town, the second is like the name of the area, and the third ...
15:27:46 [matt]
rahul: The objective would be to come up with something that is sufficient for everywhere, but I think the additionalInformation field will help.
15:27:49 [matt]
rrsagent, draft minutes
15:27:49 [RRSAgent]
I have made the request to generate matt
15:29:33 [Nobu]
an example of Web form for Japnese address:
15:29:40 [matt]
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.
15:29:54 [matt]
MikeSmith: Have the field names in the interface be opaque.
15:30:09 [matt]
sblock: That's what the RFC did, but it became non-obvious to the JavaScript developer
15:30:38 [matt]
rrsagent, did you die on me?
15:30:38 [RRSAgent]
I'm logging. Sorry, nothing found for 'did you die on me'
15:30:51 [matt]
MikeSmith: The trade off is that it's not obvious to those outside of the English speaking world.
15:31:37 [adrianba]
15:32:18 [rahul]
rahul has joined #geolocation
15:34:00 [matt]
matt: Maybe we can also preserve the unparsed address.
15:34:52 [matt]
rahul: In India there's things like "near the Golden Temple".
15:36:22 [matt]
lbolstad: We could add a "raw" field. And maybe add another level between city and street.
15:36:24 [matt]
sblock: And rename street number.
15:36:30 [matt]
rrsagent, draft minutes
15:36:30 [RRSAgent]
I have made the request to generate matt
15:36:52 [Nobu]
15:37:54 [matt]
adrianba: The Cisco case has the option of detailed information.
15:37:55 [Nobu]
15:38:26 [matt]
rrsagent, draft minutes
15:38:26 [RRSAgent]
I have made the request to generate matt
15:39:08 [matt]
rahul; The additional information is the logical union of all the things we've talked about.
15:39:32 [matt]
lbolstad: You'd still want raw?
15:39:34 [matt]
rahul: Yes.
15:40:02 [matt]
adrianba: Maybe informative text to encourage location providers to specify what it is they'll put in additionalInformation
15:41:14 [matt]
adrianba: 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.
15:41:28 [matt]
adrianba: So, if we're not going to decide what it should be, we should encourage them to document what it is.
15:41:43 [matt]
andreip: We should encourage them to populate as much as they can in these fields.
15:41:57 [matt]
adrianba: And include a suggested mapping to the RFC in an appendix or something.
15:42:37 [matt]
ACTION: andreip to update address field to RFC mapping and add it to spec
15:42:37 [trackbot]
Created ACTION-75 - Update address field to RFC mapping and add it to spec [on Andrei Popescu - due 2010-11-11].
15:42:42 [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.
15:44:04 [matt]
MikeSmith: District seems better than ward.
15:44:20 [matt]
adrianba: Should include in the spec what the size of each is relatively.
15:44:33 [matt]
sblock: Do we need street number and premises?
15:44:44 [matt]
andreip: Yes, for my case I have "Kings Court" and a street number.
15:44:51 [matt]
sblock: Which is larger there?
15:46:39 [matt]
andreip: The list in the spec is in order of decreasing size.
15:48:52 [callie]
callie has joined #geolocation
15:49:16 [matt]
adrianba: I think this is good, we can get an indication in CR if this is working or not.
15:49:36 [matt]
rrsagent, draft minutes
15:49:36 [RRSAgent]
I have made the request to generate matt
15:50:13 [matt]
i/Berntson/Topic: Civic Addresses/
15:50:15 [matt]
rrsagent, draft minutes
15:50:15 [RRSAgent]
I have made the request to generate matt
15:51:12 [tlr]
tlr has joined #geolocation
15:51:44 [matt]
Topic: Civic Address Open Issue Review
15:51:48 [matt]
15:51:50 [matt]
15:51:51 [trackbot]
ISSUE-3 -- Exposing civic addresses in the API -- open
15:51:51 [trackbot]
15:52:40 [matt]
15:52:40 [trackbot]
ISSUE-8 -- Add civic address field(s) for indoor locations -- open
15:52:40 [trackbot]
15:52:53 [matt]
sblock: We could respond that this would go in the additionalInformation field
15:54:05 [matt]
ACTION: andreip to make sure additionalInfo and additionalInformation are in sync
15:54:05 [trackbot]
Created ACTION-76 - Make sure additionalInfo and additionalInformation are in sync [on Andrei Popescu - due 2010-11-11].
15:56:22 [matt]
rahul: My preference would be for unparsed rather than raw.
15:57:05 [matt]
15:57:05 [trackbot]
ISSUE-78 -- Civic address field name -- open
15:57:05 [trackbot]
15:57:36 [matt]
15:58:13 [matt]
15:58:13 [trackbot]
ISSUE-77 -- Civic address format -- open
15:58:13 [trackbot]
15:58:23 [matt]
16:00:21 [matt]
matt: I could see a use case for comparing addresses: "meet me at foo bar"
16:00:41 [tlr]
tlr has joined #geolocation
16:00:49 [matt]
matt: 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.
16:01:17 [matt]
matt: I'm just saying a use case does exist, but maybe is out of scope.
16:01:43 [matt]
lbolstad: I think the comparison case was supporting the use of more fields.
16:01:55 [matt]
adrianba: The opposite could also be true, the more fields the more chance that they're wrongly used.
16:02:17 [matt]
andreip: Do you get requests for comparing addresses in your software adrianba?
16:02:22 [matt]
adrianba: I can ask.
16:02:45 [matt]
adrianba: 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.
16:04:49 [matt]
sblock: I'm not sure you can compare without the domain knowledge of the application.
16:05:01 [matt]
sblock: If you just want the distance, you can take two lat/lng pairs and work it out yourself.
16:05:35 [matt]
16:06:22 [matt]
16:06:22 [trackbot]
ISSUE-81 -- Civic address format transformations -- open
16:06:22 [trackbot]
16:08:15 [matt]
adrianba: We have to accept that it would be a lossy conversion.
16:08:39 [rahul]
rahul has joined #geolocation
16:09:04 [matt]
andreip: We'll map the obvious fields to theirs and leave the others blank.
16:09:23 [matt]
adrianba: If we have the appendix mapping then that's sufficient. Then they can make their own conclusion on how to map back.
16:09:36 [matt]
sblock: Then we've got our raw field, which should not be lossy.
16:09:58 [matt]
lbolstad: We have an action from our last f2f asking them to map back.
16:13:38 [matt]
lbolstad: 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.
16:14:21 [matt]
lbolstad: Thinking about converting from say a Google address to the RFC format...
16:14:48 [matt]
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.
16:15:09 [matt]
sblock: I think the Cisco guys were very keen to retrieve an RFC version of the address.
16:15:39 [matt]
andreip: If someone uses geolocation API and wants to pass information to the emergency services, they only receive the RFC format.
16:15:44 [matt]
adrianba: That's a risky use case.
16:17:06 [matt]
PENDING RESOLUTION: Close ISSUE-81 once andreip closes associated action.
16:17:47 [matt]
16:17:47 [trackbot]
ISSUE-3 -- Exposing civic addresses in the API -- open
16:17:47 [trackbot]
16:18:08 [matt]
16:18:11 [adrianba]
rrsagent, make minutes
16:18:11 [RRSAgent]
I have made the request to generate adrianba
16:18:18 [matt]
16:18:18 [trackbot]
ACTION-1 -- Lars Erik Bolstad to circulate proposed F2F agenda to member-geolocation -- due 2008-11-17 -- CLOSED
16:18:18 [trackbot]
16:18:50 [matt]
16:18:50 [trackbot]
ACTION-57 -- Andrei Popescu to put field mapping information into the spec -- due 2009-11-10 -- OPEN
16:18:50 [trackbot]
16:19:07 [matt]
s/closes associated action/closes ACTION-57/
16:21:43 [matt]
rrsagent, draft minutes
16:21:43 [RRSAgent]
I have made the request to generate matt
16:24:36 [matt]
Topic: Open Issues for Device Orientation
16:24:54 [matt]
sblock: There was a request for absolute property, to say the orientations are absolute.
16:25:14 [matt]
sblock: You can imagine something being able to detect changes, but not absolute values, they're still useful for say games
16:25:15 [jorlow]
jorlow has joined #geolocation
16:25:24 [matt]
sblock: And another for "is compass calibrated".
16:27:05 [matt]
lbolstad: The use cases for orientation?
16:27:08 [matt]
andreip: Games
16:27:12 [matt]
lbolstad: AR
16:27:37 [matt]
ACTION: sblock to update orientation spec with use cases
16:27:40 [trackbot]
Sorry, couldn't find user - sblock
16:27:44 [matt]
ACTION: steve to update orientation spec with requirements
16:27:44 [trackbot]
Sorry, couldn't find user - steve
16:27:48 [matt]
ACTION: stephen to update orientation spec with requirements
16:27:48 [trackbot]
Created ACTION-77 - Update orientation spec with requirements [on Stephen Block - due 2010-11-11].
16:27:54 [matt]
ACTION: stephen to update orientation spec with use cases
16:27:55 [trackbot]
Created ACTION-78 - Update orientation spec with use cases [on Stephen Block - due 2010-11-11].
16:28:43 [callie]
callie has joined #geolocation
16:31:19 [matt]
matt: Remember there's the W3C meetup tonight:
16:35:33 [Nobu]
Nobu has left #geolocation
16:37:50 [matt]
rrsagent, make minutes public
16:37:50 [RRSAgent]
I'm logging. I don't understand 'make minutes public', matt. Try /msg RRSAgent help
16:37:57 [matt]
rrsagent, make logs public
16:38:01 [matt]
rrsagent, draft minutes
16:38:01 [RRSAgent]
I have made the request to generate matt
17:12:53 [Luca]
Luca has left #geolocation
17:28:07 [rahul]
rahul has left #geolocation
18:01:17 [kensaku]
kensaku has joined #geolocation