You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TLDR: setting .res on UnionDataset should set it for all children.
A problematic scenario: assume a is a raster dataset with res=1 and b, c are vector datasets with res=0.0001. We want a union with res=1. If we write
ab=a|babc=ab|c
b will be cast to res of a and then c to resolution of ab -> all datasets have the same res=1. However if we write
bc=b|cabc=a|bc
we will create bc with res=0.0001 and then cast it to the res of a. But since res is just a member variable of bc, it doesn't run any code to propagate down to b and c. When we query resulting abc we will get answers at differing resolutions, which in my case crashes the kernel with an attempt of rasterizing b and c at ridiculously high resolutions.
Steps to reproduce
I hope the analysis above is sufficient to understand the issue. I can provide a runnable repro if I am pointed to a way to reasonably generate fake data (I'm not sure how to do it best, such that the fake vector and raster datasets overlap and agree on metadata).
Version
torchgeo==0.4.1
The text was updated successfully, but these errors were encountered:
I'm able to reproduce this bug. I believe it affects both res and crs for both IntersectionDataset and UnionDataset. Working on a fix and better testing now.
Description
TLDR: setting .res on
UnionDataset
should set it for all children.A problematic scenario: assume
a
is a raster dataset with res=1 andb, c
are vector datasets with res=0.0001. We want a union with res=1. If we writeb
will be cast to res ofa
and thenc
to resolution ofab
-> all datasets have the same res=1. However if we writewe will create
bc
with res=0.0001 and then cast it to the res ofa
. But sinceres
is just a member variable ofbc
, it doesn't run any code to propagate down tob
andc
. When we query resultingabc
we will get answers at differing resolutions, which in my case crashes the kernel with an attempt of rasterizingb
andc
at ridiculously high resolutions.Steps to reproduce
I hope the analysis above is sufficient to understand the issue. I can provide a runnable repro if I am pointed to a way to reasonably generate fake data (I'm not sure how to do it best, such that the fake vector and raster datasets overlap and agree on metadata).
Version
torchgeo==0.4.1
The text was updated successfully, but these errors were encountered: