Mechanism for specifying which dimensions a transformation applies to

[maxrjones]

It's ambiguous in the current specification which dimensions of an array the factors, scale, and translation apply to. There are at least two solutions:

1. Require the length of the factors, scale, and translation array to match the number of dimensions in the array.
2. Provide a way to specify which dimensions that factors, scale, and translation apply to.

I would lean towards option 2 to for more flexibility, even though it will likely lead to more redundancy with the geo-proj metadata for geospatial overviews.

[kylebarron]

This comes up in this example:

multiscales/examples/array-based-pyramid.json

Lines 16 to 39 in 317be3b

	{
	"asset": "0/data",
	"transform": {
	"scale": [1.0, 1.0]
	}
	},
	{
	"asset": "1/data",
	"derived_from": "0/data",
	"transform": {
	"scale": [2.0, 2.0],
	"translation": [0.5, 0.5]
	},
	"resampling_method": "average"
	},
	{
	"asset": "2/data",
	"derived_from": "1/data",
	"transform": {
	"scale": [2.0, 2.0],
	"translation": [0.5, 0.5]
	},
	"resampling_method": "average"
	}

I'm guessing that the meaning of the translation: [0.5, 0.5] is that "offset by half a pixel because this array is averaged from the more detailed array".

Then there's a difference between having 2/data derived from 0/data or 1/data.

As it stands, this:

multiscales/examples/array-based-pyramid.json

Lines 31 to 39 in 317be3b

	{
	"asset": "2/data",
	"derived_from": "1/data",
	"transform": {
	"scale": [2.0, 2.0],
	"translation": [0.5, 0.5]
	},
	"resampling_method": "average"
	}

could be valid (whereas in #32 I assumed it was invalid) because it means "scale by an additional factor of 2 from 1/data, after 1/data was already scaled by a factor of 2 from 0/data.

So in effect you currently have to walk a tree of derived_from values to asset keys to build the effective transform.