A little nitpick about:<p><pre><code> The number of looks correlates with a higher resolution.
</code></pre>
Yes and no. When you task an image, you usually (as is the case with Umbra) specify your desired ground resolution, eg. 25, 50, 100 cm, etc. There are two dimensions in a SAR image: range and azimuth. Range resolution is determined by the SAR system bandwidth. Azimuth resolution is determined by the integration angle (the angle formed between your target and your satellite from start to end of the collection).<p>Let's assume you want a 50 cm image. Your range resolution will be equal to that and, in a 1-look image, your native azimuth resolution will also be 50 cm. What happens when you request a multi-looked image, is that the satellite will collect data over your target for a longer amount of time (and thus over a greater angle diversity). Range resolution will not change; however, in the natural ("native") image, you get asymmetrical pixels: taking the same target resolution of 50 cm, a 2-looks image will have a 25 cm azimuth resolution. For 3-looks, ~16 cm. And so on.<p>What then happens during the processing of derived products (eg. GEC) is that the pixels are squared: to do that, you have to average out the pixels in the azimuth dimension. This greatly improves what is called the radiometric resolution (ie. how much information a pixel contains), by cancelling out the speckle and averaging the noise. But for all intents and purposes, on a multi-looked image (<i>which is what the GEC products that you use are</i>), spatial resolution remains the same, square pixel.<p>[SAR nerds here: I am not mentioning the slant-range-to-ground-range process, and I am also ignoring the resolution vs. sampling distinction for simplicity]
Quick geospatial note that's important for accurately geolocating these images:<p>You need a DEM to use RPCs for geolocation. Running things through gdalwarp as was done here will assume no terrain and 0 elevation. That will lead to significant mislocations anytime it's not flat and at sea level, especially given the off-nadir view angle of the data used here.<p>In other words:<p><pre><code> gdalwarp \
-t_srs "EPSG:4326" \
2024-05-25-15-37-54_UMBRA-06_GEC.tif \
warped.tif
</code></pre>
Should be:<p><pre><code> gdalwarp \
-to RPC_DEM=some_dem.tif \
-rpc \
-t_srs "EPSG:4326" \
2024-05-25-15-37-54_UMBRA-06_GEC.tif \
warped.tif
</code></pre>
If you don't want to use a DEM for orthographic corrections, then you should at least include a constant elevation in meters of the scene with RPC_HEIGHT. Otherwise things can be shifted kilometers from where the image actually is.
A company called Erim back in the 70's pioneered SAR systems. They had an interesting approach to processing and storage of the data which was all analog back then. They used holography. Erim and their SAR work is documented in wikipedia but their company presidents obsession with holography was detailed in their monthly news letters. I was handed some of these documents from a former (now deceased) worker at Erim. He told me how they were able to fly the massive radar systems and the huge analog computers they used to process the data. It must have been absolutely wild to work there in those days.
Man there’s everything to love about this. A novel free dataset, complete example code, clear description of how to get it up and running—the ideal blog post IMHO. Delighted to learn about it.
> Umbra has an open data programme where they share SAR imagery from 500+ locations around the world<p>I think they're referring to this: <a href="https://umbra.space/open-data/" rel="nofollow">https://umbra.space/open-data/</a> (warning: most files are absolutely ginormous)
Related, they are also visible while flying:
<a href="https://medium.com/google-earth/planespotting-465ee081c168" rel="nofollow">https://medium.com/google-earth/planespotting-465ee081c168</a><p>(not SAR in this case)
> Below is Umbra's image of the same location. Though it was taken on a different day and some aircraft might have been moved around, you can see that a lot of the aircraft in the bottom left are barely visible unless you zoom in very closely and pay attention to artefacts that give away a large man-made object is present.<p>Bad example, because the radar image simply shows a different situation with all but two of the aircraft not present. The two that are present are easy enough to spot.<p>Here's another image with 5 aircraft present (including the two from the radar image). It's rotated, the aircraft are in the top left:
<a href="https://x.com/___Harald___/status/1825362047061971309/photo/1" rel="nofollow">https://x.com/___Harald___/status/1825362047061971309/photo/...</a>
Great hands-on example! I recently read a news article [1] that discussed the monitoring of Russian "Mainstay" AEW&C Beriev A-50 aircraft [1] but unfortunately, it didn’t include the actual code.<p>[1] <a href="https://www.linkedin.com/posts/spaceknow_spaceknow-inc-in-cooperation-with-satellogic-activity-7236641575945068546-GmdZ/" rel="nofollow">https://www.linkedin.com/posts/spaceknow_spaceknow-inc-in-co...</a>
I thought this was interesting :A Chinese satellite tracking planes at Hartsfield-Jackson International Airport Atlanta<p><a href="https://x.com/HenriKenhmann/status/1325377922228629507?t=7Sx2Odd6AzW1bPOH0KjUoQ&s=19" rel="nofollow">https://x.com/HenriKenhmann/status/1325377922228629507?t=7Sx...</a>
In the blog there's a video of what looks like cars moving around, but the lighting is constantly changing. How does that work?<p>It looks like a timelapse but then there are cars doing normal car things.<p><a href="https://www.youtube.com/watch?v=cwDjJqtx_og" rel="nofollow">https://www.youtube.com/watch?v=cwDjJqtx_og</a>
It’s really cool to see the kinds of stuff I learned in school using closed source turnkey remote sensing and GIS software being done in a more open, programmatic way. There’s just this far nicer feel of control.