Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I need to use JavaScript based charting library. There are lots of good JS library for charts:
D3.js
Google charts
ChartJS
n3-charts
EmberCharts
Meteor Charts
HighCharts
and so on....
While these libraries provide lots of options, it also creates confusion, it’s really hard to pick right chart for your data.
I have following questions:
Is there any guideline for selecting charts based on data?
How do you categorize your data? I am getting JSON data from a web service, Data can be multi-dimensional. There is no restriction on no. of columns and no. of rows. If data is too large, does it make sense to prevent users from selecting some charts?
There's two ways to understand your question, and both involve very complex answers.
Choosing the right visualization
Whole books have been written on the topic. One of the best guides that I know of is SeeingData's Inside the Chart series. They have an article for each of the more common chart types (bar, pie or radar charts, scatterplots etc.), each detailing what you can see in it, what data it is for and what kind of information it can hide.
As a rule of thumb, if you have a lot of continuous data, like a time series, use a line chart. If you have few datapoints or the data is discrete, bar chart is there for you. Use stacked variants if you're presenting shares (although stacked line chart, or area chart tends to be hard to read). If presenting correlation, use a scatter plot. Changes and differences are best shown on a slope graph. Showing ratios of a single datapoint? If you have just two or three competing fields, use a pie chart, for more elements, a single stacked bar is usually a better choice.
There are more types of graphs, but unless your readers are adept in statistics, they probably won't be able to read them. Remember that it's your responsibility as an author to choose the correct graph type, which does not mislead the readers and which communicates the story of the data the best. Note that there might be more stories in one dataset, hence more graphs, more views of it.
A more general advice is: don't be creative. Good intentions (I want my chart to look cool) often lead to disasters, like this misleading Gun deaths in Florida chart. Just stick to the basics, don't do fancy faux 3D charts and let the data speak for themselves. As Edwart Tufte put it
Show data variation not just design variation
Choosing the right visualization library
Main factors are your requirements, complexity of the task and your coding skills. Google Charts is an online Excel, you click your mouse a couple of times and out comes a decent graph. However, your customization options are very limited, if you don't like the output, you'll have to look elsewhere.
D3.js on the other hand is a low-level tool with quite steep learning curve. It takes a better part of the day to make your first bar chart. Most important fact is, it's not a graphing library, it's data driven documents library. Yes, it does have some helper functions for graphs, but you have to construct them from scratch and it takes a lot of time and effort. You need to know your SVGs, HTML and CSS, as that's what you'll be manipulating. The reward is its extreme flexibility, you can make whole apps based on D3. With skill, it can completely replace jQuery. It's a lot more and a lot harder than a simple pie chart generator.
If a simple pie chart generator is what you want, but Google Charts don't offer the options you need, then the true graphing libraries like Highcharts are for you. They take data in a lot of formats, let you choose the basic output type (eg. pie vs. bar chart), do a little bit of customization and off you go. It's the middle ground.
I don't use the framework-specific libs like n3, Ember or Meteor charts, but I'd guess they fall closer to Highcharts than D3. Just check if all you need is to supply data and a configuration object, or if you're down to creating and setting up individual SVG DOM nodes.
Generally, if don't know what to choose, go from the least complex ones. Try to make it in Excel first. Then in Google charts. Then learn some JavaScript and try the Highcharts or your framework-specific library. And only if you still need more options go for the big guns like D3.
Related
My graphs currently indicate "no data" by calculating the holes in my datasets, then generating a new fake dataset that ranges from nil to max(all-y-values), thus making it look like a full-height background. I make it an "area" dataset and apply an SVG pattern to make it look like this:
The problem arises when the y-axis scale is greater than the data, in other words when max(all-y-values) doesn't coincide with the top of the graph.
I need to make these shaded background intervals always the full height of the graph, and I'm willing to rethink the whole process of adding them.
My recent attempts have been trying to follow the "filling an area above the line" example described in D3 Tips and Tricks as well as the NVD3 documentation and various other resources, but I haven't seen anything working.
This is the "filling an area above the line" example from that link:
Any solution must either use ClojureScript and Om or at least be directly compatible with them, since I already have a proof of concept in the above links and I am looking for more.
I am looking for a way to create a visualisation of live data (temp., humidity) from within a multi-story building overlaid on the floor plans. Each floor will likely be a projected iso view, laid over one-another.
I will most likely be using D3.js for the plotting, but am open to others.
I am currently considering two options:
using a 3D plot projection, and adding the floor plans as custom data.
creating custom TopoJSON files for each floor, and using a custom projection.
I am leaning toward the former.
Has anyone done any similar projects using purely indoor geospacial information? I can't seem to find any examples.
Any thoughts on which of the above two, and any other alternatives, will provide a more elegant or simple design?
I am new to d3 geo. My task is to make a map of Boston and add some interactive features to it.
So far I've been able to get an outline of Boston. But the base map should be comparable to something you'd see in Google Maps - it should have buildings, roads, street names and city names, rivers, etc. A basic geography that makes the region more familiar.
For now, I don't need to pan, and may have just two or three zoom states.
All the visualizations I've seen that overlay interactive features onto maps like this seem to use images for the underlying maps: windhistory, polymaps, google maps and more. So I guess my questions are:
Why do some maps use images for the "backdrop"? Is it just the easiest way to build on top of existing maps? Is it more performant?
If I go with the images approach, are there any limitations to the features I can add? I'm hoping to do things like windmaps, animations, heatmaps, etc.
What are the copyright implications for using images? I imagine the answer to this is, "depends on which images I use," but are there some standard libraries that have no strings attached? For example I know if I use Google Maps, I have to display their logo, there's an API limit, etc. Are there any standard sources that are completely open?
Are there any examples where geography is added purely through TopoJSON?
Sorry if some of these seem obvious, but I am completely new to maps and just don't know the standard practices. Thanks for any help!
A quick take on your questions. Hopefully someone with more mapping experience can give you more detail:
Why do some maps use images for the "backdrop"?
File size and computation time, mostly. Drawing complete maps with buildings, roads, and topography requires a lot of data and a lot of time for the browser to render it. If your browser DOM gets too complicated, it can slow down all interactions even after the original drawing.
If I go with the images approach, are there any limitations to the features I can add?
There's a reason most interactive maps use multiple layers. The background images are best for the underlying "lay of the land" type imagery, anything you want to be interactive should be on top with SVG.
What are the copyright implications for using images?
If you're using someone's images, you have to follow their licence. You might want to look at the OpenStreetMap project.
Are there any examples where geography is added purely through TopoJSON?
I suppose that depends on what you mean by "geography"; Mike Bostock has generated topoJSON for a variety of features based on US Atlas data.
As for whether it makes sense: TopoJSON encodes paths/boundaries directly, and encodes regions as the area enclosed by a set of boundaries. You could use it to encode streets and rivers and even building outlines, but you're not saving any file size relative regular GeoJSON because those paths generally aren't duplicated the way that region boundaries are. Relative to using image tiles, any improvement in file size would be countered with increased processing time.
Disclaimer: I'm an absolute d3.js n00b. I'm beginning to become proficient in JavaScript, but d3.js is giving me a bit of a headache.
I've a project I want to do, quite similar to The Art of Asking. I have a lot of data to show - I have to go down to the parliamentary/congressional district level for a few countries, not just provinces or states - and trying to load all the SVG elements kills a few lower-end computers I've been testing the project on. I rather would like it if I didn't explode any computers. (Actually, I'm pretty sure not exploding computers is a requirement of my project.)
To work around this, I figure that doing a hide/show mechanism like The Art of Asking is the path of least resistance, but while I can figure out how to hide an element, I haven't a clue how to show it after it's been hidden. I think creating a map that acts like a collapsible tree would be similar to what I want to do, but I could also just be going in the wrong direction entirely.
I'm thinking of what would be the right terms to use in the UI of my new program, when referring to graphical data representations - i.e., whether to call them "charts", "plots" or "graphs". I was wondering how these terms are different, and when is it appropriate to use each of them?
Chart: Bar, line, or pie charts.
(source: jpowered.com)
(source: jpowered.com)
Plot: X-Y plot or blueprints.
(source: grass.itc.it)
Graph: Nodes connected by edges.
(source: graphviz.org)
I feel your pain. Google searching on these words lately for software libraries was quite difficult due to the overlap in their usage.
Elementary school kids are taught that "graphs" are two dimensional grids used for "graphically" displaying math functions. Yet "graph theory" is about networks, not functions; see graphviz.
Business graphics calls a representation using symbols a "chart," such as a pie chart or bar chart, yet a stripchart is a type of plot.