Re: osm-tile-server
On 07/09/15 21:37, Ruben Undheim wrote:
>> You should be able to get it to run by installing the package, and then
>> running dpkg-reconfigure tilelite .
>
> No, I tried this as well yesterday. There is something missing for it
> to work out of the box afaics.
As it turns out, I did not work on some of my machines (as debconf was
giving strange responses). You can see the interactions by running with
DEBCONF_DEBUG="developer" (e.g. sudo DEBCONF_DEBUG="developer"
dpkg-reconfigure tilelite)
If you see something like the following, you have the same issue.
debconf (developer): <-- GET tilelite/tilesets
debconf (developer): --> 10 tilelite/tilesets doesn't exist
I have pushed up a patch that might fix this to the debconf branch, but
I cannot tell, as I no longer have the same behavior on any of my machines.
>> Secondly, the questions are asked if the user has configured debconf to
>> ask questions of that priority, you can go off the default value for
>> that, but really its up to the user, so lowering the priority does not
>> make much sense to me.
>
> The priority is now "high", which will make the questions appear
> during "apt install" on 99 % of all computers. By default,
> "dpkg-reconfigure" shows questions with all priorities. So lowering
> the priority will in general make the questions invisible when
> installing, but visible when running dpkg-reconfigure.
It comes down to whether "gis" is a reasonable default (or whether its
possible to have a reasonable default for the database name).
If its possible to set a reasonable default for the database name, then
the priority of the question should be medium, if not the priority
should be high.
When I set the priority, I was of the opinion that it is not possible
for me to set a reasonable default (and that it is important to inform
users that the file contains a hardcoded database name).
>> Also, it makes sense for the openstreetmap-carto package to allow the
>> user to change the database the style.xml file is configured to use, as
>> that is required for it to function properly once installed.
>>
>> If there is a issue with it not allowing you to use the same stylesheet
>> for two different databases, it seems to me that the best (worst)
>> solution is to extend the debconf scripts for openstreetmap-carto to
>> allow for copying the file, and changing the database in the copy.
>>
>> This probably has multiple advantages over a separate package doing the
>> copying, for example, openstreetmap-carto can handle regeneration of the
>> copies when the package updated, such that they don't get ignored or out
>> of sync.
>
> Regeneration of the files when it is upgraded is very conveniently
> handled by dpkg triggers. This is what I have done for
> osm-tile-server.
Fair enough, I have never used triggers before.
>> In summary, trying to avoid using the openstreetmap-carto package to
>> handle the style.xml file it contains is a bad idea, as you cannot
>> control the questions it asks the user, or how it handles
>> upgrades/removals from another package.
>>
>> This makes it clearer to me that having a setup where the configuration
>> for each part of the tileserver stack is handled by the respective
>> component packages is more complex, but has less problems than trying to
>> write a package or set of packages that wrap around it.
>
> I do not agree with your conclusion. Remember that we are not talking
> about having a wrap-around package that handles the configuration of
> these packages themselves. We are talking about a package which uses
> "instances" of these packages to make an "application". The component
> packages themselves actually don't need to be aware of this
> "application"-package. They can be considered sort of as library
> packages.
>
> I'm quite happy now with osm-tile-server for my own use now. I've been
> able to spin up a OSM tile server from scratch with maps already
> imported (small countries) in less than 5 minutes on DigitalOcean
> using the package, compared to an hour of fiddling around before. I
> don't see any other problems than that I get one irrelevant question
> from one of the "component" packages when installing. I do however see
> several problems with having the configuration spread out all over the
> place: being asked the same questions over and over again, and
> demanding that the user understands how the different questions relate
> to each other in order to get a workable configuration.
>
> I think having the configuration spread all over the place is both
> more complex to maintain (many packages must be uploaded to tweak the
> configuration), is not user-friendly, and is less friendly to other
> "applications" that may come up and will depend on some of these
> component packages.
Its hard to say what is the best approach, as there are just so many
unknowns. I don't even currently know when I will be able to use
tilelite and openstreetmap-carto together with mapnik3 (in Sid).
The configuration changes in mapnik3 may even effect this, as they may
change how the database configuration is handled.
Regardless, there are other ways of approaching this issue, for example,
the openstreetmap-carto package could produce two binary packages, the
first containing the style.xml file, and the second which depends on the
first, and handles copying it and editing it for the user. In this
scenario, you could just depend on the first package, and avoid any
questions being asked of the user.
Reply to: