Google AnnotationChart with only points - charts

Has anyone ever figured out how (if possible) to remove the connecting lines on a Google AnnotationChart?
My goal is to create a scatter plot where the x-axis is time data and the y-axis displays annotated values.
I could use a ScatterChart (or even perhaps a BubbleChart), but the killer-feature of AnnotationChart is the time-aware x-axis and the zoom/scale/scroll feature along that time axis.
I tried hacking around this by turning the option colors to white (the background color), but that also turns all points/annotations to white.
Similarly, there's a line thickness option, but the default (0) is already set and has non-zero thickness.
Other values for thickness I tried: null, undefined, -1... none had any effect.
Any ideas?

Related

How do I add a categorical legend to a double line graph in Tableau?

Here is my Current View
I'm wanting to add a legend to distinguish between members(yellow line) and casual riders (blue line) so viewers can see which line is which.
Seems like this should be simple, but I feel like I've tried everything. The closest I've come is by getting a legend to pop up by dragging measure values over to the color, but then it changes my colors that I have already established and syncs both lines as the same color or gradient of colors. All I need is a legend detailing which line is which.
Instead of individually changing each line's color, place Measure Names in the Color shelf of All marks card. This should make the legend appear on the right.

Draw a line and color it based on direction

Is it possible to draw a line similar to the example below and color it based on the previous value?
So to have the color red when the line is moving down and green when it goes up.
Can this be done with line type? Or does it need to be drawn with markLine or something else?
Any help is much appreciated!
https://echarts.apache.org/examples/en/editor.html?c=dynamic-data2
I don't think it is possible with the line chart, as the whole line uses the same color for all points. I suggest you use a scatter type chart where each point can have a different color. By setting symbol size to a small value and drawing values close together you can emulate visual line.
Here is an example based on the regression sample from echarts site:

Make contour labels point uphill: reverse direction of text label on line feature

I am designing a map in Mapbox Studio, using mapbox.mapbox-terrain-v2’s contour layer to determine the contour lines. This is based on the outdoors style.
In the outdoors style, the contour labels are oriented so that the text is displayed between -90° and 90° of horizontal, because Keep Text Upright is set. If I disable this, then the text becomes oriented at any angle. However, this text is oriented at exactly the opposite angle to what I would like: it always points downhill, not uphill. See first image below: note that the numbers are upright where the elevation increases from north to south.
What I am aiming for is to use the Ordnance Survey style of orienting numbers uphill (upright where the elevation increases from south to north), as in the second image below.
My current style can be seen here. I have tried using the text-rotate field, but this rotates each character individually, and there does not appear to be a function to reverse the string to counteract this. Additionally, this rotates about the top of each letter, meaning that the result is offset from the actual contour line, and text-translate + text-translate-anchor seem unable to resolve this.
As you noticed, using text-rotate on a symbol layer with placement: line rotates each character individually. So you would need to then reverse the string, which isn't possible within the expressions available.
However. There is one hacky workaround which may solve the problem for you. You can simply hardcode all the possible elevations with their reversals:
["match", ["get", "ele"],
750, "m057",
700, "m007",
650, "m056",
600, "m006",
550, "m055",
500, "m005",
""
]
Combined with a text-offset of 0,1.5, this actually looks alright:
I've published the style here

Custom number format for y-axis on Chart

I have created a chart with 2 axes that acts as a panel chart (see image)
As a panel chart I only want to show the portions of the relevant y-axes to the chart next to them. For example, for the right-most y-axis I used a custom number format to exclude anything less than 0:
_(* #,##0_);_("";_(* 0??_);_(#_)
But for the left most y-axis, I'm stuck. I want to show -400 to positive 400. I've tried 2 different options, but neither is producing the desired effect.
[<0](#,##0);[>500000000]"";#,##0_)
[<0](#,##0);[<500000000]#,##0_);""
Here is the result I'm looking for:
I learned something new today (and a bit weird) regarding formats and chart axes
After some experimenting, this is what I ended up using:
[White][>500]_(#,##0_);(#,##0);0;
The odd part: When you change the Display Units of the axis (for me, millions), then the formatting no longer recognizes the original amount (500,000,000).
Once I figured that out, I was able to work out the solution.

Sigmaplot: How to scale x-axis for correctly displaying boxplots

I want to display overlapping boxplots using Sigmaplot 12. When I choose the scale for the x-axis as linear then the boxes do indeed overlap but are much too thin. See figure below. Of course they should be much wider.
When I choose the scale of the x-axis to be "category", then the boxes have the right width, but are arranged along each single x-value.
I want the position as in figure 1 and the width as in figure 2. I tried to resize the box in figure 1 but when I choose 100% in "bar width" than it still looks like Figure 1.
many thanks!
okay, I found the answer myself. In Sigmaplot, there is often the need to prepare "style"-columns, for example if you want to color your barcharts, you need a column that holds the specific color names.
For my boxplot example I needed a column that has the values for "width". These had to be quite large (2000) in order to have an effect. Why ? I have no idea. First I thought it would be because of the latitude values and that the program interprets the point as "1.000"s, but when I changed to values without decimals, it didn´t get better.
Well, here is the result in color.
Have fun !