Node bounds attribute about podpac HOT 5 CLOSED

This would be my preference:

bounds, crs = node.get_bounds(crs=...)
# where crs in ['native', 'default', 'EPSG,...'])
# Default is 'default'
# if 'default' uses `podpac.settings['DEFAULT_CRS']
# if 'native' uses the Datasource or TileCompositor's native coordinates. If node is neither of those, raises an exception. 
# otherwise, return bounds in the requested CRS

from podpac.

@drc-creare the immediate goal of this issue is to support the WCS getCapabilities. I plan to return a dictionary {<dim1>: (<lo>, <hi>), `: (, ). Does that work for you? I know you ultimately want a bbox, but I think you can make that yourself from that dictionary.

What is a good spec for a Node that supports all times (because it is an algorithm, for example)?

Do you need resolution, too, or is the bounds enough?

from podpac.

@drc-creare Also, let me know if you think a method get_bounds is more appropriate.

from podpac.

@jmilloy The dictionary works, its easy to construct a bounding box from there. Reporting min and max is sufficient, but if step (e.g. resolution) can be reported, I believe that could be used as well.

Yeah, all-times is an interesting case. It looks like we report basically minimum and maximum possible value for things like elevation (see xml example below). Maybe datetimes have min/max values supported by the underlying data types. For an algorithm, if min/max can be bounded based on bounds of the inputs, then it would be nice to know that.

Is the difference between get_bounds and find_bounds that the latter would dynamically adapt to changes in the underlying data (e.g. as new data points are added over time the find_bounds would include those)? In that case, it would be better to have find_bounds than get_bounds.

Example of "all-times" currently reported:

<wcs:temporalDomain>
<gml:timePeriod>
<gml:beginPosition>0001-01-01 00:00:00</gml:beginPosition>
<gml:endPosition>9999-12-31 23:59:59.999999</gml:endPosition>
</gml:timePeriod>
</wcs:temporalDomain>

from podpac.

@mpu-creare @drc-creare The bounds are somewhat meaningless without a CRS. Note that find_coordinates returns a list of coordinates which may not all have the same CRS.

I guess the user should specify the desired CRS:

bounds = node.get_bounds(crs='EPSG:2193')

In some cases, e.g. for a Datasource or Compositor, maybe we should default to the native CRS.

# default
bounds = node.get_bounds()

# same as
bounds = node.get_bounds(crs=node.coordinates.crs)

Or we could default to the default CRS in the settings?

# default
bounds = node.get_bounds()

# same as
bounds = node.get_bounds(crs=podpac.settings['DEFAULT_CRS'])

In either case, does it make sense to return the crs alongside the bounds?

# use a default crs, and know what it is
bounds, crs = node.get_bounds()

# the returned crs would be redundant here, but that's okay
bounds, crs = node.get_bounds(crs="EPSG:2193")
assert crs == "EPSG:2193"

Another alternative would be to only implement get_bounds for Datasources and TileCompositors and Interpolators (where there is a single source CRS). This would simplify what CRS to return bounds in, and we would either return it alongside the bounds or in a separate property.

Any other ideas or preferences? This is very easy to implement, just have to nail down the API.

from podpac.