Re: osm-tile-server
Hi,
>> 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.
I understand your point, but I do sort of see it a little bit
differently. I consider this OpenStreetMap use of tilelite as just an
"instance" of tilelite. It should be possible to still use tilelite
for other purposes while the "OSM instance" is running. Tilelite is
sort of a simple tool adhering to the Unix philosophy of doing one
thing and doing it well. Therefore I think that a specific use of it
should be captured by one separate package which does what is expected
of it. osm-tile-server-tilelite="uses tilelite for the purpose of an
OSM tile server". Then the configuration of this tilelite-instance
will be fully captured by the osm-tile-server-tilelite configuration,
and it will not interfere with other use of tilelite at all. It would
be nice to hear what other experienced Debian people think about this
though.
>> 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.
Yes, we should try to find the best solution to this problem.
> However, don't let my opinions block you from attempting to do or change
> anything.
Nice of you to say this, but I do really like to hear your opinion. :)
Best regards,
Ruben
Reply to: