RFC: civic location

Jussi Kukkonen jhkukkon at cc.hut.fi
Fri Jun 15 06:09:09 PDT 2007


I'm reworking my plans/schedule, and I'd _really_ like comments on a
couple of issues. I'll start with civic location.



  ** Civic Location **

This is what I've been calling the kind of location information that
includes data like a street address, country name or post code. I rate
civic location support a high priority issue for Geoclue for two
reasons:
 1. Lots of applications will want to use this data instead of lat/lon
 2. Human readable location information makes demoing GeoClue easy

Just so you know: As a learning exercise I actually already coded a
prototype civiclocation interface, hostip-implementation and some
example-code. I can commit this if you want to take a look (it
doesn't break other things as far as I can see ;) ), or I can wait
after the discussion here.


Some open issues that I'd like comments on:

* Is Civic location an interface of it's own or should the
  functionality go into Positioning-backends? I originally thought a
  new backend type would be good idea, but am not 100% sure anymore...
  Some reasons for using a new interface:
    * the api might get fairly large (see below)
    * a lat/lon source is not necessarily a civic location source
      (and e.g. selecting GPS as the default backend would mean no
       civic location)


* The API. Currently my prototype is very spartan, only one method
  (and the hostip implementation actually only fills country and city):

      current_location (country, city, street, house_number)

  We may want convenience methods like the one above (implemented either
  in bindings or in server), but we'll probably also want methods for
  singular elements, e.g.
      country (OUT_country)
  The elements we may want to support can be picked from this list
  (from IETF rfc 4119):
   +----------------------+----------------------+---------------------+
   | Label                | Description          | Example             |
   +----------------------+----------------------+---------------------+
   | country              | The country          | US                  |
   |                      | (ISO 3166 code)      |                     |
   |                      |                      |                     |
   | A1                   | national             | New York            |
   |                      | subdivisions (state, |                     |
   |                      | region, province)    |                     |
   |                      |                      |                     |
   | A2                   | county, parish,      | King's County       |
   |                      |                      |                     |
   | A3                   | city, township,      | New York            |
   |                      |                      |                     |
   | A4                   | city division,       | Manhattan           |
   |                      | borough,             |                     |
   |                      |                      |                     |
   | A5                   | neighborhood, block  | Morningside Heights |
   |                      |                      |                     |
   | A6                   | street               | Broadway            |
   |                      |                      |                     |
   | PRD                  | Leading street       | N, W                |
   |                      | direction            |                     |
   |                      |                      |                     |
   | POD                  | Trailing street      | SW                  |
   |                      | suffix               |                     |
   |                      |                      |                     |
   | STS                  | Street suffix        | Avenue, Platz,      |
   |                      |                      | Street              |
   |                      |                      |                     |
   | HNO                  | House number,        | 123                 |
   |                      | numeric part only.   |                     |
   |                      |                      |                     |
   | HNS                  | House number suffix  | A, 1/2              |
   |                      |                      |                     |
   | LMK                  | Landmark or vanity   | Low Library         |
   |                      | address              |                     |
   |                      |                      |                     |
   | LOC                  | Additional location  | Room 543            |
   |                      | information          |                     |
   |                      |                      |                     |
   | FLR                  | Floor                | 5                   |
   |                      |                      |                     |
   | NAM                  | Name (residence,     | Joe's Barbershop    |
   |                      | business or office   |                     |
   |                      | occupant)            |                     |
   |                      |                      |                     |
   | PC                   | Postal code          | 10027-0401          |
   +----------------------+----------------------+---------------------+


* Combining / standardizing interfaces
  This is how we use/produce location info right now:
    * position                    IN: -           OUT: lat/lon
    * geocode (addr_to_latlon)    IN: civic       OUT: lat/lon
    * geocode (latlon_to_addr)    IN: lat/lon     OUT: civic
    * civiclocation               IN: -           OUT: civic
  We should probably make sure that at least the interfaces that have
  the same output types have the same interface (as much as possible).
  Other ideas? Is the current interface division a smart one?


* backends using other interfaces/backends
  It's possible (and probably smart) to write backends that use
  other backends to get the data. Example:
    A civiclocation backend uses the position interface (e.g. GPS
    backend) to get lat/lon and then the geocode interface (e.g.
    yahoo backend) to get civic location.
  Is this a good idea? Is there anything preventing this?



 -jussi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/geoclue/attachments/20070615/4f779b9a/attachment.pgp 


More information about the GeoClue mailing list