Add own plot method and data.py to CBF #410
Conversation
github-actions
bot
added
datasets
|
No idea what is happening with the tests here, let me know if you want me to look more into it @nilsleh |
|
Yes, sorry I am not sure what is happening, locally it passes all tests. |
|
Will this plot method work with a VectorDataset? |
I added an example from the cbf dataset. |
| @@ -675,21 +675,6 @@ def __getitem__(self, query: BoundingBox) -> Dict[str, Any]: | |||
|
|
|||
| return sample | |||
|
|
|||
| def plot(self, data: Tensor) -> None: | |||
There was a problem hiding this comment.
Since CBF was the only VectorDataset, and since it overrides the plot method, this code was no longer being tested. We have a few options:
- Remove
VectorDataset.plot - Keep it, update the signature to take in a sample, and use a useful default
- Keep it, update the signature to take in a sample, and raise NotImplementedError
- Turn it into an abstract method and require all subclasses to implement it
The benefit of 1 is that it is the least code. The benefit of 2-4 is that they add mypy checks to ensure that all subclasses use the same signature. The benefit of 4 is that it prevents someone from adding a new subclass that doesn't implement plot. The downside of 4 is that it means you can't instantiate a VectorDataset directly.
I forget where we discussed this already, but I have a slight preference for 4 because it seems like "the right thing to do", and @calebrob6 has a slight preference for 3 because it allows you to use VectorDataset directly without creating a subclass. I think 1 and 2 are valid options too. Interested in hearing other opinions on this one.
Note that this will also affect RasterDataset once we finish adding individual plot methods to all classes.
There was a problem hiding this comment.
I wonder if our plotting code has enough in common that we could define one or two plot methods in VisionDataset and GeoDataset and then have each subclass call super with the appropriate arguments.
There was a problem hiding this comment.
Does anyone have any opinions on this? We should make this decision so we can finish adding plot methods to all GeoDatasets.
There was a problem hiding this comment.
I wonder if our plotting code has enough in common that we could define one or two plot methods in VisionDataset and GeoDataset and then have each subclass call super with the appropriate arguments.
We do have a good bit of duplication, but I think a utility function would be better for the average case as there are some really whacky plots.
* add own plot method and data.py * clean up data.py * version changed instead of added * Update cbf.py * Any instead of Tensor * Fix VectorDataset tests * Plot method in base class no longer needed/tested * Removing unused imports * Remove type ignore from openbuildings * Fix tests * Black formatting Co-authored-by: Caleb Robinson <calebrob6@gmail.com> Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* add own plot method and data.py * clean up data.py * version changed instead of added * Update cbf.py * Any instead of Tensor * Fix VectorDataset tests * Plot method in base class no longer needed/tested * Removing unused imports * Remove type ignore from openbuildings * Fix tests * Black formatting Co-authored-by: Caleb Robinson <calebrob6@gmail.com> Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Since RasterDatasets should have their own plot method per #253, this PR adds a plot method as well as a data.py file with adapted fake data to the the CBF dataset.
Example:
