I understand that. Consider the simple case, where the view is only a small portion of the entire (world) map; simplify further and consider that the tiles consist only of a single row, instead of the two dimensional array that would really be used, and that there are only ten tiles, numbered 0-9. The view determines where it is centered and the extent of the view and sends that information off the the tile server. The server determines which tiles are needed to fill that particular view, and their arrangement. Let's say the server determines that tiles 4, 5 and 6 are required; it sends those tiles, along with some information about how they should be displayed, in this case simple ordering will do: 4 5 6. Now, if there are only ten tiles that span the entire map, let's look at the case where things need to "wrap around": the server determines that tiles 8, 9 and 0 are needed, and that they should be displayed in that order: 8 9 0. Or it determines that tiles 9, 0 and one are needed in the order 9 0 1. The wrapping problem is solved, and only the portions of the map needed (plus a small amount that slops over the view edges) are required.
This is how GIS handle such things.
If you are trying to visualize the entire span of the map, the same approach works, but your single tile is the size of the map. You can make the client smart enough to reuse that single tile without too much trouble.





Reply With Quote

Bookmarks