Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it possible to deliver map tiles quickly over the web without worrying about caching or seeding them?

With raster map engines this is a problem because endering raster tiles is resource consuming. Consequently, it is often required to cache them in advance. Every time the map changes map tiles should be recreated and cached if you want to have them quick delivered.

share|improve this question

closed as not a real question by Devdatta Tengshe, PolyGeo, BradHards, iant Jun 24 '13 at 12:07

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

I agree with user mwalker about the potential problems vector layers have when rendered by web browsers. Since rendering a vector layer is also a CPU intensive task, I would add the following points:

  • You cannot expect that general users have a last generation web browser. In fact there are still many instances of the Internet Explorer 6 working.
  • You cannot expect that general users have a computer with enough processing power or RAM memory. This problem can become serious when the vector layer has thousands of points.

Besides, I disagree with statements like "Every time map changes map tiles should be recreated and cached if you want to have them quick delivered." Obviously, a map change implies the recreation of the cache, but not the whole cache for the affected layers: just recreating the affected area is enough. In fact, TileCache's seeder (TileCache is mentioned in the linked benchmark) accepts a restricting bounding box parameter.

Another statement I partially disagree is "Those tiles are rendering quickly and they are only 20%-50% in file size when comparing to equivalent raster tiles". In case the vectorial information is packed in a verbose format like GML, this statement can be false. Tiles of vector layers like boundaries that are compressed using formats as usual as GIF or PNG can be very, very light.

At work I have a more pragmatic approach than the almost-always-vector-layers one: a mix of vector and raster rendering. When the shown are area has too much points, pre-rendered, server side WMS tiles, and when the number of points is small enough, client side rendering of vector layers.

Another disagreement the assumption of that getting the vectorial information is faster or, at least, as fast as getting pre-rendered, cached raster tiles. Before the vectorial information arrives client side, (a) the information must be retrieved from a spatial database (PostGIS, Oracle Spatial), ESRI shapefile, file geodatabase or similar, (b) must be formatted (GML, WKT...) and (c) must be sent to the client. In the case of cached raster tiles, neither data source must be queried nor formatting must be done. Thus, it is not clear that vector information will arrive client faster than cached raster tiles, especially when the server is under high load.

The benchmark seem a bit unfair to me: "Mapnik i.e. TileCache was tested as CGI and GIS Cloud vector engine as CGI and Apache module." Why not FastCGI - which has been around for years - instead of CGI? Under CGI, for each new request a new process is created and destroyed at its end. Under FastCGI, persistent processes are used to handle requests, thus each "individual FastCGI process can handle many requests over its lifetime, thereby avoiding the overhead of per-request process creation and termination." Comparing TileCache "under" FastCGI and an Apache module would be fairer.

share|improve this answer

I think that if you could devise a solution whereby GIS data is rendered "as intended" 100% of the time, it would be wildly popular.

However, I also think that as soon as you introduce rendering styles, label placement, overlapping features, and user interaction, current browser technology and processing power are going to produce a net result that is just as slow as forcing a server to draw your map for you.

share|improve this answer

You should check out this utility tool for ArcGIS Server called Portable Basemap Server. It can provide tile images of raster images in real time without really caching them, and also can convert a dynamic map service into a cached map service in real time too.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.