Hi Steven!<br><br><div class="gmail_quote">2011/4/11 Steven M. Ottens <span dir="ltr"><<a href="mailto:steven@minst.net">steven@minst.net</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Last week I met Oliver Tonnhofer at FOSSGIS in Germany. We discussed the problems of tiling and especially tile-cache-management. My immediate problems are too many files to manage (for instance backups), updating of tiles, smart seeding (seeding the most popular regions first).<br>
He said that he already had done some benchmarks on SQLite and it appears to be fast enough to serve tiles. So our idea is to use SQLite as a tilestore. Storing both the tiles and its metadata. Most likely using one database per tilecache-layer or maybe one database per tilecache-layer and zoomlevel.<br>
<br>
Any thoughts from the crowd on this idea?<br></blockquote><div><br>I'm not really sure if switching to SQLite is going to make tile-cache-management a lot easier in the long run. SQLite would be perfect for small and somewhat static tilestores or offline caches for mobile applications.<br>
But once they get bigger and have constant read & write access databases get notorously difficult to backup.<br><br>Having thousand of files can be hard to handle. But there are myriad of tools like e.g. rsync that makes handling them a lot easier.<br>
<br>What I would really appreciate would be some kind of standardized tile access log format that could be parsed and used for tile seeding and an easier way to export complete tile sets.<br><br>Currently it is extremly difficult to export a complete tile set from e.g. from MapProxy to TMS format or export the data into Rastelite and it would be great if that could change in the future.<br>
<br><br>cu andreas </div></div>