Re: What about Reverse Geocoding?

Hi Erik,

Do you have any examples of what your are talking about?  How does a  
UA get a civic address?

btw, i am perfectly happy, if it isn't clear, scoping the first  
version of our specification to just deal with lat/long information on  
the web.

Doug



On Nov 11, 2008, at 4:23 PM, Erik Wilde wrote:

> hello everybody.
>
>> Do you really mean that every website that does geolocation will  
>> have to provide geodetic location?  As I've tried to point out,  
>> there are many situations where it makes more sense to provide  
>> civic, *especially* in contrast to just a lat/long pair.
>
> this discussion is now getting to the same point that we reached a  
> while ago: i proposed to extend "geolocation" to something less  
> constrained than lat/long, my use cases were civic addresses as well  
> as social places (such as neighborhood names and maybe even more  
> personal concepts), and i think if you look at how location is used  
> on the web today, there are tons of applications that use location  
> concepts that are non-lat/long. as i have pointed out earlier, i  
> think this WG will set a pretty important precedent on how location  
> concepts on the web will develop, and personally, i find it  
> unfortunate to see something as limited as a lat/long model being  
> developed under a much wider term of "geolocation". location is a  
> concept that is so rich and diverse that anything as limited as just  
> lat/long or just civic addresses will not be able to represent  
> location concepts as they are and will be used by applications.  
> personally, my wish would have been a more disciplined approach by  
> first looking at "how do we want to represent location as a concept  
> on the web", and then take this and start developing an API by  
> saying "ok, and for the really important use case of lat/long  
> locations, this API can be used".
>
> most people on this list are in favor of keeping the scope of the  
> API limited. which i think would be fine as long as the API would  
> just be clear about the fact that it is not about geolocation in  
> general, but about acquiring lat/long information. if the API would  
> be more clear about this, not only would this make it easier for  
> people to understand the scope of this API, it also would give more  
> generalized ideas about location concepts a better starting point  
> later.
>
> i do see that there currently is mainly interest in getting web apps  
> to talk to mobile clients and getting their lat/long info, and this  
> of course is a very important functionality. my personal hope would  
> just be to not claim that this is what "location on the web" is  
> going to be.
>
> think about basic web principles such as REST and its implementation  
> in HTTP. RESTful location management would allow negotiation of  
> appropriate and useful location representations, and for many  
> applications these will be lat/long, for many it will be civic  
> addresses, and for many it will be social locations. this bigger  
> question of how to manage location in a web-like way is still  
> untackled, and it would be unfortunate if the narrow scope of a lat/ 
> long-API would shape the way in which people think location on the  
> web in general will develop. i certainly hope that location on the  
> web will become much richer and more web-like, and from what i see  
> as the scope and goals of this API, it is just a fraction of how the  
> web will evolve as a location-aware web.
>
> and finally the ad section: because i am mostly interested in these  
> more long-term issues, we have organized workshops on "location and  
> the web", one at this year's WWW conference in beijing, and the next  
> is at CHI 2009. in these workshops, we try to look at the bigger  
> picture, and i suspect that things like geocoding belong into the  
> bigger picture, and not the lat/long-API.
>
> http://medien.informatik.uni-oldenburg.de/LocWeb2008/
> http://ifgi.uni-muenster.de/locweb2009/
>
> kind regards,
>
> dret.

Received on Wednesday, 12 November 2008 00:41:35 UTC