= !MapGuide RFC 112 - sqlite based tile cache = This page contains a change request (RFC) for the !MapGuide Open Source project. More !MapGuide RFCs can be found on the [wiki:MapGuideRfcs RFCs] page. == Status == ||RFC Template Version||(1.0)|| ||Submission Date||(Date / Time submitted)|| ||Last Modified||(your name here) (modification date here)|| ||Author|| Zac Spitzer || ||RFC Status||(draft)|| ||Implementation Status||(pending)|| ||Proposed Milestone||(2.3)|| ||Assigned PSC guide(s)||(when determined)|| ||'''Voting History'''||(vote date)|| == Overview == This is a proposal to implement a secondary tile cache persistance layer using a sqlite db. == Motivation == The file base tile cache can be problematic for backup or copying due to the massive number of files and directories.[[BR]] A single sqlite db file per scale level, per tile cache solves this problem. [[BR]] Generating tiles is currently done using a rather brute force approach, by storing[[BR]] tiles in a database, it can be queried for existing tiles and only missing tiles[[BR]] can be requested. Using a sqlite database will use less disk space than a disk based tile cache. == Proposed Solution == Implement sqlite based persistance as an option for the tile cache. Utilize FDO as the storage interface, perhaps using GDAL RasterLite http://www.gdal.org/frmt_rasterlite.html Add additional API methods to the tile service to query and manage the tile cache (TBD)[[BR]] Some way to convert between tile cache formats (standalone util?) Each tile would be stored with it's extents/scale, allowing the coverage a tile cache could be visually mapped. == Implications == TBD == Test Plan == Existing Tile Cache unit tests still apply == Funding / Resources == Ennoble Community(?)