For geo types, the summary stored in the control fields is not detailed enough to index it directly. Instead, we must transform the definition to use a new internal index type that is aware of the bucket structure. In particular, a measurement field will be present in the bucket document as data.a, but will hold the column-pivoted data for all measurements. Thus a definition:

{
	createIndexes: "abc",
	indexes: [ { key: { "a" : "2dsphere" } } ]
}

will become:

{
	createIndexes: "system.buckets.abc",
	indexes: [ { key: { "data.a" : "2dsphere_bucket" } } ]
}

The new index type will treat the field a as a column of points, and generate a region containing the points. From here out, the solution is the same as for existing geo-type indexes: create a covering for the region (using the appropriate space-filling curve library) and generate index keys from the covering.

The new index type should be considered internal. Attempting to create the new index type directly on a non-bucket collection should result in an error. When examining the indexes on a time-series collection, it should report the original index type rather than the new transformed type. Examining the bucket collection directly should return the new type.