The actual Coordinate system is Sphere_Mercator (53004) instead of World_Mercator (54004). Some small gaps between tiles maybe visible at smaller scale if the projection is not set correctly. See below.
Understanding Tile System World Mercator (54004) Sphere Mercator (53004)
The tile system started at zoom level 1, and the earth is rendered as 4 tiles, 256x256 each.
Each successive zoom level, the map width and height grew by factor of 2
At zoom level n, the map size is 256 * 2 ^ level pixels
Assuming DPI of 96, at latitude 0, the actual zoom scale can be calculated, and a set of commonly used map scale can be used as reference to set up the map engine for cutting tiles.
For most local governments, the relevant zoom level are from 10-19.
Each resource can implement one or more interfaces. For example, an ArcIMS resource can produce Map and perform query, and a SQL resource can store, retrieve image and possibly query. While a File resource can only store and retrieve image.
A particular tile set can mix and match its functionalities. For example, the base map tiles can use SQL server to store tiles, use ArcIMS to make tiles on the fly, and use MS Spatial for data query.
Cutting Tiles: Implementing Interfaces
A Simple Scenario
Use ArcIMS to make tile images.
Store Tile Images in a file system
Retrieve tile from the file system
Use ArcIMS to make images
The Input coordinate system should be WGS Geographic Coordinate System, unless converted in the cutter.
The output image should be in Sphere Mercator Coordinate System (53004).
Reaspect must be set to false to avoid ArcIMS automatically adjust the envelopment if the filtercoordinate system is GCS 4326.
For vector layers, it maybe necessary to set a transparent background for PNG output types.
For Vector layers, PNG8 is recommended for smaller size. For raster, JPG is best.
SQL Express is a good option for moderate datasets (4GB limit).
Faster to move between systems( detach, attach)
More meta data options such as timeout rules etc.
Can use x, y, z index or Quadkey.
Tile Image store as Image type (or varbinary)
MDF file can be put into TileServer application’s App_Data folder, or register with SQLExpress using Management Studio.
The Cutter write bytes into a table, and tile server handler read from database and send to browser.
Improving Tile Cutter Quality
Because the map will be pre-rendered, it is acceptable to use advanced cartographic features such as antialiasing.
Use scale dependent renderers for different zoom level, using the map scale table for reference.
Use multiple composite renderers to achieve outline effects for polyline feature class
Use multiple layers to make sure correct symbol order. e.g Freeway on top of local streets.
Improve cutting performance
Only Google Map API supports tile size other than 256x256. Larger tile means less server requests but larger download size.
Having map engine render 256 tiles is not very efficient considering data IO, rendering etc.
For most map engine, rendering a 512 x 512, even 1024 x 1024 map takes only slightly longer time than rendering a 256x256 map.
Cut larger tiles then slice into smaller pieces will dramatically decrease the number of map images the map engine has to make. Cut 512 instead of 256 will need only about ¼ of map requests (the boundary may cause small variations)
Improve cutting performance
Use Graphics API such as GDI+ or Java2D can slice images into smaller pieces.
PNG8 can cause smaller problem because the GDI+ will convert it to PNG24 and the saved file will lose transparency setting.
To fix the PNG8 problem, use the Image Color Quantization code from http://msdn2.microsoft.com/en-us/library/aa479306.aspx
The cutter uses larger steps when traveling in tile system, requesting larger images from map engine, then slice them, store in tile repository in normal size.
Most web server or application framework has some caching mechanism.
Tiles can be cached in memory of web server and served directly if someone requested same tile within a timeout window.
ASP.NET has built-in HttpContext.Cache system, along with configurable CacheDependency, the tile server will have a better performance.
For less popular area, the tile can be rendered on demand and store in to the tile repository.
There are multiple level of caching:
If the browser can not find the tile or expired.
Generate on demand then store the tile.
Push-pin or Markers are generally clickable in GM/VE/YM API.
The map itself can not be clicked, or “identified”
However, click events can be captured, along with information about the clicked point, including lat/lon, zoom level, map view point extent etc.
Those information can be passed via AJAX request to server and query the underline spatial data.
Normally a query engine can work off the same map service that produces the actual map image, in that case, the scale control on layer can be used to check which layer should be queried.
Identify function can be de-coupled from the map service, so additional tools and features can be used.
A Common interface ITileData can be defined and resources can implement the interface.
The query can be implemented by ArcIMS query server, or MS spatial, or ArcSDE API, or other spatially enabled RDBMS, such as PostGIS etc.
Attach click event to Google Map instance
Upon click, form an http request and send to server via XmlHttp
Perform spatial query based on clicked location, adjust to correct spatial reference system.
Display results in callback.
Putting it together
An example that:
Replace the default Map type’s tile layer
Add a new map type for a new tile set.
Tile cut from an ArcIMS map service.
Store/retrieve map tiles in SQL express
Render on demand when the requested tile is not pre-rendered.