Comments (15)
I think this is how long labels should behave (word-wrap when needed, then eventually if you make it too small, automatically rotate):
http://jsfiddle.net/nmsxtx02/1/
from cedar.
@abakirov super nice in theory, but so many use cases where this won't work, like when there's too many bins, or the chart is narrower. In trying to avoid adding logic to cedar to determine when to rotate labels, we've shifted to defaulting to a rotated label, and if users/devs want to override that option based on their app, they can.
Here's an example, using the dataset you are using above: http://esri.github.io/cedar/examples/style-overrides.html
from cedar.
Well, this is not a theory, this is real charting library (pretty good one!). If chart becomes narrower, every other label disappears and becomes available only as tooltips.
Looping in @arthaddad and @HeikoH for input/thoughts.
In our case data comes from user and it is our responsibility to take care of label placement. I don't like the fact that we will have to implement our own logic to decide when and how to word-wrap or rotate labels.
Speaking of word wrapping... SVG/Canvas does not even support automatic word wrapping. This has to happen on d3 level as indicated in this example:
http://bl.ocks.org/mbostock/7555321
from cedar.
Yep, well aware of high charts, and use it all the time. Fact is there's a lot of charting libraries out there that are great and have already resolved a lot of these issues.
This seems like more of a philosophical question on what we want Cedar to be, and if we want it to be High Charts, why aren't we just using High Charts? To me the power of Cedar has always been the template, which allows you to pretty much make any type of chart with any definition you could possibly one. The other power of Cedar is the ability to supply a feature service URL get get a chart in return, without any of the logic needed there. As soon as Cedar starts trying to address all the use cases, it gets more complicated. So I've tried to address it as -- Cedar needs good defaults, but let's minimize the logic side.
Now, maybe this isn't the best approach, and we need to continue to add more logic to Cedar-core (pull requests accepted!), but if that's the case I think we need to make a conscious decision to do so, and make sure what Cedar/Vega is, makes sense.
I'm sure @dbouwman and @ajturner have thoughts here.
from cedar.
I think the idea of template-based charts that automatically connect to feature services is very good. And the idea of company-wide defaults for charts also makes total sense.
Just want to propose maybe consider evaluating other charting libraries, not Vega, to use as rendering engine. Obviously, there are good commercial libraries out there but maybe there is also a free open source library that already handles sizing and labels positioning correctly (or at least better than Vega does it).
from cedar.
Let's work with the Vega team to improve the engine.
Clearly automatic label layout is not a difficult capability - it just needs to be slightly abstracted, perhaps as a Vega JSON parameter and the implemented in that engine.
In fact, first would be testing the latest version and the v2 branch of Vega. If not, then let's submit an issue in their repo and work on a PR together.
There are many reasons for Vega in particular - including headless rendering, compatibility with R, Python ports and the very advanced scene graph generation that abstracts rendering from layout logic - portable to WebGL and Native runtimes
from cedar.
More screen captures of the issue:
http://services.arcgis.com/qvVnajWeXlTaQQu1/ArcGIS/rest/services/sf_custs1/FeatureServer/0
http://services.arcgis.com/pmcEyn9tLWCoX7Dm/arcgis/rest/services/uwAeJ/FeatureServer/0
from cedar.
from cedar.
@tomwayson I'm working on this issue now - to do the label placement & orientation I'll need to calculate statistics on the tick labels.
So I want to capture this data - seems like in Cedar.update that the data are not being retained.
Do you see any issues with keeping the data in an object? Could be a bit of memory, but flush it on updates.
from cedar.
Renamed the issue... it is not enough to only resolve this for bar chart and specific dataset by rotating labels. There needs to be a generic solution so that labels never overlap, regardless of chart type, chart size, and data set. This is key, fundamental requirement for a charting library.
from cedar.
thanks for the input @abakirov - we'll continue to investigate this and develop heuristics for label placement and truncation
from cedar.
assigning to @phlorah and @ddred11 to document the heuristics for label logic.
decisions need to be made on "too scrunched" "label orientiation" "truncation" "hiding labels", etc.
from cedar.
@phlorah @ddred11
Just wanted to re-iterate on my earlier proposal to just do what this other charting library does:
http://jsfiddle.net/nmsxtx02/1/
Note how nicely they handle labels.
You can resize output pane to see how labels respond:
from cedar.
just capturing examples of Highchart logic for @ddred11 design @phlorah heuristics
- differences: high-chart rotates Counter-clockwise; cedar rotates clockwise.
- CCW takes advantage of Y-axis spacing
- high-charts does string truncation. Cedar does not automatically
from cedar.
closing this large issue - we can open specific ones as they come up (and I know there are a few)
from cedar.
Related Issues (20)
- Add to doc - examples of changing data formats HOT 1
- Please show examples using ArcGIS API for JavaScript version 4.x HOT 3
- Capability to Convert Between Units? HOT 2
- deploy v1 docs
- domains are not decoded for datasets that don't query features (i.e. use `data`)
- fetching chart JSON from "CDN" returns 404 for v0.x HOT 8
- give @jgravois the keys to publish arcgis-cedar on npm HOT 1
- definition should provide a way to specify or override default axis labels
- how to set up cedar properly to chart object arrays? HOT 2
- Cedar not working - TypeError: keys.reduce is not a function HOT 4
- add repository.directory to packakge.json
- Sparkline Support
- Chart not rendering data correctly HOT 2
- change color of data series
- Cedar with React HOT 3
- number format issue HOT 5
- export button HOT 1
- add function that converts the chart data/series to a feature set HOT 1
- Allow passing request options to query HOT 1
- UMD bundles include arcgis-rest-js dependencies HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cedar.