Re: osm-tile-server
On 06/09/15 18:45, Ruben Undheim wrote:
>> So, if I understand what you are getting at here, you don't want to
>> start tilelite until openstreetmap-carto is usable.
>>
>> Now currently, usable means that the package is configured, and the user
>> has selected to download the data files.
>>
>> But, as tilelite does not depend on openstreetmap-carto, if you have a
>> metapackage that pulls in both of them, the packages could be configured
>> the other way around, which would mean tilelite would start before
>> openstreetmap-carto is configured, and the data files fetched.
>
> What I intended with the packages I've been working on was that the
> tilelite package itself does not install any daemon process, but the
> "osm-tile-server-tilelite" package installs the daemon process.
> osm-tile-server-tilelite depends on both osm-tile-server-base and
> tilelite, and osm-tile-server-base itself depends on
> openstreetmap-carto. This means that both openstreetmap-carto and
> tilelite will have been fully configured before the tilelite daemon
> starts. Doesn't this seem to solve the problem you describe?
It does, but it means that some of the configuration handling for the
tilelite package sits in a completely separate package, which feels a
bit off.
>> Having the data files in the openstreetmap-carto package, or a package
>> it depends on would solve this, but I am not sure if this is possible at
>> the moment, as one of the files downloaded is around 413MB, which might
>> get rejected by the Debian archive maintainers.
>
> I saw the same thing. The files are very big..., but isn't there a
> possibility of adding some kind of dummy files for the shapefiles that
> will allow tilelite to be started (but not necessary displaying the
> correct coastlines etc). The user can be warned that it needs to run
> the script to download updated shape files. It is just a bit annoying
> that when I now install osm-tile-server-tilelite, it crashes if the
> shapefiles haven't been downloaded... But I guess we have several ways
> of working around this problem.
Dummy data does not feel like the right way of solving this problem. Its
not good for something to work wrong when it should not have worked at all.
However, don't let my opinions block you from attempting to do or change
anything.
Reply to: