Re: Civic Address for V2

To +1 the other messages in this thread: We had a long discussion in  
GEOPRIV about this (I've been involved in the DHCP civic draft, which  
yielded the 4119 elements). Civic addressing *seems* easy until you  
delve into the amazing variations that are used around the world. Just  
relying on intuition about US postal addresses is a likely road to  
quick obsolescence. (There's even more elaborate work going on in  
specialized GIS and postal standardization bodies [Universal Postal  
Union], but they are likely to be too unwieldy or inaccesible for non- 
specialists.)

The draft should also explicitly reference the various profiles that  
either have already been specified or will be specified, e.g., for  
Austria. The whole point of this exercise is to have semantically- 
marked data, as we can otherwise just carry a text string formatted in  
whichever way somebody feels like.

Henning

On Feb 27, 2009, at 11:44 AM, Allan Thomson (althomso) wrote:

> Hi -
>
> I would suggest that the Civic Address format defined in the IETF  
> Geopriv PIDF-LO schema as described in RFC4119 is a more appropriate  
> definition. For many indoor environments where location can be used,  
> providing only the street address is not sufficient and RFC4119 has  
> the basis for providing location information (e.g. conference room  
> or cube) that is more relevant to indoor business applications that  
> need location.
>
> Regards
>
> Allan Thomson
> Cisco Systems
>
> From: public-geolocation-request@w3.org [mailto:public-geolocation-request@w3.org 
> ] On Behalf Of Alec Berntson
> Sent: Friday, February 27, 2009 8:32 AM
> To: public-geolocation@w3.org
> Subject: Civic Address for V2
>
> 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 coords;
>     readonly attribute DOMTimeStamp 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 Sunday, 1 March 2009 18:40:10 UTC