Closed leifdenby closed 2 years ago
I totally agree. In fact, this. might be more than a semantics discussion; I've had people ask me about whether we could use the metrics to analyse paintings or tree bark patterns. It would be nice to not lock into clouds only.
Taking the question one step further, what would you do with the name of the package? I quite like cloudmetrics
, since it maintains a link to the community we're first and foremost trying to support, but am happy to think about other options.
I totally agree. In fact, this. might be more than a semantics discussion; I've had people ask me about whether we could use the metrics to analyse paintings or tree bark patterns. It would be nice to not lock into clouds only.
Great! I'll do a pull-request for that. Thanks
Taking the question one step further, what would you do with the name of the package? I quite like
cloudmetrics
, since it maintains a link to the community we're first and foremost trying to support, but am happy to think about other options.
Yes, I've been thinking that too. But I haven't thought of a good name yet :) We could always make an "alias package" with the new name pointing to this one, so that the cloud community still find it easy to find this package. But I'm completely open to changing the name too at some point if we can think of a good name...
this has been completed with https://github.com/cloudsci/cloudmetrics/issues/47, thanks for your help @martinjanssens !
@martinjanssens while working through the refactoring over the last two days I've realised a generalisation we might want to make.
Because the functions we've written here actually would apply to any "mask" (not just cloud-masks) and any scalar field (not just those related to clouds) I suggest we write
mask
rather thancloud_mask
,scalar_field
rather thancloud_scalar
andobject_labels
rather thancloud_object_labels
. Are you ok with me changing this?