interfaces / wiki page

[Andrew Turner]

Here is my thought on what the API's should provide:

Positioning (from backends, and from GeoClue)
Geocoding (user entered location convert to lat/lon, useful for search)
(Search - see below)


I think that Routing isn't necessarily part of "geoclue" but part of
any client application. I guess perhaps routing "could" be part of
geoclue proper (so any client can tie into it to provide directions)

Maps perhaps should also be "client-side" and not part of GeoClue.

Search is also a client-side activity. It would be nice to register
search 'services' in GeoClue with an abstract interface that any
client could then optionally query. But in general (and first round of
implementation) I think GeoClue should target just getting locations
from the backends, and providing a common location API to any client.

And as for "abstract search interface". I would suggest we support
OpenSearch-Geo & Time:
http://www.opensearch.org/Specifications/OpenSearch/Extensions/Geo/1.0/Draft_1

http://www.opensearch.org/Specifications/OpenSearch/Extensions/Time/1.0/Draft_1

The responses would nominally be GeoRSS or KML. There is already a
prototype written for GeoRSS with Wikipedia (via geonames) and
Mapufacture using MaemoMapper as the client viewer.

Finally - Track Logs I would assume would just be saying 'tell GeoClue
to store a history of locations it sees'. I guess this is an API
(commanding to start/stop/save log and logging rate, and to query any
of those logs). But again - this could just be a client.

Regarding your schedule/plan. I think we should consider making
GeoClue very thin and simple for first implementation. Make it very
solid and easy to use for just providing location. Then other devs can
build clients for Maps, Search, Track Logs, routing, etc.

This would be doable by the end of the summer. Then as the project
progresses, we can see about pulling in base-elements of additional
parts (routing, search, etc.)

Make sense?

On 6/19/07, Jussi Kukkonen <jhkukkon at cc.hut.fi> wrote:
> (Sorry for not delivering on the schedule/plans yet, I've had real
> trouble getting my thoughts organized enough...)
>
> Instead, here's something related that has bothered me for a while.
> Currently the homepage lists the following APIs/interfaces as a GeoClue
> goal:
>   # Positioning
>   # Routing
>   # Geocoding
>   # Map
>   # Track Logs
>
> Positioning and Geocoding are basic services pretty much tied to each
> other, Routing is an obvious extension and I can understand the need for
> "Maps on the desktop". The fifth one, however... can someone explain the
> logic behind that?
>
> In the code there is another type of interface too, "find". I love the
> idea of including a geographic searching interface (although I fear a
> good and abstract implementation is going to be really difficult to
> achieve).
>
>
> Summarizing:
> * Is there a point to "Track logs" and is it justifiably a part of
>   GeoClue?
> * Should I add "Find" to the list of interfaces, maybe like this:
>
> >    # Position
> >    # Geocode
> >    # Route *
> >    # Find *
> >    # Map
> >
> >   (*) not implemented yet
>
>
> -jussi
>
> PS.
>
>
> _______________________________________________
> 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