Labels should not overlap about cedar HOT 15 CLOSED

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

Narrow:

medium:

wide

cedar

• 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.