graph3d google visualization dependency about chap-links-library HOT 12 OPEN

we started the visualizations as an extension to the existing google visualization library, using the Google DataTable as data format. We too found the dependency on JSAPI quite a show stopper, as this library is only available online. Not very handy when you have to give a presentation somewhere where you can't rely on a working internet connection, or want to deploy on a closed intranet.
Besides that we found that we typically retrieve data via some JSON RESTful interface, then need to convert to Google DataTable before the data could be displayed in the visualization. Therefore most visualizations by now support JSON as data format too, resulting in better performance. The documentation and examples are still mostly focussed on using the Google DataTable though.

The Graph3d does not yet support JSON as data format. It will not be that difficult to implement this. Internally, the Graph3d already converts the data to JSON already, so mainly the methods that initialize and filter data need to be extended with support for a JSON format.

It is still on our to-do list so if you are not in a hurry you can wait for it, or if you want to implement it I can give you some more details and we can think about the required JSON structure for the data.

from chap-links-library.

Hoi, Jos, thanks for the answer!

As I see from a cursory glance at the code, you use google APIs to:

1. Store, transfer and manipulate the charted data. This, as you say, can be easily substituted for an alternate data structure which can even be designed for performance optimization. Have you anything in mind already?

Obtaining data from a server in JSON can be done by any x-browser AJAX framework. Using google.visualization.Query is just handy because you already have it around for Google's datatable, but most non-trivial sites are already using something like jQuery or extjs that they could also use for this purpose.

2. Fire some events. Again, x-browser event handling is provided by google.visualization.events. In order to make this JS framework-agnostic maybe these events could be substituted by callbacks. Otherwise some small x-browser event handling code could be included, like this one:

http://www.creativemeat.com/development/2012-01-10-oneupweb-cross-browser-event-binding-without-jquery/

Cheers,

L

from chap-links-library.

A quick first draft?

