[MIR] geonames

[Sebastien Bacher]

* the package is available on all archs:
https://launchpad.net/ubuntu/+source/geonames/0.1-0ubuntu1

* rationale:
it's a small library created by one of Ubuntu desktop team members to parse geonames datas, it's going to be used to provide a consistent user experience in ubiquity&settings (desktop+phone) and fixes some issues with the currently available parser

* No security issue reported

* The Ubuntu Desktop Team is maintaining that package, it's using current packaging standards and only packages in main (glib), desktop-bugs is subscribed to the launchpad reports

[Sebastien Bacher (seb128)]

going to be used in https://code.launchpad.net/~larsu/unity-control-center/datetime-use-geonames/+merge/280265

[Didier Roche-Tolomelli (didrocks)]

Looking good to me, +1, tell me once something is pulling it into main and I'll promote it.

[Didier Roche-Tolomelli (didrocks)]

$ ./change-override -c main -S geonames
Override component to main
geonames 0.1-0ubuntu1 in xenial: universe/gnome -> main
libgeonames-dev 0.1-0ubuntu1 in xenial amd64: universe/libdevel/optional/100% -> main
libgeonames-dev 0.1-0ubuntu1 in xenial arm64: universe/libdevel/optional/100% -> main
libgeonames-dev 0.1-0ubuntu1 in xenial armhf: universe/libdevel/optional/100% -> main
libgeonames-dev 0.1-0ubuntu1 in xenial i386: universe/libdevel/optional/100% -> main
libgeonames-dev 0.1-0ubuntu1 in xenial powerpc: universe/libdevel/optional/100% -> main
libgeonames-dev 0.1-0ubuntu1 in xenial ppc64el: universe/libdevel/optional/100% -> main
libgeonames-dev 0.1-0ubuntu1 in xenial s390x: universe/libdevel/optional/100% -> main
libgeonames0 0.1-0ubuntu1 in xenial amd64: universe/libs/optional/100% -> main
libgeonames0 0.1-0ubuntu1 in xenial arm64: universe/libs/optional/100% -> main
libgeonames0 0.1-0ubuntu1 in xenial armhf: universe/libs/optional/100% -> main
libgeonames0 0.1-0ubuntu1 in xenial i386: universe/libs/optional/100% -> main
libgeonames0 0.1-0ubuntu1 in xenial powerpc: universe/libs/optional/100% -> main
libgeonames0 0.1-0ubuntu1 in xenial ppc64el: universe/libs/optional/100% -> main
libgeonames0 0.1-0ubuntu1 in xenial s390x: universe/libs/optional/100% -> main
Override [y|N]? y
15 publications overridden.

done!

[Michael Terry (mterry)]

How does this interact with libtimezonemap, which the desktop team also maintains and also talks to geonames (though in a less generic way -- only through a GtkTextCompletion thingy).

[Lars Karlitski (larsu)]

> How does this interact with libtimezonemap

It doesn't interact with that at all. It's a replacement for the parts of libtimezonemap that complete city names, but without the dependency on gtk (see bug #1436211) and without fetching anything from the network (we've had a lot of reliability issues with it and users apparently expect the panel to work offline, too).

I'm probably going to deprecate everything in libtimezonemap that isn't the map itself - or even move it into unity-control-center and ubiquity, so that we don't have to install libtimezonemap at all anymore.

[Michael Terry (mterry)]

Right, I know they don't interact in a code sense. I meant the deprecation aspect.

You mention not hitting the network and I see by looking at the geonames code that it bundles cities15000.txt into itself to avoid hitting the network.

libtimezonemap also ships cities15000.txt on disk to work offline... (although, bizarrely the timezone completion part of it doesn't use it? -- maybe we could have fixed that and added some API instead of making a new library?)

But anyway, that's the sort of 5M duplication I'm trying to avoid and why I asked about their interaction. For example, geonames could have simply depended on libtimezonemap-data and not wasted 5M of space.

It's also annoying that geonames doesn't use a separate geonames-data package for that content. Avoids wasted space during SONAME transitions and makes the file available for others to parse in case they want to. For example, you could have shipped it on disk and then had libtimezonemap depend on it and drop its own data files.

[Michael Terry (mterry)]

(Oh, I guess libtimezonemap's completion code does use cities15000.txt as an initial database then additionally hits the network if that's available? But then I'm confused how geonames will improve that user experience.)

[Lars Karlitski (larsu)]

We would have ended up with a separate library anyway, because we need something that doesn't depend on gtk.

I pondered splitting the non-gtk parts out of libtimezonemap at first, but decided to do a few more optimizations while I was at it:

1. throw away data in cities15000.txt that we don't need
2. compress the data and put into the .so, so that we don't need to open another file when accessing it
3. move searching for a city into its own thread, so that we don't block the UI (see bug #1367287)
4. not create a GObject for every city in the database

The library (including the data) is about half a megabyte now. It will grow by a bit more once I include translations, but it will stay under the 5 megabytes that libtimezonemap installs. I don't see any reason why the data should be shared. Just use the library if you need access to it. I also want to make it possible for us to change the way the data is stored to allow for more efficient lookups if we find out there's need for that.

The completion part of libtimezonemap indeed parses cities15000.txt on startup (and creates an object for each), but only ever uses it when the request to the web service fails.

[Michael Terry (mterry)]

Awesome, I didn't notice the tossing-data or compression aspects; that's nice that we got it so small.

In terms of data you are throwing away, I notice you throw away the alternate names. Can you stop doing that and expose that info instead? On the phone side of things, we are trying to add support to libtimezonemap for exposing those names so that we can use them when searching for a timezone. And thus be a little less English-centric.

See https://code.launchpad.net/~mterry/timezonemap/alternate-names/+merge/280194

(Alternatively, you could add alternateNames.txt to the geonames package, but that's 400MB uncompressed...)

All your improvements are good improvements. I'm just surprised that we are creating a new project for the library rather than a new library inside the timezonemap project. It struck me as a very NIH approach to timezonemap which is in fact something we invented. :) But I get that some of the improvements you made would be a total different API anyway.

I'm just sore that I apparently wasted the effort on the above MP. :-/

[Lars Karlitski (larsu)]

Ah sorry I wasn't aware you were working on this :/

I should have commented on the bugs saying geonames is on the way.

I definitely plan to expose alternate names as well.

I guess you're right, we could have added it to timezonemap. My reasoning was that the new library's purpose is to provide access to the geonames.org database; whereas timezonemap is a widget which only happens to use that database (and might use the new library as a backend).

Sorry again.