-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
graph3d google visualization dependency #16
Comments
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. 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. |
Hoi, Jos, thanks for the answer! As I see from a cursory glance at the code, you use google APIs to:
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.
Cheers, L |
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"
} |
Thanks for sharing your ideas. About the events: in the other visualizations (such as the Timeline) I implemented a class
About the data format: your setup looks very complete, flexible, and efficient. And it makes sense to me to replace the 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:
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:
this format enables both simple and advanced+optimized data structures, without the advanced format getting in the way of the simple format. |
That looks like a perfectly acceptable solution.
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.
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:
This suits my purposes good enough and gives us time to think about future developments. |
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. |
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, |
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). |
Hi Jos, |
@MariaPa do you think you could share your solution? I'd be very interested. :) |
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:
And my cache.manifest file looks like:
|
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. |
Hi! I find graph3d a really nice, useful contribution, thanks for sharing it! However, its dependency on google visualization is rather inconvenient since it prevents offline usage, which may be important in certain situations.
Before digging deep into how to remove this dependency by myself I'd like to know from the original developers if they have any advice on this issue. Is the coupling with GVA loose enough that this separation can be achieved with a reasonable effort? Any pointers you would kindly want to share?
It goes without saying if I finally decide to undertake this project and I am successful I'll be happy to share any results here.
Thanks in advance,
L
The text was updated successfully, but these errors were encountered: