I’d like to discuss the option of, sustainably, providing a lot more locations
and cities in libgweather. By sustainable I mean without overloading the libgweather
My reason for wanting to do this is that the current 100k population suggestion
for inclusion can be extremely limiting in cases. Though the policy says this
is not a hard limit, it then makes the decision to include a location or city
a judgement call on the part of the maintainers, who might not be well versed
in a region’s human and political geography to be able to make that call.
I’ll make this a bit more concrete by using Sweden as an example. The coverage
of Sweden is a bit odd, in that it includes things like Ljungbyhed, a small
town with a population of roughly 2k, but a city like Uppsala, the capital of
Uppsala County with a population of 170k+ and Sweden’s 4th largest city, is
missing. Similarly, Jämtland county and its capital of Östersund and Gävleborg
county with its capital of Gävle appear to be missing. Those two total about
7% of Sweden’s entire population. Right now for me GNOME Weather for example
falls in the “cute but useless” category because of this, as it picks
Stockholm for my closest location. This is true given what libgweather knows
of Sweden, but entirely useless for weather data. (I’ll be submitting PRs to fix
these particular cases, but there’s more).
I can completely understand how this situation arises, ultimately someone cared
to submit a PR for this or not and the maintainers decided to include it. But
I’d like to explore if there’s a way to improve things, without that resulting
in a potential avalanche of updates to
Locations.xml for the current
maintainers to deal with. With that in mind, I’m wondering if it would be possible
to have additional location and city sources, in the style of drop-in files. If
libgweather could have a set of predefined directories it reads, then it would be
possible for external repositories to be used to maintain the data.
This would let interested folks maintain a libgweather-data-swe for example
where we can include significantly more data for Sweden with rules for inclusion
being tailored to the realities of the country. Additional, this would make it
easier to use some local to the country data sources to generate some of this.
In the particular case of Sweden, we could build some automation based on the
data published by Statistiska Centralbyrån (the national statistics office).
Though this makes sense in the context of Sweden, the approach doesn’t necessarily
translate to other countries, hence looking at if it’s possible to provide the data
to libgweather through something like drop-in files.
I can see some problems arising from supporting something like this:
- What to do when duplicates are found: as long as an explicit policy is set,
like files are parsed in ASCII-betical order and last definition wins, the
behaviour becomes predictable and easily user overridable
- What to do about translations: this one I’m less clear about, though in a
lot of cases having accurate city name translations isn’t crucial (since
they’re primarily relevant to locals who know how to spell them) and in the
majority of cases location names aren’t translated. As the
translation document states:
The state/province and city names are more likely to only be seen by people
living in those states/cities, and so are less critical to have 100% translation
- What to do about
Locations.bin, the database that gets compiled when libgweather
is built. I’m unsure how to solve this one. I can imagine distributions packaging
build-aux/meson/gen_locations_variant.pyand running that
whenever a package is installed with files in a libgweather drop-in location,
but I’m not sure if that’s workable and how to solve any user override
What do folks think of this? Is this reasonable, feasible, desirable? Do folks
see other ways of solving this?