Comparative Analysis between gHeat and Google Fusion Tables

[Narinder Kumar]

Hi All,

I am in the process of deciding an appropriate technology for our
project, where we are supposed to show heatmaps of different
activities in a particular geographical region. We will be receiving
the data on a regular basis and would like to present filtered heat-
maps depending upon different user-specified criteria. Ideally we
would like to host this application on PaaS provider preferably GAE.

I had a look at the documentation of Google Fusion Tables and related
FusionTableLayerAPI and gHeat for the purpose and wanted to have your
opinion before spending quite some time experimenting with both the
scenarios. Few questions below would help me decide faster:

1. The documentation mentions that Gheat is probably not suitable for
realtime applications. But Gheat performs well when the underlying
dataset evolves on a weekly or even daily basis. As our scenario
involves real time data and it evolves every 15 minutes. It's roughly
250,000 rows every time. Do you think that it would be a problem in
terms of scale while using gHeat ?

2. I remember having read that gHeat runs with Google Maps JavaScript
API 2.0. Is it correct ? As Google has officially deprecated 2.0 in
favor of 3.0. Has someone tried working with 3.0 version and
encountered some issues ?

3. There is a mention of gHeat for Google App Engine. But the
subsequent pages are empty. Is there some development and testing
being done in that area?

Best Regards
Narinder

[Albert Sun]

Fusion Tables will be much easier to work with as it's basically
automatic. The tradeoff is you get much less (no) control over the
rendering.

1. gheat renders 256x256 tiles for your map. Whether or not it will be
able to scale for you depends on what zoom levels and what geographic
areas your data covers, and the speed of the computers you're using to
render the tiles. I'd advise you to do your own experiments. To
quickly render a lot of tiles it would be good to look into using a
farm of tile rendering servers and an intermediate caching layer.

2. Gheat will work just fine with the 3.0 version as all it does is
make 256x256 png images and put them in a directory with a predictable
naming scheme. Here's the documentation for that.
http://code.google.com/apis/maps/documentation/javascript/maptypes.html#CustomMapTypes

3. Check out http://www.wheredoyougo.net/ which uses gheat for app
engine. (A modified version I believe) The code for gheat-ae is
available http://code.google.com/p/gheat-ae/source/browse/#svn%2Ftrunk%2FgHeatAE%2Fsrc%2Fgheatae
it's just the project summary page that's blank.

[Narinder Kumar]

Many thanks Albert for your comments. I will do further analysis and see what best suits our purpose.

Best Regards

Narinder

--
You received this message because you are subscribed to the Google Groups "gheat" group.
To post to this group, send email to gh...@googlegroups.com.
To unsubscribe from this group, send email to gheat+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gheat?hl=en.

[Steven Lehrburger]

Hey Narinder,

I'm the developer of http://www.wheredoyougo.net/, and my code is on GitHub at https://github.com/lehrblogger/where-do-you-go. I started with the gheat-ae code but modified it heavily so that I could optimize and that my users could customize the appearance of their tiles for the general types of datasets I was working with (Foursquare checkins).

Once you have the 256x256 png overlay tiles it should be relatively easy to cache, update, and serve them regardless of where you're hosting them. The bottleneck I encountered, however, was in generating the tiles itself - tiles with much larger numbers of datapoints took much longer to generate, and even though this scaling is (I think) linear it can become a problem if you have lots of points in a small area at a low (i.e. high-altitude) zoom level. This can create complications on AppEngine which (at least when I was developing on it) restricts the length of time that any HTTP-based process can run to about 30 seconds. So, users of Where Do You Go with large numbers of checkins noticed that some tiles took an unacceptably long time to generate. I'm sure you could work around this by splitting up the math required for the tile generation into multiple processes, but managing these tasks and combining the results would add complexity to your application's code that you might not want to worry about building and maintaining. 

Hopefully that makes sense and was helpful. Let me know if you have any other questions, and best of luck!

Cheers,

Steven