= !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(?)