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

[Bug]: Temporary VRT fails for unzipped SAFE files due to relativeToVRT=1 #96

Open
scottstanie opened this issue Jan 23, 2023 · 0 comments
Labels
bug Something isn't working needs triage Issue requires triage to proceed

Comments

@scottstanie
Copy link
Contributor

scottstanie commented Jan 23, 2023

Checked for duplicates

Yes - I've already checked

Describe the bug

When I ran COMPASS with unzipped files, I was getting read errors.
I checked the _temp.vrt file made for each burst:

$ gdalinfo unzipped/scratch/t087_185679_iw1/20180511/t087_185679_iw1_20180511_VV_temp.vrt

Driver: VRT/Virtual Raster
Files: unzipped/scratch/t087_185679_iw1/20180511/t087_185679_iw1_20180511_VV_temp.vrt
Size is 20492, 1490
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0, 1490.0)
Upper Right (20492.0,    0.0)
Lower Right (20492.0, 1490.0)
Center      (10246.0,  745.0)
Band 1 Block=128x128 Type=CFloat32, ColorInterp=Undefined
  NoData Value=0
ERROR 4: unzipped/scratch/t087_185679_iw1/20180511/S1A_IW_SLC__1SDV_20180511T161552_20180511T161622_021859_025BF8_1292.SAFE/measurement/s1a-iw1-slc-vv-20180511t161552-20180511t161620-021859-025bf8-004.tiff: No such file or directory

What did you expect?

I expected the VRT to correctly point to the .tiff file

Reproducible steps

The reason for the failure is here: https://github.com/opera-adt/s1-reader/blob/428328de5011968da91174cdf14db6eb3e8264c7/src/s1reader/s1_burst_slc.py#L360

We are using relativeToVRT=1, which means we're saying that the location of the tiff_path will be relative to the location of the VRT.
This is probably only going to be true when we do slc_to_vrt_file('.'), since we're passing some other path to the tiff_path.

The reason this is currently working for the zipped file testing is gdal ignores your indication of relativeToVrt when your path starts with a / and treats it as absolute

Note that "relativeToVRT=0" doesn't mean it has to be a full path. If it's not, then the path is treated relative to whatever directory you are in.

For example:

$ tree
.
├── data
│   └── swath.tiff
├── folder-with-vrt
│   ├── test_absolute.tiff
│   └── test_relative.tiff

 cat folder-with-vrt/test_relative.tiff
<VRTDataset rasterXSize="20492" rasterYSize="1490">
    <VRTRasterBand dataType="CFloat32" band="1">
        <NoDataValue>0.0</NoDataValue>
        <SimpleSource>
            <SourceFilename relativeToVRT="1">data/swath.tiff</SourceFilename>
            <SourceBand>1</SourceBand>
            <SourceProperties RasterXSize="20492" RasterYSize="14900" DataType="CInt16"/>
            <SrcRect xOff="15" yOff="8957" xSize="20459" ySize="1456"/>
            <DstRect xOff="15" yOff="17" xSize="20459" ySize="1456"/>
        </SimpleSource>
    </VRTRasterBand>
</VRTDataset>

$ gdalinfo folder-with-vrt/test_relative.tiff...

ERROR 4: folder-with-vrt/data/swath.tiff: No such file or directory

$ diff folder-with-vrt/test_absolute.tiff folder-with-vrt/test_relative.tiff
5c5
<             <SourceFilename relativeToVRT="0">data/swath.tiff</SourceFilename>
---
>             <SourceFilename relativeToVRT="1">data/swath.tiff</SourceFilename>

$ gdalinfo folder-with-vrt/test_absolute.tiff

(it works)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs triage Issue requires triage to proceed
Projects
None yet
Development

No branches or pull requests

1 participant