RFC: civic location
Andrew Turner
ajturner at highearthorbit.com
Fri Jun 15 06:29:46 PDT 2007
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
More information about the GeoClue
mailing list