Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I am wondering how useful would you find to have a way to deliver map tiles quickly over the web without worrying about caching or seeding them?

With raster map engines we know that this is a problem. Rendering raster tiles is resource consuming therefore it is often required to cache them in advance. Every time map changes map tiles should be recreated and cached if you want to have them quick delivered.

We focus to overcome this issue by rendering map tiles quickly in real-time as vector tiles. What do you think about this approach?

Here is a benchmark that we did:

http://www.giscloud.com/blog/realtime-map-tile-rendering-benchmark-rasters-vs-vectors/

Thanks!

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.

2  
It's interesting to see other options available, but this "question" feels more like an ad for your service. –  Michael Todd Nov 9 '10 at 23:57
1  
There are already existing software packages that serve GIS data with dynamic rendering (i.e. "real-time"). This does not seem like a question so much as a promotion. –  zwaap Nov 10 '10 at 0:40
1  
I understand this can sound like an ad, but vector tiling is something that could be interesting for GIS on the web. It is not common so I thought it could be interesting topic to discuss. We are not the only one doing it, there are Polymaps, NAVTEQ has vector engine, etc. –  Dino Ravnic Nov 10 '10 at 1:02
2  
still sounds like an ad to me. –  iant Nov 10 '10 at 19:44
2  
But no one from ESRI is posting "questions" about their products. –  iant Nov 11 '10 at 15:11
show 1 more comment

3 Answers 3

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.

EDITION: added 2010-11-10 16h41 CET

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.

EDITION: added 2010-11-10 17:16 CET

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
1  
Thanks for the feedback. I'm glad that there is interest for discussion rather than wondering if this is or isn't an ad :) –  Dino Ravnic Nov 11 '10 at 3:14
    
We use Flash as map engine so it works well in any browser because Flash is running as Adobe plugin. Regarding TileCache and map change: what if you change entire symbology? Like color? Feature expressions? Then you need to refresh all tiles and then you have a problem. –  Dino Ravnic Nov 11 '10 at 3:26
    
We also find that vector-raster combination is a winner. That is why beside vector engine we support raster as well through mapnik and mapserver. It is easy to change engine per layer. –  Dino Ravnic Nov 11 '10 at 3:27
    
PNG and GIFs can be light but packed vectors are lighter please check here: (PNG 30KB) giscloud.com/rt/1289393990/895/9/155/190.png (SWF 11KB) giscloud.com/vt/1289393990/895/9/155/190.swf –  Dino Ravnic Nov 11 '10 at 3:27
    
I don't know for other vector engines but we render vector tiles from optimized metadata which resolves problems of slow DBs etc. So tiles can be produced much faster as it is shown in the benchmark. –  Dino Ravnic Nov 11 '10 at 3:28
show 1 more comment

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
    
It is possible to render i.e. pack vector tiles with complex data as well. The key is to optimize, because having vectors can be cpu intensive. Benefit of rendering vectors is that they can be "packed" much faster than raster tiles can be rendered. –  Dino Ravnic Nov 10 '10 at 1:07
    
btw. here is one mapping portal done entirely in vectors: karte.hr –  Dino Ravnic Nov 10 '10 at 1:10
    
Complexity of the data isn't really a big deal to me. Computers are really good at, well, computing. It's the complex decisions that get made in order to draw a map - that's not something I want to leave until the last minute. Computers are notoriously bad at making intelligent decisions, mostly due to our habits of throwing unexpected conditions at them. –  mwalker Nov 10 '10 at 17:56
    
By using smart algorithms we can make them make "intelligent" decisions. Render geospatial data as vectors is not easy. In our case we are doing allot of optimizations to achieve best ratio between quality and speed. –  Dino Ravnic Nov 11 '10 at 3:31
add comment

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. http://www.arcgis.com/home/item.html?id=48bf53da123e442ab8ac9aed52747552

share|improve this answer
add comment

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