Why are xTicks and yTicks set using Math.pow

[boldtrn]

I was wondering if there was a specific reason to change the x- and yTick implementation to use the power of 2? This makes it a) more complicated for to understand how it works, b) makes setting any tick values that are no multiples of 2 more complicated and c) seems like an unnecessary breaking change.

For users of d3 this is also a bit counter-intuitive. If you are used to the exiting x- and yTick arguments of d3, using exponentially growing ticks is probably a bit irritating.

I used to set the tick values to 5. With the new ticks, the almost equivalent value would be 2.33, but I had to look at the implementation to understand what is happening.

[TheGreatRefrigerator]

originally this was the result of setting tick values:
Tick value (always x and y with the same value) 1:

Tick value 2:

Tick value 3:

Tick value 4:

Tick value 5:

Tick value 6:

Tick value 7:

Tick value 8:

Tick value 9:

Tick value 10:

Tick value 12:

Tick value 16:

Tick value 24:

The gap between the values that actually change the placement of ticks grows exponentially, as it somehow snaps to specific values.
By using exponential setting it makes it easier to change the placement with simple values.

In your case you should get the same result (tick values 5 for both)
by setting
xTicks: 2,
yTicks: 3

If you find a value that is not reproducable by the new setting let me know. I tested and couldn't find any. (I also tested for different width and height)

[boldtrn]

In my case, using 5 (as actual input to d3) shows the best results. I cannot get similar results by setting:

xTicks: 2,
yTicks: 3

I also tested for different width and height

I recommend to also test different data. For example short routes, with a lot of elevation change, can result in a different result than a long segment, with almost no elevation change. In my case, I am also using a smaller width and height of the diagram. If you look at routes, for example try some in the Alps and some in the Nederlands.

If you find a value that is not reproducable by the new setting let me know. I tested and couldn't find any.

Well you can get very close to almost every number, if you use floating point inputs like 2.33.

Sorry but I still don't understand why this breaking change was necessary?

IMHO, it would be best to revert this change. Changes in minor versions should be non breaking. If there is a benefit of introducing non-linear axis scaling, we should probably do this in a major version or keep it configurable as opt-in, to have a smooth update experience. WDYT?

[TheGreatRefrigerator]

Sorry but I still don't understand why this breaking change was necessary?

I didn't consider this a breaking change, as during my testing nothing did change. That's why i only did a minor bump.

But in this case we really should postpone this to a major version.

I recommend to also test different data.

This is a good point. Would you be so kind to provide some input data (best as geojson input for the heightgraph) where you experienced differences in the ticks? The dimensions you are using are 400x180 i guess ?

Well you can get very close to almost every number, if you use floating point inputs like 2.33.

I never really worked with d3 myself. To me it appeared that most of the values settable for the Ticks are not necessary.
If there is no change in appearence from xTicks:8 to xTicks:15 it didn't make sense to be able to set these. This was rather confusing to me and the reason why i introduced the change.

[boldtrn]

Sorry this issues somehow slipped through :).

Here are some samples for a randomly chosen route by Kurviger.

x/yTicks = 2

x/yTicks = 3

x/yTicks = 4

My choice was 2.33 which seems to show the best results for a lot of different cases I tested

The dimensions you are using are 400x180 i guess ?

Yes, these are the dimension I use. I attached a sample zip with the json data from the sample above.

kurviger-route-elevation.zip

[TheGreatRefrigerator]

@boldtrn I just wanted to keep you in the loop:
With tick sizes being handled automatically now, you might not have to set x and y Ticks at all anymore.
If you want to test it, just use the latest release and see if it works for you.

It is still possible to set x and y Ticks to overwrite the automatic handling.
I will migrate back to passing the tick values to d3 directly again, soon.

Best regards