- From: Alec Berntson <alecb@windows.microsoft.com>
- Date: Fri, 27 Feb 2009 08:31:30 -0800
- To: "public-geolocation@w3.org" <public-geolocation@w3.org>
- Message-ID: <D8939A2F7A8C124ABE6075E08C52CDCA22070B28AF@TK5-EXMBX-W603v.wingroup.windeploy.n>
Hi, As per my Action Item from the December F2F meeting, I'd like to put forth a proposal for Civic Address Support in V2. Civic Address support will be surfaced by including an additional object in the Position object next to the cords object. For Example: interface Position { readonly attribute Coordinates<http://dev.w3.org/geo/api/spec-source.html#coordinates> coords<http://dev.w3.org/geo/api/spec-source.html#coords>; readonly attribute DOMTimeStamp timestamp<http://dev.w3.org/geo/api/spec-source.html#timestamp>; readonly attribute CivicAddress addr; // <-this is how it will be added }; 1. The contents of the CivicAddress Object a. I propose we use the same fields as the CivicAddressReport in the Windows 7 Location API. These fields work internationally and have no geopolitical issues. They are sufficiently expressive to cover virtually any address that would be used in practice. i. Address1 ii. Address2 iii. City iv. PostalCode v. StateProvince vi. CountryRegion 2. Addition to PositionOptions a. The PositionsOptions object needs an option to indicate which type of data to return. This option will inform the UA of what the app wishes to see in the Position objects that it is returned. b. I propose: Enum {CoordinatesOnly, CivicAddressOnly, Either} i. CoordinatesOnly = The API only returns position objects when coords has data, addr is null ii. CivicAddressOnly - The API only returns position objects when addr has data, coords is null iii. Either - the API returns a position object whenever there is data for either CivicAddress or Coordinate data. Thanks, Alec
Received on Friday, 27 February 2009 16:32:56 UTC