[uss_qualifier] rename and generalize VerticesResource to VolumeResource#1138
Conversation
1a63d46 to
6165254
Compare
|
|
||
| template: Volume4DTemplate | ||
|
|
||
| def s2_vertices(self) -> list[s2sphere.LatLng]: |
There was a problem hiding this comment.
This operation should apply to an outline; probably a Volume3D if we want to make it easier to support non-polygonal shapes like circles in the future. We don't want to put a method on a high-level object that operates only on a much narrower subcomponent because that reduces reusability for other things that use only the narrower subcomponent (e.g., if we later wanted S2 vertices from a Volume3D for some other reason, we would be likely to duplicate this logic since it's not obvious we should go looking in a much higher-level special-purpose VolumeSpecification for that existing code).
We can add convenience accessors to higher-level objects, but we should make sure the actual operation is always performed at the appropriate lower level. An accessor would probably look something like:
def s2_vertices(self) -> list[s2sphere.LatLng]:
return self.template.resolve({}).volume.s2_vertices()with
class Volume3D(ImplicitDict):
def s2_vertices(self) -> list[s2sphere.LatLng]:
[the rough implementation shown here]Plus, the implementation here isn't even correct because a Volume4DTemplate includes, for instance, transformations.
There was a problem hiding this comment.
Switched to using resolve() and moved the logic for s2_vertices to Volume3D
e890826 to
6be9d17
Compare
| -------------------------------------------------------------------------------------------------------------------- | ||
|
|
||
| # Release Notes for v0.18.2 | ||
| # Release Notes for v0.19.0 |
There was a problem hiding this comment.
Bumped the minor number given that the change is breaking.
# Conflicts: # NEXT_RELEASE_NOTES.md
6be9d17 to
d38f2df
Compare
First step towards #1053:
Rename
VerticesResourcetoVolumeSpecificationand let it have a single field of typeVolume4DTemplate, which will allow us to use the optional (and dynamic) time-bounds out of the box.This PR does not yet update scenarios to make usage of the dynamic time-bounds, this will happen in a follow-up PR.