{
  "options": {
    "xMax": ...
    ...
  },

  "dataset": [
    {
      "filter": // Value for animation filtering
      "xAxis": // If not present use global xAxis as defined in options
             // Can be an array of x values or an object defined by:
        {
          "min":
          "max":
          "step":
          "logarithmic": // if true "step" is treated as a multiplier
          // These can also be called xMin xMax xStep xLog for consistency with options.
        }
       "yAxis":
       "data": {
         "xyz": [[xxx, yyy , zzz] ... // Array of xyz tuples.
         "xyzv": [[xxx, yyy , zzz, vvv] ... // Array of xyzv tuples for dot-size and dot-color graphs.
         // Alternative version to save braces and commas for better network performance.
         "x": [... // If not present, xAxis or global options x-axis is used.
                   // MUST be present for "line" graphs.
         "y": [... // If not present, yAxis or global options y-axis is used.
                   // MUST be present for "line" graphs.
         "z": [... // One for each "x" and "y" pair.
                   // If data is using its own axes or global axes to calculate x,y and style is "grid"
                   // or "surface" data MUST be sorted, first by x-coordinate, then by y-coordinate.
         "v": [... // Same as "z" for dot-size and dot-color graphs.
    }  // End of element in "dataset"
  ]  // End of array "dataset"
}

from chap-links-library.

Thanks for sharing your ideas.

About the events: in the other visualizations (such as the Timeline) I implemented a class links.events, which exactly mimics the google.visualization.events class. Maybe best to use that one, so the library as a whole stays consistent. When triggering or registering an event, all you have to do is register to both event busses (when available):

links.events.trigger(this, event, params);
if (google && google.visualization) {
    google.visualization.events.trigger(this, event, params);
}    

About the data format: your setup looks very complete, flexible, and efficient. And it makes sense to me to replace the xMax, xMin, etc with 'xAxis': {'min': ..., 'max':..., }. Maybe it is better to strictly separate data and meta-data into data and options, so not putting axis or label information in the data. I don't think there is need to have both xyz and xyzv, as this distinction is already clear from the style option of the graph.

From a usage point of view I would opt for simplicity. Only having to provide one plain table with data is very easy, and ease of use is one of the key factors of a succesful tool/library. The simplest approach would be:

var options = {
    'xAxis': {
        'min': number,
        'max': number,
        'step': number,
        'scale': string,  // 'linear' or 'logarithmic'
        'label': string
    }
    'yAxis': { ... },
    'style': string,
    ...
}

var data = [
    {
        'x': number,
        'y': number,
        'z': number,
        'value': number,  // optional
        'filter': number  // optional
    },
    ...
]

I would really like to have this simplest format available, so that people can get started very easy without having to deal with 'advanced', nested data structures. Of course from an optimization point of view it makes sense to group the data points per filter value instead of specifying the filter value for each data point. I like your approach of enabling different (more optimized) formats if desired. Something like this, quite close to yours:

var data = [
    {
        'filter': number,  // optional

        // simplest, flat data format
        'x': number,
        'y': number,
        'z': number,
        'v': number,       // optional (need depends on options.style )

        // OR an array with data points for this filter value
        "data": [
            {
                'x': number, 
                'y': number, 
                'z': number,
                'v': number   // optional (need depends on options.style )
            }, 
            ...
        ],

        // OR an array with numbers (most efficient qua data size, but not qua data processing)
        // -> will this format be useful in practice? it is harder and slower to process, 
        // and I don't think it will save that much bytes.
        'x': [number, number, number, ...],
        'y': [number, number, number, ...],
        'z': [number, number, number, ...],
        'v': [number, number, number, ...],
    },
    ...
]

this format enables both simple and advanced+optimized data structures, without the advanced format getting in the way of the simple format.

from chap-links-library.

About the events: in the other visualizations (such as the Timeline) I implemented a class links.events

That looks like a perfectly acceptable solution.

Maybe it is better to strictly separate data and meta-data

Agree, but I must specify I was thinking of the axes contained in the data not so much as instructions on how to draw the lines that represent them, but more like "x" and "y" coordinate generators. Cartesian graphs will probably be a very common use case. For a 50x50 linear grid, defining x and y coordinates for the whole graph will take a few values: max, min, step... Then you only have to define "z" values. Specifying all x,y,z coordinates for every single point can get highly redundant.

   // OR an array with numbers (most efficient qua data size, but not qua data processing)
   // -> will this format be useful in practice? it is harder and slower to process, 
   // and I don't think it will save that much bytes.

Well, premature optimization is the root of all evil, and all that. I have the gut feeling that, even if the web server uses gzip compression, shaving a few KB in a JSON transmission will improve the user experience more than saving a few thousand CPU cycles, especially for mobile users. But I haven't any measurements to back up this statement.

Anyway, since I am not using events of filters, for the time being I have chosen to circumvent Google dependency by the expedient of:

• Declaring a null google.visualization.events.trigger function. I could overload it with something more useful, but I can live without events for now.
• Adding my own getNumberOfRows, getNumberOfColumns, getColumnRange, getValue and getColumnLabel methods to my data object.

This suits my purposes good enough and gives us time to think about future developments.

from chap-links-library.

Thanks for your clarification. I'm glad you have a nice workaround by mimicking your data to be a Google DataTable.

it is indeed hard to tell what kind of optimization is "best": saving data size, or saving cpu, as there is not a single correct answer to this. It depends on the situation, and will certainly change over time with rolling technologies. So it is best to design the data format such that we leave this choice open to the developer, which can decide depending on his situation.

It makes sense to reckon and allow for different types of datasets such as the common cartesian grid, but maybe later-on for other types/scales/coordinate systems like a polar graph. Good to keep that in mind.

from chap-links-library.

Hi thogether,

I know, it's a one year old thread, but I hope someone can help me out.

I'm playing around with graph3d and find it great! But I'd like to use it for an applications that needs to be used offline and online. So the usage of google visualization is a great problem for me. When I read your disscussion I hoped for a solution...

@josdejong: are you working on this issue? Is a solution on the way?

Thanks in advance,
Maria

from chap-links-library.

Hi Maria, this solution is not yet implemented: Graph3d still only supports Google DataTable and not yet JSON. There are no concrete plans to implement this (though still it is on the to-do list).

from chap-links-library.

Hi Jos,
thanks for your fast replay! Today, I allready wrote workaround replacing the necessary functions to use it offline.
best regards

from chap-links-library.

@MariaPa do you think you could share your solution? I'd be very interested. :)

from chap-links-library.

Once again, starting up an old thread, but I found this solution to the be the easiest for offline usage of graph3d. If you simply grab Google's jsapi, visualization, and visualization en (or whatever language you use) in a manifest file, then you can use it offline. The XAMPP/WAMP/LAMP stack now is automatically configured to properly serve the manifest MIME, so if you are using an up-to-date build of your server, you shouldn't have an issue.

The first two lines in my HTML file now look like:

<!DOCTYPE HTML>
<html manifest="cache.manifest">

And my cache.manifest file looks like:

CACHE MANIFEST
CACHE:
http://www.google.com/jsapi
http://www.google.com/uds/?file=visualization&v=1
http://www.google.com/uds/api/visualization/1.0/dee027d0b48a2e0a0a0375d00d7dd635/format+en,default+en.I.js
graph3d.js
favicon.png
playground.js
csv2array.js
playground.css

from chap-links-library.

Thanks Michael, that's a smart idea!

Besides that, for offline usage you can use the ported Graph3d in vis.js, which uses a JSON data format instead of Google DataTable.

from chap-links-library.