Databases Reference
In-Depth Information
Fig. 4 . A composite map, base layer tile, and dataset tile
tiles per map) and one fixed set of parameters for how the data is visualized,
then there are roughly 2
10 12 possible tiles. Assuming that the average size
of a tile is 500 bytes (for point datasets many of the tiles will be very sparse or
empty, especially at higher zoom levels), the complete size of the tile space is
approximately 9
×
10 14 bytes. The time that it would take to pre-generate these
tiles, and the costs associated with hosting this amount of data, are prohibitive
for projects with modest budgets.
By supporting on-demand generation of tiles, the TMS greatly reduces the
amount of static storage space required to deploy the application, which increases
the options for deployment and minimizes cloud storage costs (at the expense
of slightly more computationally expensive requests). An experiment was per-
formed to compare the total transfer times between dynamically generated and
static tiles, where the tiles from the first six zoom levels were requested for each
of the tile sets. Transfer time for the static tile set averaged 0.182s (0.039s stan-
dard deviation; 0.543s max), while dynamically-generated large particulates and
sulfur dioxide averaged 0.189s (0.094s SD; 3.245s max) and 0.187s (0.187s SD;
0.740s max), respectively. These results show that, on average, the generation
time is eclipsed by transmission time. The exceptions are the tiles at the lowest
zoom levels for large datasets, which could benefit from pre-generation or caching
priority. When requesting a map from the server, clients will often request tens
or hundreds of tiles in a short period of time. The 10Green server design, based
on REST principles, ensures that a client can use any of the available servers.
(See Sect. 3.)
×
2.4 Mobile App Development
An early version of the 10Green app simply downloaded and displayed a sim-
plified version of the 10Green Web application based on mobile Web standards.
This is an attractive and popular approach to application development, as it
requires very little device-specific code and can be quickly ported to many mo-
bile platforms. However, this approach yielded an application that was sluggish,
didn't implement the standard interface conventions, and required full page re-
freshes every time a page option was changed or the user navigated between
views of the data. A second version of the app utilized the same mobile Web
 
Search WWH ::




Custom Search