Re: First release of geocode-glib available
- From: Bastien Nocera <hadess hadess net>
- To: Ted Gould <ted gould cx>
- Cc: "desktop-devel-list gnome org" <desktop-devel-list gnome org>, geoclue <geoclue lists freedesktop org>
- Subject: Re: First release of geocode-glib available
- Date: Tue, 17 May 2011 15:53:57 +0100
On Mon, 2011-05-16 at 09:37 -0500, Ted Gould wrote:
> On Sat, 2011-05-14 at 21:24 +0100, Bastien Nocera wrote:
> > On Wed, 2011-05-11 at 10:20 +0200, Ted Gould wrote:
> > > On Mon, 2011-05-09 at 16:52 +0100, Bastien Nocera wrote:
> > > > This library should be used in place of Geoclue's D-Bus API for
> > > > geocoding and reverse geocoding.
> > >
> > > Is this now deprecated in the Geoclue API?
> > Pretty much, though I can hardly tell KDE people to start using a
> > glib-ish library for that. I would expect them to come up with their own
> > library in due time.
> > When we have a working new-fangled geoclue to replace the current one,
> > the API (and the old geoclue code) will most likely disappear of their
> > own.
> Why do you think they'd do that rather than just work on GeoClue?
Because I haven't seen any patches from KDE people for now. The new
Geoclue (as discussed on the geoclue list) won't have geocoding or
reverse geocoding interfaces. There's no point in hiding a web service
behind a D-Bus interface when it doesn't buy you anything.
> > > It seems like there's an
> > > advantage to using an API that can have multiple providers.
> > The API is generic enough to support multiple providers, it's just that
> > there's currently only one implementation.
> > The fact that we have only one implementation means that we have one
> > well maintained implementation. I don't think it's much of a problem. Do
> > you have particular reasons why you think that supporting multiple
> > backends is actually useful?
> I don't have a specific use case, but I would guess that name providers
> vary widely based on location. My guess would be that Yahoo is pretty
> good in the US/Europe but there's a better local provider for
> India/China for instance. I have no information on that, it just seems
> to be pretty consistent for data like this.
Full list of supported countries:
Note that this doesn't mean that geocoding isn't available at all, it
just means that street-level isn't supported. It's still good enough for
most of our uses.
> Which is one of the things that struck me as odd with a new library
> being created that didn't use the plugable interface already created.
> Is there a reason you didn't just make a well maintained GeoClue
Because we don't want to use Geoclue's geocoding interfaces.
] [Thread Prev