Are the ticks oriented incorrectly?

[CorySimon]

Place your finger somewhere in the interior of the triangle. The way the ticks angle into the boundary of the triangle (the axes) suggests that the composition does not add up to 1.0... I think the ticks are oriented in incorrect angles. Am I right?

import ternary
scale = 10

figure, tax = ternary.figure(scale=scale)
tax.left_axis_label("Component 1", offset=0.15)
tax.right_axis_label("Component 0", offset=0.15)
tax.bottom_axis_label("Component 2", offset=-0.05)
tax.heatmapf(iast_loadings_component_0, boundary=False, 
             style="hexagonal", cmap=plt.cm.get_cmap("Blues"), vmax=10.0, vmin=0.0)
tax.boundary(linewidth=2.0)
tax.gridlines(color="blue", multiple=1) # Every 5th gridline, can be a float
# Set ticks
# tax.ticks(axis='lbr', color="black", linewidth=1)
tax.ticks(axis='lbr', color="black", linewidth=1, locations=np.arange(scale+1),
         ticks=["%.1f" % (1.0 * i / scale) for i in range(scale+1)], offset=0.03)
# Remove default Matplotlib Axes
# tax.line(p1, p2, linewidth=3., marker='s', color='green', linestyle=":")
tax._redraw_labels()
tax.set_title("Uptake, component 1", y=1.08)

tax.clear_matplotlib_ticks()
plt.tight_layout()
plt.savefig("Tertiary_diagram.png", format='png', dpi=300, facecolor=fig.get_facecolor())
tax.show()

[marcharper]

The library uses the same convention as ggtern. Here's an example. There was a long discussion a few months back about how the ticks should work, and it's largely a matter of preference. See #13 and #18.

You can change the orientation with the axis="lbr" option to tax.ticks. If that doesn't work for you, let me know and we can add additional options.

[marcharper]

In the diagram you posted, start at the bottom right corner. Move left 0.2 and up-left 0.2. Then look along the up-right diagonal -- it points to 0.6. So I think the ticks are right from that perspective (but as I said above, it's not the only valid way to plot, just the default).

[CorySimon]

I figured out how to read it with the aid of this site. At least for chemistry, I think the numbers on the axis in the following plot should stay as they are, but the ticks should be reoriented to go along with the respective colors. i.e. they are at the wrong angles.

And, maybe the labels should be at the corner so we know that, at the top of this plot, is pure component 1...

Is there another way to interpret this?

[marcharper]

You can pass clockwise=True to ticks to reverse the orientation (which changes the tick angles).

Adding labels to the corners could be done easily, but it think the plot is clear already -- in the above plot y2 is zero in the bottom right corner, it's equal to one in the left corner. To add labels to the corner points just use the normal matplotlib labels at the appropriate coordinates, something like

x, y = project_point((-1, -1, scale))
ax = tax.get_axes()
ax.text(x, y, "Label", horizontalalignment="center",)

I could add a convenience function tax.corner_labels(label1, label2, label3)
that adds labels at the appropriate points. But if the labels are long they may run into the figures,
so depending on what you want the label to be, the position may have to be adjusted manually. (I think ggtern only handles single characters, but I'm not that familiar with its API).

[CorySimon]

I think you're right about the labels.

I passed clockwise=True to ticks, but I had to reverse the order of the tick labels from [0, 0.1, ... ,1] to [1.0, 0.9, ... ,0.0].

I made the colormap correspond to the uptake of a given component to check the tick labels.

I modified ternary to make each boundary a different color, but it was ugly, by passing a dictionary of colors for left, right, and bottom:

boundary_colors={'l': 'g', 'r': 'b', 'b': 'r'}

I can think of a cleaner way to do it if you are interested.

[marcharper]

I think that's a nice addition -- maybe just a tuple of colors (or even a namedtuple), something like:

>>> from collections import namedtuple
>>> boundary_colors = namedtuple("colors", "left bottom right")
>>> boundary_colors
<class '__main__.colors'>
>>> boundary_colors('r', 'b', 'g')
colors(left='r', bottom='b', right='g')
>>> 

Maybe it's a good idea to modify TernaryAxes to take a namedtuple of colors and use it for both the boundary, interior lines, labels, and ticks as you've done in the figure above.

If that's too much to ask, please just post the code for your diagram and I'll write up a patch.

Also, have you played with the alpha of your interior lines? I think that could improve your plot, and also perhaps increasing the offset for the boundary labels. The plot would make a nice addition to the examples in the readme.

[CorySimon]

I also added a colorbar label for the heatmap and fixed the formatting so it isn't always multiplied by a scientific number (before, it was labeled 0.0 - 1.0 but had a 1e0 at the top to indicate it is a multiple of 1.0).

So do you want me to modify master to change the tick colors and boundary colors, or will you do this? IMO, a dictionary is more popular; I have never heard of the namedtuple until now.

Sure, once you decide on the syntax for changing the colors in the boundaries, ticks, tick labels, I will post my code and a simple function f(x, y, z) to make this example.

[marcharper]

A dictionary is fine. I'm happy to make the necessary changes, but even happier to merge a pull-request from you, since it's really your contribution / idea, and you'll get credit in the repository history.

So if you have the time and inclination, go for it. Just fork the repository and push one or more commits to your master. When you are ready, open a pull-request. I will update the documentation appropriately. Otherwise please just post the sample code and I'll modify the master branch.