- From: Doug Turner <doug.turner@gmail.com>
- Date: Sun, 9 Nov 2008 19:12:13 -0800
- To: "Thomson, Martin" <Martin.Thomson@andrew.com>
- Cc: "Greg Bolsinga" <bolsinga@apple.com>, "public-geolocation" <public-geolocation@w3.org>, "Andrei Popescu" <andreip@google.com>, "Richard Barnes" <rbarnes@bbn.com>
In this use case, i do not see why you need anything exposed into the DOM. Lets suppose you did. We extended the location object to have this data. i don't see how a "pizza site" could make use of this information. Will they have to have a data base of civic addresses? Is it not easier to just pass them a conical form and let them deal with it? I am all for making it easier for the user to type in their location. However, i don't think we should be transporting this information to every website.... instead, i think we should encode it into something that is more universal. For example, for a end user to get their location, I wrote up this little web app (ignore lack of polish, etc.) http://whatismygeolocation.com/ It is is based on the google maps api. You simply enter where you are, confirm where the webapp thinks you are, and you get back a lat/ lon. This can be made simpler, not requiring the user to enter any data (or copy that lat/lon). In any case, using this approach will allow you to avoid sending "civic" address over the wire, and instead use the base lat/lon format. Thoughts? Regards, Doug On Nov 9, 2008, at 7:01 PM, Thomson, Martin wrote: > The use case we dealt with when we were toying with the idea of a > browser plugin was the automatic filling of address forms. We even > had a working prototype that followed exactly this use case. > > For instance, knowing where you are, you can order deliveries > without needing to go through the tedium of telling the site where > to send the package/pizza/truckload of blue metal. > > You could also say that people are more likely to get a civic > address correct. If you are relying on manual entry, then civic > address information is at least equivalent to automatic methods. > Geocoding and reverse-geocoding erase a lot of the difference > though, but a lot of that is subject to how robust the > implementation of the translation is. > > Cheers, > Martin > >> -----Original Message----- >> From: Doug Turner [mailto:doug.turner@gmail.com] >> Sent: Monday, 10 November 2008 1:42 PM >> To: Thomson, Martin >> Cc: Greg Bolsinga; public-geolocation; Andrei Popescu; Richard Barnes >> Subject: Re: What about Reverse Geocoding? >> >> Right, i think draft 1 needs to have the conical format for location >> (lat, lon, err). I worry about civic addresses universal value, cost >> to implement, and, of course, adoption. >> >> Do you have a use case for a civic addresses? Something that >> couldn't >> be solved with lats and longs? >> >> Doug >> >> On Nov 9, 2008, at 6:26 PM, Thomson, Martin wrote: >> >>> This isn't necessarily about reverse geocoding. You should be >>> careful in making that assumption. Civic address information can be >>> acquired by other means. >>> >>> Besides, if it's out of scope, then what is this doing in the >>> current draft? >>> >>> " The Geolocation API should allow an application to request address >>> information as part of the location data. " >>> >>> Cheers, >>> Martin >>> >>>> -----Original Message----- >>>> From: Doug Turner [mailto:doug.turner@gmail.com] >>>> Sent: Monday, 10 November 2008 1:01 PM >>>> To: Thomson, Martin >>>> Cc: Greg Bolsinga; public-geolocation; Andrei Popescu; Richard >> Barnes >>>> Subject: Re: What about Reverse Geocoding? >>>> >>>> I thought reverse geocoding was out of the scope for the first >>>> revision of the specification. What am I missing? >>>> >>>> Doug Turner >>>> >>>> >>>> On Nov 9, 2008, at 2:20 PM, Thomson, Martin wrote: >>>> >>>>> I don't think that either comment was suggesting that the object >>>>> needed to be in XML (or DHCP LCI) format. Only that the fields be >>>>> considered for the API... That is, something like (as you >>>> suggested): >>>>> >>>>> interface CivicAddress { >>>>> readonly attribute string country; >>>>> readonly attribute string A1; >>>>> readonly attribute string A2; >>>>> ... >>>>> readonly attribute string PLC; >>>>> readonly attribute double PCN; >>>>> readonly attribute double POBOX; >>>>> readonly attribute double ADDCODE; >>>>> readonly attribute DOMTimeStamp timestamp; >>>>> }; >>>>> >>>>> The elements chosen by gears works moderately well for the US. >>>>> Unfortunately, it doesn't travel particularly well. Hence the >>>>> suggestion that the API adopt a more comprehensive set of fields. >>>>> >>>>> Ta, >>>>> Martin >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: public-geolocation-request@w3.org [mailto:public- >> geolocation- >>>>>> request@w3.org] On Behalf Of Greg Bolsinga >>>>>> Sent: Sunday, 9 November 2008 8:24 AM >>>>>> To: public-geolocation >>>>>> Cc: Andrei Popescu; Thomson, Martin; Richard Barnes >>>>>> Subject: Re: What about Reverse Geocoding? >>>>>> >>>>>> >>>>>> On Nov 6, 2008, at 1:17 PM, Richard Barnes wrote: >>>>>> >>>>>>> Wouldn't the simple thing to do be to just provide in the API a >>>>>>> way >>>>>>> to deliver location as a civic address? See [1] and [2] for the >>>>>>> some ideas on how you might structure such an object. >>>>>>> >>>>>>> That way, a location provider that knows natively about a civic >>>>>>> address can provide it, and a location provider that only knows >>>>>>> geodetic location can geocode. This would leave the whole >>>>>>> question >>>>>>> whether and how to geocode out of the API, leaving it up to the >>>>>>> location provider. >>>>>>> >>>>>>> --Richard >>>>>>> >>>>>>> [1] <http://tools.ietf.org/html/rfc4119> >>>>>>> [2] <http://tools.ietf.org/html/rfc5139> >>>>>> >>>>>> On Nov 6, 2008, at 3:27 PM, Thomson, Martin wrote: >>>>>> >>>>>>> Civic addresses are pretty damned awkward for a computer system, >>>> but >>>>>>> they are still useful to people. For manual entry, a civic >>>>>>> address >>>>>>> is far more reliable than lat/long. Based on the current rate >>>>>>> of >>>>>>> progress of technology, manual entry is still going to be a >>>>>>> significant proportion of users. Civic addresses include >>>>>>> information that simply cannot be encoded in a geodetic >>>>>>> position, >>>>>>> such as data relating to the human environment: buildings, >>>>>>> roads, >>>>>>> signs, and landmarks. >>>>>>> >>>>>>> So here's a possibility: >>>>>>> >>>>>>> navigator.geolocation.getCivicAddress(function(address) >>>>>>> { alert(address.country);}); >>>>>>> >>>>>>> Selection of fields for civic addresses is a complex challenge. >> A >>>>>>> free-form line based format is possible, but it doesn't offer >> much >>>>>>> to the recipient. Free-form data is inconsistent. The >>>>>>> alternative >>>>>>> is to try to structure the data. Even the most carefully >>>>>>> constructed format has its drawbacks and compromises need to be >>>>>>> made. The format in RFC 4776/5139 (yes, I have a horse in this >>>>>>> race) takes the structured approach and has been widely adopted >>>>>>> already. This is the format that is most likely to be available >>>>>>> in >>>>>>> standard form from an ISP. >>>>>> >>>>>> If we pass 'a blob' back to the developer, they are going to have >>>>>> to >>>>>> parse it. Sure it's flexible, but it's not very practical. In >>>>>> addition, parsing more downloaded data is not so practical on >>>>>> resource >>>>>> constrained UAs. Developers may not parse it in the the most >>>>>> efficient >>>>>> manner. The first one to implement the parser will be the one >>>>>> that >>>>>> every other developer copy and pastes into their web page. ;) >>>>>> >>>>>> This is why I like an API solution. I think the object in >>>>>> http://code.google.com/apis/gears/api_geolocation.html#address >>>>>> is also very flexible, but it's an API. The big benefit in my >>>>>> mind >>>>>> is that the developer won't have to do any parsing. >>>>>> >>>>>> Would it be 'illegal' if a UA added these optional fields >>>>>> ("requestAddress" to the PositionOptions and "address" in >> Position) >>>>>> if >>>>>> they should not make it into the specification? It would be a >> shame >>>>>> if >>>>>> they didn't make it in, but I can see certain UAs wanting to >>>>>> provide >>>>>> this information to their developers. >>>>>> >>>>>> Thanks, >>>>>> -- Greg >>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------- >> -- >>>> --------------------------- >>>>> This message is for the designated recipient only and may >>>>> contain privileged, proprietary, or otherwise private information. >>>>> If you have received it in error, please notify the sender >>>>> immediately and delete the original. Any unauthorized use of >>>>> this email is prohibited. >>>>> ------------------------------------------------------------------- >> -- >>>> --------------------------- >>>>> [mf2] >>>> >>> >>> --------------------------------------------------------------------- >> --------------------------- >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> --------------------------------------------------------------------- >> --------------------------- >>> [mf2] >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2]
Received on Monday, 10 November 2008 03:12:58 UTC