Re: Forward/backward compatibility

On Thu, Nov 13, 2008 at 7:39 PM, Richard Barnes <> wrote:
> Hi Andrei
>> I think it's better to leave the Position
>> interface as is and just add an 'address' attribute to it. ... since all
>> implementations are guaranteed to support
>> lat/long coordinates.
> That assumption -- that all UAs have lat/long -- shows up all over this
> list, and I don't know where it comes from, unless it's a deliberate
> limitation on the scope of the API.

Yes, this is deliberate.

> There are many examples of location providers that don't naturally provide a
> lat/long, but can do pretty well with civic information.  Some random
> examples:
> -- A fixed-line ISP that has a database of service addresses that they offer
> as a location provider

I'm not sure I understand this example, can you please explain?

> -- An enterprise network that hands out location down to the floor and
> cubicle number

The floor and cubicle are part of some building, so I imagine it's
feasible for the enterprise to find out what are the lat/long
coordinates for each of its buildings and add the information to its
location database.

> -- An IP-based geolocation service that is reasonably accurate to the
> metro-area level, but not down to a point (see [1],[2])

Ok, but that's the case today with IP-based location providers that
are already used to implement this specification. They are very well
able to provide a lat/long and an associated accuracy. In v2 they will
also provide a civic address, but I don't see a problem with them
being used to implement v1 of our API. And indeed, both examples that
you give *do* provide latitude and longitude. The Location class in
your second example reads:

public class Location {
    public String countryCode;
    public String countryName;
    public String region;
    public String city;
    public String postalCode;
    public float latitude;
    public float longitude;
    public int dma_code;
    public int area_code;

> The best a lat/long will do in these cases is get to the front of the
> building; at worst, it'll be geocoded into something meaningless.

Whether a lat/long pair is meaningless or not depends on the
application, which is able to make a decision based on the value of
the accuracy field.

>> If by 'Civic' you mean address, then I agree that that placing it on
>> the Position interface is the right thing to do. So, as far as
>> extensibility goes, I think we agree. I am not sure about the naming,
>> as 'civic' seems to be something pertaining to a city. Anyway, that's
>> a discussion for v2.
> As I understand it, the name "civic location" or "civic address" (in
> contrast to "geodetic location") has fairly wide, standard usage in
> communities that deal heavily with location.  For example, the emergency
> services community (9-1-1 / 1-1-2).

That may well be, but I'm not sure that is the main target audience of
this API. I think we need to come up with a terminology that is
intuitive to anyone using this API, not just domain experts. We can,
of course, add wording to clarify that the same concept is called
"civic" in certain communities.


Received on Thursday, 13 November 2008 20:45:00 UTC