Coordinate Creation Spec about podpac HOT 8 CLOSED

@mlshapiro @mpu-creare I think we overlooked adding this issue. It needs to be assigned to someone and then the spec approved by the group.

from podpac.

A few thoughts:

• I think the version in develop is appealing because all of the coordinate creation options are in one place. However I think the code is hard to follow and hard to test, and the documentation and usage overwhelming.
• I think my PR #44 is appealing because the Coordinate init is simple and explicit and the coordinate factory is flexible and concise, so that both are easy to read, document, and test. The explicit dictionary argument required in init makes sense because it exactly matches the stacked_dict property.
• I think Marc's proposal is appealing in the way it mirrors xarray.DataArray init and avoids keyword arguments. The values argument matches Coordinate.stacked_dict.values() and the labels argument matches Coordinate.stacked_dict.keys() (with the additional change of stacked keys being changed from underscore-separated strings to tuples, which is a separate concern).

from podpac.

An example of another helper function:

Currently you can create stacked uniform coordinates several ways.

Coordinate('lat_lon'=(coord_linspace(0, 1, 10), coord_linspace(0, 2, 10)))
Coordinate('lat_lon'=((0, 1, 10), (0, 2, 10)))
Coordinate('lat_lon'=((0, 1), (0, 2), 10))

The first two use a tuple matching the dimensions, with the second using the existing shortcut that maps to coord_linspace. The third one is an entirely separate case requiring a separate code path (plus tests and documentation) in coordinate creation. Consider replacing it with a helper function stacked_linspace that returns a tuple of UniformCoord objects (just like coord_linspace returns a single UniformCoord object).

Coordinate('lat_lon'=stacked_linspace((0, 1), (0, 2), 10))

I don't know, I was sort of just trying to think of another helper function. Maybe the names aren't quite right, or coord_linspace itself should handle both cases. But I thought it was worth writing down.

from podpac.

I added a stub for the spec here: 4fa87ab
Jeff, have a go at it. Half time on this, half time on the unit tests.
I'll try to get to your PR later today or tomorrow.

from podpac.

@mpu-creare @mlshapiro I pushed an updated (partial) spec to develop. I will probably flesh it out a little bit more on the airplane tomorrow, and possibly here and there I'm out the next two weeks, so take a peek again and let me know what you think.

Still need to do:

• Coordinates methods
• rotated coordinates
• default ctype, etc handling (I get why the current solution doesn't really work anymore now)
• coordinate evaluation rules, with regard to native coordinates (though this may more properly go in the node spec)

I'm particularly interested in the two downsampling examples at the bottom. The question applies for any indexing of stacked coordinates. It suggests to me that we should have a lightweight class StackedCoordinates. It would behave like a dictionary or tuple of Coordinate1D objects but also spit out the combined dims name (with underscores), the size, etc and handle mapping intersections, indexing, etc. We would probably still have the stacked function which would just alias StackedCoordinates, and the stacked_linspace helper function would return a StackedCoordinates as well. Is that something I should pursue? @mpu-creare do you anticipate any major cons, from your experience?

from podpac.

I added a proposal for the StackedCoordinates to the spec. It would behave just like the tuple we are using now with a few additional methods and attributes. I added a BaseCoordinates1D class that contains the common interface for both the ~Coordinates1D and StackedCoordinates classes:

• size
• name
• indexing with []
• select and intersect

The main thing I still need to do is add the intersect and select methods. I started some of that, and I hope to have the rest in a few days. In particular, now that now that the Coordinates1D are named, it opens up some new possibilities and issues.

from podpac.

@mpu-creare Do you want to continue this issue as the coordinate refactor that implements the spec as well? Or should I start a new issue for that, and try to wrap the spec with the notes from our in-person meeting so we can close this?

from podpac.

Start a new issue... in fact, you could do a WIP PR.
Do please wrap in the notes from above so they don't get lost.

from podpac.