Ice velocity is estimated with a moving window...filtering is also necessary to remove spurious correlations.
In the past, these algorithms have divided the two scenes into chips (tiles). The idea here is an identifiable feature will only move a restricted number of pixels between t
1 and t
2. For example, if a pixel represents 10 m, if a region of the Jakobshavn ice stream is moving 30 m per day (ie 3 pixels), if 12 days pass between orbits, a given feature will be displaced 36 pixels.
So for a chip 360 pixels on a side from the first scene, the feature is quite likely to
still be on the same chip of the second scene at t
2. Since there's no human intervention in feature definition, only best correlation, there's a huge reductions in false positives (and gain in processing speed) if you refrain from comparing t
1 pixels to
all the places they couldn't possibly be at t
2.
These satellite scenes are less than a gigabyte in size and a pair can be processed in 3-4 minutes on a desktop. That means it's no big deal to vary chip size to optimize for slow and fast motion. Even at Jakobshavn, the world's fastest glacier, the velocity range is restricted and reasonable.
The worst case scenario is 1 m per year at Summit vs 17000 at the mid-August calving front. More typically, if you can see the ice moving in a Jakobshavn animation, the speeds will range from 1-30 meters per day. However not all the ice is moving, for example the NS dividing island no longer has any significant driving stress from the east.
In the case of the Jakobshavn elbow, we already know from the mound animation to expect a large variation in speeds over a short distance -- the ice takes several years to cross the top of the mound yet to the south the ice stream proper is moving at a record pace. So this is going to be challenging to measure both on the same chip with the same accuracy.
That's important to get right (not squash with a log palette display) because adjacent ice moving at different speeds requires accommodation by shearing along glide-plane surfaces to the full 1400 m depth which raises a whole range of ice physics issues.
It's also very clear from the elbow and north bank animations that even in small regions, the ice is not remotely moving in a parallel flow (as it does off the summit ridge). So even on a small chip there will be convergent and divergent flow lines even though ice is incompressible. Ng has a good recent treatment that's discussed over on the Pine Island forum.
Given that every chip within 25 km of the Jakobshavn calving front will have ice moving in different directions, it is completely unacceptable to dumb down the output to speed.
Note mass conservation does not imply volume conservation. First the ice surface is not vertically confined (allowing troughs and pressure ridges) and second air-filled crevasses can take up some of the slack. A steady succession of them is being created off the southeast flank of the elbow mound by differential flow.
I like this mound elbow region because it raises all the issues in a very small space and has very dense radar coverage to depth (this is all happening in 3D). The very first thing to look for in a Jakobshavn journal article is if they
blew off this region (converted it to a non-interacting straightaway). If the elbow region isn't be done right, the physics and future will both be wrong. Reality may be inconvenient but it can't be ignored.
The image and excel file below show all the possible Jakobshavn time series for Sentinel 1A and Landsat-8. Here Sentinel repeats its orbit every 12 days and Landsat every 16. We are only interested in Sentinel IW GRDH scenes and those come four orientations, of which two are new. It will not work out to mix and match different orientations (ie re-project) as the slightest degradation of feature resolution will throw off velocity measurements.
Note too that even the better scene types skip dates, leaving 12, 24, 48 and even more days between takes. That is not a problem for measuring slower velocities (12 days might not provide for enough displacement) but this must be balanced with loss of feature correlation. For example, the 276 day gap (23 orbits) between 11 May 15 and 11 Feb 16 might seem ideal for nearly stagnant ice but in practice re-locating t
1 features at t
2 will prove problematic.
I have not seen anyone chaining velocity chips (ie t
1, t
2, t
3, ... t
n off an animation to spline up flowline chords].
Sentinel-2A will be producing its first images of Jakobshavn this week. It is a Landsat-type instrument and will have the same problems with clouds that right now are obscuring the calving front. It is on a 10 day orbit but in some areas the (orthorectified) takes will be 30 days apart. This is great to have three open source satellites for monitoring Greenland glaciers.
https://sentinel.esa.int/web/sentinel/missions/sentinel-2/acquisition-plansClicking on the first image will get it to display better. The attached text file has the same data as plain numbers (without the colors) and will load into any spreadsheet (for updating this season) as a comma-separated-values file (edit .txt to .csv after download).
There is a secret sauce, namely 'GRD IW', that causes the Sentinel portal to list only its IW GRDH (nothing is returned for 'IW GRDH') scenes. At the 'classical' portal, you could set it to show all the scenes, the new one will only show 25 on first go-round.
Using the gold series, someone here could make an animation of 37 easily co-registered frames spanning 504 days. The purple series has only 18 frames but also spans 504 days, These may be ascending/descending orbit pairs since they alternate for much of the chronological column.
No one has tried integrating the Sentinel series into the Landsat series to get year-round, more evenly spaced temporal coverage. This would look odd as an animation but have improved scientific value in measuring seasonal velocity changes, year-on-year acceleration, and surges after calving events. The SNAP toolbox does enable re-scaling and co-registration to UTM22.
