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 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.
A single sqlite db file per scale level, per tile cache solves this problem.
Generating tiles is currently done using a rather brute force approach, by storing
tiles in a database, it can be queried for existing tiles and only missing tiles
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)
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
Discussions
Funding / Resources
Ennoble Community(?)
