Re: Forward/backward compatibility

Hi Andrei,

 > I think your argument can be summarized as follows: some systems only
 > know the civic address where a set of desktop computers is located.
 > Given that in a subset of these cases the civic address does not
 > geocode to a precise (lat, long) pair, then this API should make the
 > geodetic coordinates optional on the basis that they may not always be
 > useful.

I would make two corrections to that:
1. Remove the word "Desktop".  This could apply equally well to mobile 
hosts.
2. It's not just that a lat/long/accuracy isn't always useful, it's that 
it can actually be deceptive.  (See below.)

 > In my opinion, this argument is flawed since the concept of usefulness
 > should be left entirely to the application that receives the location
 > data. There are classes of applications that perfectly happy with
 > city-level accuracy so, to them, the coordinates that result from
 > geocoding a civic address are perfectly useful.

... except that cities aren't circular.  If I describe Washington, DC by 
a lat/long at the Washington monument, plus a big enough radius to 
enclose all of DC, then I get significant chunks of two other *states* 
as well.  How is an app supposed to tell which jurisdiction I'm trying 
to tell him?  I could make a circle that lies entirely inside the 
District, but that leaves out a lot of area.  The same applies to 
buildings.

Like you said, there are apps that are interested in claims like "I'm in 
this city" or "I'm in this building", and there are location providers 
that can only provide that level of detail.  If you want to make 
statements like that, without artificially decreasing precision or 
claiming to increase it, you either need complex geodetic shapes or 
civic addresses.  The latter are far easier to implement, both for 
location provider and application providers.

--Richard




Andrei Popescu wrote:
> Hi Richard,
> 
> On Thu, Nov 13, 2008 at 10:30 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>> There are lots of cases where converting a civic address to a
>> lat/long/altitude results in silly results.  I'm sure Martin has better
>> examples, but here are a few that come to mind:
>>
>> The most obvious one is where the civic address describes a large area, like
>> a state or a county.  You can run into this even when the address represents
>> a specific unit of land, like a large farm.  Or a large building, like the
>> Merchandise Mart or the Pentagon.  (Factoid: The Pentagon takes up 0.004 of
>> a degree of latitude.  Merchandise Mart. Both have their own ZIP codes.)
>>
> 
> I think your argument can be summarized as follows: some systems only
> know the civic address where a set of desktop computers is located.
> Given that in a subset of these cases the civic address does not
> geocode to a precise (lat, long) pair, then this API should make the
> geodetic coordinates optional on the basis that they may not always be
> useful.
> 
> In my opinion, this argument is flawed since the concept of usefulness
> should be left entirely to the application that receives the location
> data. There are classes of applications that perfectly happy with
> city-level accuracy so, to them, the coordinates that result from
> geocoding a civic address are perfectly useful.  In case of a building
> (where most desktop computers seem to be located), if you were to
> geocode such addresses to the center point of that building, then you
> would get a (lat, long) pair with an associated accuracy of a few
> hundred meters. You mentioned the Pentagon (largest building in the
> world): that building has a ground area of ~344 sq meters, so the
> accuracy in this case would be roughly 300 - 400 meters. If this is
> meaningless / silly, then anything worse than that will also be
> meaningless / silly. But GSM Cell-ID providers that are used today on
> mobile devices return coordinates with a lot lower accuracy than this,
> and practice shows that those fixes are actually useful to many
> applications. I therefore don't think your argument is a good enough
> reason to make latitude and longitude optional in this API.
> 
> Thanks,
> Andrei
> 
>

Received on Sunday, 16 November 2008 17:02:23 UTC