[Librem-5-dev] Packaging offline maps server for L5

rinigus rinigus.git at gmail.com
Sat Aug 24 06:47:40 PDT 2019


The offline maps server does way more than just a bunch of tiles stashed in
a folder.

Re API: API is actually via HTTP through localhost URL. Its described at
https://github.com/rinigus/osmscout-server#access with DBus extensions
mainly used to provide just-in-time navigation data.

Re lockstep: I need to have data servers and program versions matching.
Each Planet import and distribution takes significant amount of time and
server resources. In theory, we can keep 1-2 versions of older imports for
people with older libs, but those will probably not get updated and users
will want to move over to the newer version anyway (fresher data, better
performance). To keep multiple versions of datasets, I'll have to ask
people who provide me with the database storage and distribution for
permission as well.

Closest to the tiles-in-a-folder, it supports vector tiles (Mapbox GL
format) that are kept in sqlite databases. This is a part which is not
sensitive to 'lock in' of the library version and such distribution is
mainly done to avoid having too many files on the distribution servers.

For raster tiles, applications such as uNav and Gnome Maps, the server
performs rendering using Mapnik on device. This allows you to have the
tiles with different styles (day, night, car-oriented, ...) from the same
data. You could also tune label sizes for your linking which is
advantageous when you want to use maps while keeping them in your hand or
on the holder in a car for navigation. The used Mapnik version requires a
special patch (merged upsteram, will come with the next major Mapnik
release) that allows to compress datasets by the factor of 2 or so when
using SQLite backend.

Server can be used to search for streets, calculate the routes, find POIs
next to some reference point or along your route. All this is impossible
when serving a bunch of tiles via local tiles in a dir. However, all the
libraries used for it (Valhalla, GeocoderNLP) do require specific versions
of the datasets on which they operate.

Cheers,

Rinigus

On Sat, Aug 24, 2019 at 3:53 PM Matthias Apitz <guru at unixarea.de> wrote:

> On Sat, 24 Aug 2019 14:56:57 +0300, rinigus via Librem-5-dev wrote:
> > Hi,
> >
> > I would like to get an advice on how to package properly offline maps
> > server - OSM Scout Server - for L5. Its a piece of software that allows
> > such map clients as Pure Maps to work in offline mode (show maps, search
> > locations, calculate routes, and other expected operations on maps). Its
> > also written in a way that allows it to be used with other map clients -
> > why not Gnome Maps, sports apps - and share the same data on device. The
> > clients just have to use documented API for that. As a result, users
> don't
> > need to download large offline datasets specific for some app, but can
> use
> > the same datasets in multiple applications.
> >
> > What makes packaging situation a bit trickier is the fact that the server
> > requires some specific libraries and their versions. These specific
> > requirements are due to the used offline map data which has to match the
> > libraries. We are going to be sharing the same datasets as used on
> > Sailfish, L5, and Flathub-distributed version. So, all of the versions
> have
> > to use the same libs versions. In addition, I should be able to update
> all
> > of them within a reasonable amount of time when such updates are required
> > allowing me to update offline datasets and libraries simultaneously (+/-
> > 1-2 days) to ensure as good service as possible.
> >
> > Due to the time constraints on updates and bundled libs, I think there is
> > no point in going for full Debian packaging solution which would require
> > packaging as a part of Debian. But I can surely make a special DEB for L5
> > and bundle all libs under it. Advantage of this solution would be ability
> > to use systemd socket activation that is used currently to ensure
> seamless
> > integration with map clients. In this case, maybe someone can tell where
> > would I be expected to keep these bundled libs. On Sailfish, we were told
> > to use /usr/share/appname/lib . Not sure its recommended on Debian-based
> > distros.
> >
> > Alternative would be to use Flatpak. Its by definition packages the
> > libraries with it, I have already all scripts written and the server
> > distributed via Flathub. In this case, I would need to add DBus
> activation
> > (systemd socket activation is not supported), but that maybe a good idea
> > anyway for covering requirements of desktop users.
> >
> > I would prefer to package it as Flatpak, as it is expected to come to L5
> > and bundling of the libraries is not going against the common policies of
> > that format. However, would that be expected to work on launch of L5?
> > Server doesn't really require any fancy graphics as such - only has some
> Qt
> > QML GUI for maps datasets management and few settings.
> >
> > Thoughts regarding it?
>
>
> Hi,
>
> Why not just store the tiles in a tree form like OSM does and use a
> local.HTTP daemon to present the tiles to the map client? I do this with
> uNav on my Ubuntu Touch.
>
> Best
>
> matthias
>
> --
> Sent using Dekko from my Ubuntu device
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.community.puri.sm/pipermail/librem-5-dev/attachments/20190824/b6f50f11/attachment-0001.html>


More information about the Librem-5-dev mailing list