Difficulties using the make_ortho method

[JackEisenrichCarroll]

I've been trying to use this package as a method for automatically orthorectifying Planet Labs satellite imagery for analysis, and have run into some issues using the make_ortho method! I am attempting to use PlanetScope 4-Banded imagery combined with ArcticDEM elevation data. I am thinking possibly the error is caused by the DEM being at a higher resolution than the imagery; Attached are links to a screenshot of the error message, and some of the raw PlanetScope image data.

https://user-images.githubusercontent.com/58920063/89475300-3ecb3f00-d734-11ea-97be-cf48e4019806.png

https://drive.google.com/drive/folders/1XfwK0ONn5O7-A8cIU_XSIEtG3w0UKiEQ?usp=sharing

[mpfaffenberger]

Thanks for the detailed report. I was able to access your data and correctly orthorectify it. I'm attaching a Jupyter notebook demonstrating -- I did have to make a small change to the codebase here and there. If you happen to get this running on your end, please supply a P/R with the minor changes required to run this.

Arctic_Dem_Planetscope_Analysis.zip

[WalidGharianiEAGLE]

Greetings, I have Two question to ask: 1/ I did download the Jupyter notebook you provided; Since the data provided by JackEisenrichCarroll are not accessible for everyone, I am not able to follow along and try it out; So I did try with my own data set which contain RPC info and I also downloaded an SRTM scene covering my satellite image, looking through the code; I understand that make_ortho is the function needed for the orthorectication task; My question here; How did you defined; first the bounding box (x1, x2, y1, y2) min_lon, max_lon, min_lat, max_lat, which is in the provided script (-163.022113662,-162.404335798,65.9717081494,66.1267419677) how do you get this extent since I would assume its not the one from the original satellite data? Second the width: int (number of pixels)? Third you included an argument -50 at the end which represent what?

2/ Since this package is based on GDAL, Ive tried to with it as well: The documentation on Orthorectification with GDAL is really lacking most of the answars Ive been getting are from stackoverflow or some blogs; Here what I've tried to do: First; gdalwarp --config CPL_DEBUG ON -overwrite -s_srs EPSG:4326 -t_srs EPSG:4326 -rpc -to 'RPC_DEM=srtm.tif' raster.tif raster_ortho.tif Regardless of using 'RPC_DEM=srtm.tif' or not I get the same raster_ortho.tif which is was shifted but not on the proper location when overlaying on top of google imagery in qgis (a bit worst than the original data) , So Im not sure why is that! does it actually uses the DEM I'm providing or no? Second; I've read this blog by Frank Warmerdam on http://fwarmerdam.blogspot.com/2013/09/exploring-rpcs.html I didn't really get a lot of what he did to generate another RPC with GCP, but he mentioned that its possible to use (RPC_HEIGHT) as an argument into the gdalwarp function, so I did experimented and I got different raster_ortho with it but not exactly orthorectified properly, So Im not sure what exactly I should provide as a value for the height.

It will be really helpful to address this questions since this topic is really important, and I would suggest to write a Jupyter Notebook as a tutorial with open source data so that everyone interested could learn about it and use it properly.

[mpfaffenberger]

Hi @WalidGharianiEAGLE,

To answer your first question, sometimes raw satellite imagery that ships with RPCs will also ship with a polygon / bounding box that represents the footprint of the image. In the case of @JackEisenrichCarroll's data, that wasn't the case. IIRC, I think I just looked at the RPC data. There are a couple of fields that give you the upper left corner in lon/lat (4326) coordinates. I believe it is LAT_OFFSET and LONG_OFFSET. There is also a LAT_SCALE AND LONG_SCALE that you can use to determine the width/height of each pixel. You can then multiply in each direction to yield the bottom right corner.

For your second question -- actually this orthorectification routine is not based on GDAL. It is 100% native Python. This package uses GDAL only for I/O (reading and writing the imagery data from and to files).

I'd be more than happy to create a Tutorial Jupyter notebook with open source data, and include it in the repository. In fact, why don't you post a link to a dataset that would suit your needs?

Generally speaking, every provider ships their data a little bit differently. In order to accurately read the metadata, you sometimes have to write custom utilities. GDAL helps a TON with this, but @JackEisenrichCarroll's data from Planet had some XML metadata that I believe had to be manually parsed (using ElementTree or whatnot).

[WalidGharianiEAGLE]

@mpfaffenberger Thank you for your informative answer. Here you may found the datasets I used as an illustration and some of the questions about the code and data https://github.com/WalidGharianiEAGLE/orthorectification_python_tutorial/tree/master