RFC: civic location
Andrew Turner
ajturner at highearthorbit.com
Fri Jun 15 06:41:14 PDT 2007
Clients
--- (lat/lon && civic) ---
| GeoClue | =(lat/lon || civic )=> | Services |
| | <=(lat/lon && civic)= | |
--- ((lat/lon || civic) ---
--- && 'accuracy') ---
Backends
Better for mono-spaced people?
On 6/15/07, Andrew Turner <ajturner at highearthorbit.com> wrote:
> On 6/15/07, Jussi Kukkonen <jhkukkon at cc.hut.fi> wrote:
> > ** 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
>
> There is civic location - and there is also Toponym. Geonames.org will
> be an incredible resource for this. For geocoding lat/lon into
> location name (eiffel tower) instead of just address. It also has
> exonyms/endonyms - all the names the location is referred to in any
> number of languages.
>
> > 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)
>
>
> Some services will optionally be able to provide civic location. For
> example - Loki (wifi-geopositioning) can return street, city, region,
> country with lat/lon.
>
> I would think to make this generic, just allow civic location as an
> optional parameter in the Positioning-backend interface. Similarly,
> lat/lon should be optional (as a service may provide *only*
> civic/toponymic location)
>
> Then I think another layer/service would be 'lookup' services. Like
> geocoders. These would take in either lat/lon or civic and return the
> full response of lat/lon & civic (would reflect back the input or
> possibly even clean it up (correct spelling, punctuation, fill in
> missing parameters like postcode or region))
>
>
> So not it looks like:
>
> Clients
> --- (lat/lon && civic) ---
> | Geoclue | =(lat/lon || civic )=> | Services |
> | | <=(lat/lon && civic)= | |
> --- ((lat/lon || civic) ---
> --- && 'accuracy') ---
> Backends
>
>
>
>
> >
> >
> > * 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
> >
> >
> > _______________________________________________
> > GeoClue mailing list
> > GeoClue at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/geoclue
> >
> >
> >
>
>
> --
> Andrew Turner
> ajturner at highearthorbit.com 42.2774N x 83.7611W
> http://highearthorbit.com Ann Arbor, Michigan, USA
>
--
Andrew Turner
ajturner at highearthorbit.com 42.2774N x 83.7611W
http://highearthorbit.com Ann Arbor, Michigan, USA
More information about the GeoClue
mailing list