Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AOI's label geopackage: optionally accept a layer to define extent of ground truth data, per AOI #419

Open
remtav opened this issue Dec 7, 2022 · 1 comment

Comments

@remtav
Copy link
Collaborator

remtav commented Dec 7, 2022

In AOI's __init__, we'd need to allow the use of a layer from ground truth's geopackage that contains a single polygon which defines the extent of interest for ground truth data. This layer would also be used:

  • to calculate overlap between ground truth and imagery in self.bounds_iou_gdf_riodataset()
  • during tiling, where we'd pass this layer to ogr (in GDLVectorDataset): GetLayer("name_of_extent_layer")
@remtav
Copy link
Collaborator Author

remtav commented Dec 7, 2022

After discussion with @mpelchat04 , ground truths that were acquired only partially from imagery and for which that acquisition extent is not rectangular could cause problems.
In an example like BC37, the extent is a "L" shape:
image

If buildings were acquired inside that entire extent, the current tiling script would also tile in the lower left corner, where there could also be buildings on imagery, but no corresponding footprints on gt. This becomes problematic as models would train on imagery where buildings are present, but they'd be associated to "background" class in ground truth.

If we use the "extent" layer inside a gpkg, this wouldn't fix this issue unless we assure tiling can cover a non-rectangular polygon, which is not easy. Why? It's not easy to pass a polygon as a dataset extent in torchgeo's GeoDatasets rather than a bounding box. The rtree library which deals with this extent in torchgeo expects only bounding boxes.

Potential solution:

  1. use "extent" layer as nodata mask on imagery instead of source nodata mask (see Use NODATA mask to avoid out of bounds extractions #346 )
  2. make sure we don't acquire gt in non-rectangular extents

Solution 1 seems easier to implement, though it's more a workaround than a solution... The downside compared to ideal solution (ie clip with extent's polygon), is that many patches would be created with "black" imagery patches (outside nodata mask). To be discussed.

I'd also like to know in our datasets, how many extent polygon significantly differ from a rectangular shape.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant