I’m interested in building a time series based on Sentinel 1 SLC data.
I had two questions I’d appreciate help with:
Do the SLC tiles cover fixed geographic coordinates (same as for Sentinel 2), or can the areas included in a tile change from acquisition date to acquisition date?
Are there any kml files (or some other type of file/solution) that would allow me to determine which Sentinel 1 tile a coordinate belongs to? I found a webpage maintained by esa that shares kml files describing the planned acquisition segments, but I’m not sure whether that’s the same thing.
What I’m interested in is backscatter and coherence, which I’m deriving from the SAFE files. Don’t the SAFE files include information coming from both slices and bursts? Do the SAFE files not cover fixed geographic areas?
P.S. Thanks for your response! I originally replied via email but the response wasn’t sent, sorry for the late reply.
@ABraun You wrote here that “footprints” can slightly change along track.
Does that mean that I cannot assume that a pixel at x,y in file #1 will represent the same geographic location as the pixel at x,y in e.g file #2?
Yes, this cannot be assumed, party because of shifts, but mainly because of terrain distortions which have to be corrected first. These depend on incidence angle and sensor positions and therefore vary between different acquisitions.
Is it safe to assume that SAFE files aim to consistently cover the same areas?
So that if, for example, I sample 100 random points from a SAFE file at date A, it’s likely that almost all of those random points will be in the corresponding SAFE file at date B, though their exact pixel locations may have slightly changed?
Actually, SAFE is just the container of the metadata which refers to the actual image data in the subfolders, depending on the product level.
Sentinel-1 products are acquired along tracks (relative orbits) and inside these tracks the images are made within fames. If these are identical for several images, the footprint should at least be similar, but as SAR data is acquired in side-looking geometry, there can still be shifts inside which are only solved by terrain correction. Working with pixels defined by column and row (x/y) instead of geo-coordinates doesn’t sound like a good idea to me.
Adding to @ABraun response. It is really fragile if you depend on column and row location only.
Converting image/column location to geographic coordinate and vice versa can be done via popular and free software such as GDAL. Though this needs an appropriately processed slc image with geotransform data.
Absolutely, sorry if my question was poorly phrased. I didn’t mean that I’m going to depend on row+column locations only, I’m just trying to get a sense of how much areal overlap to expect between SAFE files. It sounds that the overlap should be very significant, though there isn’t an exact correspondence due to terrain correction and other considerations.