API return needs to include nodes_at_patch and corners_at_cell

[gregtucker]

Currently, the API returns attributes such as x_of_node and faces_at_cell, but nodes_at_patch and corners_at_cell seem to be missing. This is likely because these two attributes are not included in graph's xarray dataset ds (or at least that is the case for DualUniformRectilinearGraph).

[mcflugen]

You are correct. nodes_at_patch is not included in the graphs data structure as it's a derived quantity. One can get nodes_at_patch from nodes_at_link and links_at_patch. When the nodes_at_patch property is accessed from a landlab Graph, it is calculated and cached so that it doesn't have to be recalculated.

Is this something we need to include in the response? Is there anything else?

[jennyknuth]

It turns out that for most grids, I can derive nodes_at_patch from links_at_patch (same for cells/faces) pretty easily MOST of the time, but since the links (and faces for cells) are directional, it is tricky to figure out the correct index of the link for the order of the nodes. With the simple method I came up with, I could easily get the coordinates of the nodes, but the order of the nodes was not predictable for drawing a polygon in the radial grids. It worked for hex and raster grids. I'm sure I could make a function to overcome this, but if nodes_at_patch and faces_at_cell are already available, would it be better to just use them from the source rather than trying to recreate them and needing to know the directionality of the links and faces?

Let me know if that makes sense.