I should have done some tests, but haven't had time that yet.
I feel that we have gained performance both in seeding and access.
But I haven't done any measurements.
My first goal was to have sqlite db files that were not to big and not to small.
It worked really good serving 16 zoom levels over
Lars,
Sorry for the side questions
Is there any performance benefit (specifically seeding) in using the
x/ycount parameters?
Thanks
On Thu, 20 Sep 2018 at 08:24, wrote:
> I also ran into the problem of running out of i-nodes last year.
>
> Here is the configuration I have with a sqlite cache:
I guess I was following the example in on this page:
https://mapserver.org/mapcache/caches.html
(https://mapserver.org/mapcache/caches.html)
It explains the naming.
Look under section: Using Multiple SQLite Database Files.
You don't need to worry about calling the database. Mapcache is doing t
Lars,
Why did you use {z}/{x}-{y} in the filename?
I was probably wrong when I tell to create the sqlite file, this is true
for mbtiles though.
Y.
Le jeu. 20 sept. 2018 à 14:24, a écrit :
> I also ran into the problem of running out of i-nodes last year.
>
> Here is the configuration I have w
I also ran into the problem of running out of i-nodes last year.
Here is the configuration I have with a sqlite cache:
/data/mapcache/{grid}/{tileset}/{z}/{x}-{y}.sqlite3
1
1
1573741823
I guess the pragma thing is described in the documentation.
xcount and ycount describes how mu
disk should also be changed to mbtiles in
your example. Note that "mbtiles" is not the best name (I copy pasted my
example)! You can find a better name :)
And yes except that you need to create the db file (as you should
create a database postgresql before to use it) all other command are
similar.
Here a short tuto from my personal notes:
1. create a cache entry in your mapcache file
/var/www/osm_google.db
2. create a empty sqlite file
- run sqlite3
- run this commande inside sqlite3: ".save filename.db" (without ")
3. use this cache in your settings
You don't need MySQ
