Zachariae Isstrøm / Nioghalvfjerdsfjorden / NE Greenland

[Espen]

Here are the historic elevation changes and calving front positions along with transects up the main channels. It represents a prodigous amount of imagery acquisition and processing as can be seen from the Supplemental Material. Sidd posted parts of this before.

This is a very different system from the other glaciers, originating as it does on the distant central ridgeline above an area of abnormal but steady geothermal heat flux, with sharp shear margins and not much by way of tributaries. I've attached a radar transect that, while not quite the one we want, still shows that summit radar horizons -- and their ice dating -- get all the way to the coast with deformations mostly along shear margins and not so evident bottom freezeups like at Petermann.

Sustained mass loss of the northeast Greenland ice sheet triggered by regional warming
SA Khan et al NATURE CLIMATE CHANGE | VOL 4 | APRIL 2014
http://www.indiaenvironmentportal.org.in/files/file/greenland.pdf
http://www.nature.com/nclimate/journal/v4/n4/extref/nclimate2161-s1.pdf

A-Team,

One thing puzzling me, is if Zachariae is grounded as they describe it, how come those calves float around so freely?

(Maybe this belong to the stupid question thread?) 

[Yuha]

One thing puzzling me, is if Zachariae is grounded as they describe it, how come those calves float around so freely?

My (completely uneducated) guess is that during calving the bottom part of the calve crumbles into small pieces and the resulting calve is not as high as the calving front. The smaller pieces of ice between the big calves could be the remains of the bottom parts.

[Espen]

Or maybe the Zachariae calves got a cork+ gene built in?

[A-Team]

Espen, various possibilities. I did not enclose the locations of the depicted transects but see below. If you can align bed topography with satellite surface images, you might find the transects are farther inland than the calved pieces. Alternatively, the cartoon might not have attempted to depict the situation accurately ... wouldn't be the first time. Possibly but implausibly, the situation might have changed since that illustration was made.

Otherwise, no: pieces would not be free to move about. There is partial buoyancy and some flexure with tides but that can barely be detected with double interferometric SAR (example of Petermann posted in Jakobshavn forum).

On the technical side, the color errors in the bed DEM below should have been caught during peer review. The original submitted image and especially the depth key are so badly dithered that it is not possible to locate say the -1000 to -900 m regions (if there even are any), even by using H of the HSV decomposition which can sometimes save the day.

[A-Team]

I pulled out the Cresis file that constitutes the last part of the radar horizon montage in post #249. This area is a ways south of Zachariae though the upper horizons would still be representative in most respects. Einar Mikkelson/Sonaneibraeen might have been a specific target of the flyover.

The region (yellow arrows) where the Cresis picked surface (red) coincides with the picked bedrock (magenta) is presumably exposed bedrock though that doesn't fit with the imagery or the apparent trough.

You just know OIB flew lots of rasters and flowlines on Zachariae; the question is, stored under what file names, for which many years, for which radar configurations, which flight lines include the NEEM/Ngrip ridge, ie finding the optimum for the calving region. This would settle the channel bedrock depth and loose floe issues.

[Espen]

Alternatively, the cartoon might not have attempted to depict the situation accurately ... wouldn't be the first time. Possibly but implausibly, the situation might have changed since that illustration was made.

Otherwise, no: pieces would not be free to move about. There is partial buoyancy and some flexure with tides but that can barely be detected with double interferometric SAR (example of Petermann posted in Jakobshavn forum).

On the technical side, the color errors in the bed DEM below should have been caught during peer review. The original submitted image and especially the depth key are so badly dithered that it is not possible to locate say the -1000 to -900 m regions (if there even are any), even by using H of the HSV decomposition which can sometimes save the day.

Yes A-Team I am sometimes very surprised how bad they present their findings, most with "Mickey Mouse" like graphic, but I doubt Zachariae is grounded as they show it?

[Shared Humanity]

I can't imagine how a grounded glacier could be calving so quickly with tabular icebergs.

[Espen]

I can't imagine how a grounded glacier could be calving so quickly with tabular icebergs.

Unless someone had a conveyor system installed for the purpose?

[A-Team]

Here is the radar data from 2012. It shows the surface and bedrock fairly clearly, maybe not exactly where we wanted.

The first is a funky reconciliation of the Cresis track icon, seemingly in mercator coords over a totally antiquated satellite image, with Cresis kml google earth projection over that poor quality imagery. Both should really stub in Howat et al's careful photomontage of the Greenland coast.http://www.the-cryosphere.net/8/1509/2014/tc-8-1509-2014.pdf] [url]http://www.the-cryosphere.net/8/1509/2014/tc-8-1509-2014.pdf
[/url]

Next I assembled the longer continuous track 20120514_02_007-010. Cresis has not prepared these properly so the overlap has to be manually removed frame by frame (short of scripting lat,lon interpolation). I cut off the rocks and the NW corner of 007. This image is 1289 pixels wide so won't display properly unless you click.

I shrunk the width by 50% while bumping vertical exaggeration to 200% after gaussian sharpening of the image with 'unsharp mask' and colorization. Gimp provides effortless initial tiling up of scenes, Filter --> Combine --> Filmstrip.

The third image looks at four slices going to the terminus. I left my thinking cap at the brewpub last night so could not adjust the offsets given the channel has a slightly skew latitude line and the flight lines, while blessedly parallel to each other are kattywumpus to the channel center line. To interpolate the missing sections out to 3D so as to reconstruct ice relative channel bedrock, I would want to combine Cresis' digitization of 2echo_picks with the Bamber 2013 bedrock DEM.

[Espen]

Geat work A-Team, image 14 and 20 are identical?

[A-Team]

Espen, every time you ask for a fix, a whole litter of puppies goes to the pound.

Yes, that row should not have been duplicated. Also notice that when the plane flies a grid like that (ie boustrophedonically), alternate Cresis images will be laid out in the reverse direction. Two of those needed to be flipped above. (Of course that reverses the lat,lon text so that has to be fixed as well.)

There is also some major mickey-mouse in pixel proportionality to find the point of alignment which here I took as when the flight path was over the center Zachariae flowline. That is taken care of below.

I will look tomorrow to see if they ever had a flight right down the middle (surely). The radar swath is something like 100 m which would still leave a lot unobserved but a line across our sections would very much constrain interpolation.

[Espen]

A-Team it is amazing the fjord is relatively shallow between Skallingen and Lambert Land, that surprises me?
But then again that explains the reduced speed of the glacier, because of that "back pressure".
And why the ice wants to take the "no hazzle" way via the now free Zachariae highway.

[A-Team]

Yes, good analysis. Here is an interesting scene of an entire flight path from the summit due east down to the Zachariae area. Looks like one of these bottom-up freeze deformation of basal water.

[A-Team]

A lot more going on than meets the eye with the Greenland ice sheet. Especially in the north, ice-penetrating radar shows  massive deformations beneath the surface. The images below explore one of these slow melodramas, found on a 2012 radar flight path from the summit ridge en route to Zachariae, https://data.cresis.ku.edu/data/rds/2012_Greenland_P3/images/20120514_02/.

I've taken to displaying flight paths over a surface velocity map (rather than elevation), with the idea that major deformations would be associated with ice movement. However in this case, there seems to be no correlation with velocity, bedrock holes or bumps (shown as lowest radar horizon), surface elevation, surface slope, or ice stream shear margins of Vallelonga et al http://www.the-cryosphere.net/8/1275/2014/.

That seems to leave bedrock geothermal anomalies. Along the lines of Bell et al 2014, meltwater freezes up on the bottom, over time pushing up an incredible deformation of formerly ~ flat radar horizons. The timescale is not know yet; I presume tens of millenia in the making and ongoing today. The curie point Petrunin et al 2013 bedrock geothermal map does not extend this far north.

[A-Team]

I was curious about the extent of this deformation so looked at 2013 flight lines. It apparently shows up 71 km to the southwest in a slightly subdued form on Cresis scene 20130426_01_049. If so, this is quite a large sub-glacial feature as it could extend quite a ways to the northeast as well.

I added a depth - distance background grid. This shows the first deformation extends from bedrock at 2250 m up the 500 m from the ice surface. The feature in the second track starts at a similar depth but only extends 700 m up. The radar horizons above are in neatly draped wave and what may be a horizontal fold is seen to its east.

Without a handle on the shape and distribution of these features -- and the rheological properties of the ice in them --  the future behavior of the Greenland icesheet will not really follow from modeling off Glen's law and the assumption of tame horizontal ice layers to depth. These bottom freezeups are having a monumental effect.

Existing tracks may be rather sparse for this particular feature; I'll poke around uphill from Petermann where the density of sections is probably more favorable for accurately 3D structure reconstruction.

[A-Team]

I found a straight shot down the main channel of 79N (Nioghalvfjerdsbrae) from a 2010 DC-3.

In case you are having problems drilling down to exactly the frames wanted at Cresis, the first slide explains the procedure: start with the kml file for the year in question. That will open as many tracks in Google Earth. Mouse over the track you want and start to rename: this seems the only way to highlight the track's id in the Places column. Go to that folder and open its restricted kml file. Mouse over again to find the id of segments wanted. Then back up at the Cresis site to the image folder, verify with 0maps and then open the radar track with or without surface and bedrock markups.

The second image shows three consecutive segments of the channel flyover. It's a good idea to trust their markups of the bedrock because double and triple echoes beneath it are artifacts. Espen is more familiar with what this profile means for Zachariae so I will leave the interpretation to him.

[Espen]

Hi A-Team nice work, as usual, it is the profile of 79Fjord you showing above.
But it shows when the back pressure was released at Zachariae (separation from its former tongue) the ice will naturally go the easiest way, and that is not "Route 79".  The steep bottom-end at 79 explains why the ice wants to go the Zachariae route and not "Route 79".

[A-Team]

Yes, this side of Greenland may be more exposed to Atlantic warm water which will strongly affect marine terminating glaciers. While that might waken them, it is not the whole story ... why this icestream is here in the first place, why it goes so much farther inland without the pronounced overdeepenings commensurate with its size, and what its discharge response can be without tributaries.

It is quite a different situation from Jakobshavn Isbrae and indeed the two don't seem to be connected.

[A-Team]

Here are three sections of Zachariae. The down-channel flight path is perpendicular to two subsequent cross-channel sections. I do believe ImageJ, somewhere in its many plugins, has the capacity to display the three sections intersecting in perspective with some degree of transparency and ability to rotate to a nice view. Meanwhile I used gimp as a start.

[A-Team]

Here I made the bump maps of the individual layers, erased some upper firn and radar echoes, and colorized them differently prior to applying perspective transforms with help from an underlying grid layer and then translucencies, all in gimp, for the 25 down-channel and 27 cross-channel.

If uploaded as a gif, blog visitors could download and turn any combinations of radar transects on or off. Maybe better but still not great.  In some key areas, the plane flew dense grids in both directions! PovRay is better in allowing parallel planes to be defined and textures (the radar sections) to be assigned.

[A-Team]

It is not possible to make a comprehensive account of the number and extent of freezeups in Greenland because flight tracks are still too sparse. However 3 people did examine all radar scenes (especially those from modern 16-element arrays) from 1995-2012 and map them (first slide below).

This is actually not too arduous because it amounts to just scrolling down composite pdfs provided at Cresis (or scripting a 1map filmstrip in gimp). The spectacular one I described above is called Northeast Greenland South in their 2014 report.

Not all freezeups have been described: see below or what about 20130415_01_015  at 68.600 N 35.484 W, 20130423_01_003 at 76.057 N 35.926 W, 20130423_01_022 at 74.937 N 28.753 W or the spectacular 20130423_01_033 at 73.445 N 47.137 W seen in 2013 flights.

It's not feasible to name freezeups systematically because their full extent cannot be determined without dedicated surveying, perhaps radar dragged behind snowmobiles. Two mega-complexes extending for tens of km are located upstream from Petermann and Zacharaie. No marginal freezeups have been found south of Eqip.

Take away the freezeups and most of the Greenland Ice Sheet interior remains plain vanilla layer cake, yet the freezeups are important because they warm interior ice which facilitates its flow. Jakobshavn is an exception, having neither freezeups nor pre-Holocene layers in its fast-moving overdeepened lower 40 km. Bedrock topography is important too; many scenes show lower radar horizons draped.

The NEEM borehole encountered a doubled over recumbent fold that did not get a mention but presumably is a portion of a basal freezeup, though the original drill team report attributes it to downhill ridge drift. Radar may have difficulty demarcating subtle freezeups at great depth or this feature could be too small. This would be the only core that has drilled through a freezeup feature -- annual layers are largely preserved despite the dramatic deformations.

The freezeups are classified by meltwater source and mechanism. The one at Eqip represents marginal freezeup of surface meterological water from meltlake and moulins as overhead ice pressure drives it up bedrock topography where it is subject to glaciohydraulic supercooling.

Those farther inland have to use water melted at depth by pressure and geothermal gradient that is available down drainages computed from the bedrock DEM. The bottom of NGRIP is -2.5º, the enormous pressure puts that above the melting point. Subsequent freezeups of this water down-drainage (and associated latent heat) have a profound advecting effect on the ice above which is 15-20 degrees cooler, deforming it up to a mile above.

The second slide shows the freezeups do not correlate with the surface velocity field except at Petermann (which is the main pressure meltwater outlet for the interior). The mid-elevation clustering would fit with a need for melt water source but radar attenuation could reduce detection higher up. Freezeups are not notably associated with bedrock topology (third slide) though surely ice movement over large rock projections deforms ice layers too. Only a single freezeup was validated by gravity modelling as not generated by side reflection from rock.

The remaining four slides illustrate freezeups, with special attention to Petermann where peak deformation is associated with peak surface velocity. I replaced postage stamps in the article with enhanced radar sections though these are still not at full resolution.

A lot more could be done to characterize the structure of freezeups that have been densely grid-sampled during bedrock mapping. To date, no one has dated freezeup onset or modeled their evolution over time. I suspect the margins would be very instructive in this regard; being less developed, they may retain information about early stages of formation.

Deformation, warming and softening of Greenland’s ice by refreezing meltwater
RE Bell et al
http://www.nature.com/ngeo/journal/v7/n7/full/ngeo2179.html (abstract, paywalled)
http://www.nature.com/ngeo/journal/v7/n7/extref/ngeo2179-s1.pdf (free, detailed supplement)

The slides are fairly complex so I set the animation at 10 seconds per frame, click if it doesn't start up.

[Espen]

More calving and retreat at Zachariae Isstrøm between Aug. 22 and Aug. 29 2014:

[Espen]

Retreat situation at Zachariae Isstrøm:

Please click on image to enlarge!

[Espen]

Here is the updated retreat situation between 2009 and 2014, below you find the Byrd Polar Research Center version prior to 2009:

As you can see, the tongue was completely separated from Zachariae Isstrøm in 2012.

As I was discussed with Mauri Spelto back then: http://glacierchange.wordpress.com/2012/08/27/zachariae-isstrom-further-retreat-ne-greenland/

Please click on images to enlarge!

[A-Team]

Meanwhile ... in the interior, very detailed studies of a site halfway down reveal what is going on above and below this unique icestream (which wasn't even identified until 1993). Probably will have to click on the 4th image below to get the short slide show running.

Initial results from geophysical surveys and shallow coring of the Northeast Greenland Ice Stream (NEGIS)
P Vallelonga et al
www.the-cryosphere.net/8/1275/2014/
The Cryosphere, 8, 1275–1287, 2014

K Christianson et al
Dilatant till facilitates ice-stream flow in northeast Greenland
Earth Planet. Sci. Lett., 401, 57–69, doi:10.1016/j.epsl.2014.05.060, 2014.

Basal conditions and ice dy- namics inferred from radar-derived internal stratigraphy of the Northeast Greenland Ice Stream
BA Keisling et al
Ann. Glaciol., 55, 127–137, doi:10.3189/2014AoG67A090, 2014.

[A-Team]

Certain aspects of Greenland-ology are just breathtaking in their audacity. The sheer laziness in not using all available radar data -- do we really have the luxury of dinking around in view of the coming decades?

Let's just say modern radar arrays are not technically worse than those used 15 years earlier so why would a 2014 paper confine itself to 1999 data? Two months in the field translates to ten months in the cubicle so that cannot be the excuse. Surely nine co-authors can find 20 minutes of research time between them.

I cannot picture myself as peer-reviewer reading very far into a paper where authors gesticulate in the general direction of an immense archive but do not cite year, flight, and frame. When 17 years of tracks are reviewed and ~100 rare internal deformations found but no records are kept or gallery provided, I would remind authors of ample storage opportunities on journal supplemental and institutional web sites.

Greenland radar data, ten$ of million$ of it, has largely sat unanalyzed in its archive from 1993 on. It is just unbelievable to me that the OIB science crew is allowed to step off the aircraft without rescaling, tiling, horizoning, and uploading of data -- why are we providing them with laptops?

Meanwhile, Sept 2014 with the last Cresis flight on 22 May, still no kml tracks or curve-fitted horizons -- batch processing rather than pipelining is so 1950's. And that awful photomontage of Greenland from the dawn of motorized flight: https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/images/20130426_01/20130426_01_063_0maps.jpg

Greenland radar evidently has a custom-and-culture problem relative to Antarctica; with croudsourcing it would be fairly easy to do an end run around some of the paid help.

Below I added the 2013 radar transects of the Zachariae icestream to the never-fully-utilized 1996-2012 sections. Given the lame search interface, it is mildly tedious to pull the 2014 but I have those as well.

The radar sections could be distilled with a classification scheme. Here I would toss the 'continuity index' -- its  Holocene overemphasis rather misses the point, which is the more deformable state below. In Greenland, the default vertical ice profile is unadulterated layer cake (eg everything east of Jakobshavn). The layer cake has never been mapped!

Beyond that, I would say topographic draping, shear margins, icesheet marginal turmoil, and bottom freezeups are the main interpretive classes. It would not take rocket science to provide an html 1.0 click-map or mouse-over popups. Interpolation of sparse tracks would consider flow anisotropy, the direction is known. The stratigraphy, often predictably conformal to bedrock, sometimes ignores it entirely for reasons that are surely informative.

[Espen]

Studying the latest images from Landsat, I found some of the calves from Zachariae must be grounded somehow, since they don't  move as the other calves ( marked with red spots), the calf with the * even breaks apart:

[A-Team]

Awright, after a little learning curve with Google Earth, all the ice-penetrating radar tracks in Greenland, 1993-2013. The lower image will need a click to get it animated.

[Espen]

Amazing stuff, it must terribly boring to do those flights across the ice sheet, but then the glaciers and other fringes must be an incredible experience. 

[A-Team]

Yes, I think the flights are long, loud, cold, not without risk but rather boring over hours of layer cake -- really have to applaud the people providing this data.

I look forward to the day that you and I can rent online a radar or camera drone in Illulisat, fly it from wherever we are, to wherever want for the day, then knock off a post. No more scrounging around for journal articles.

I moved the full size animation into storage here: http://tinyurl.com/mppcwe8

The still montage below shows the existing flight paths around the new NEGIS core site. I've labelled some of them -- that is key to actually drilling into right radar scenes. The bright yellow blotches shows bottom freezeups according to Bell 2014.

The background ice surface velocity map is from Vallelonga 2014 -- that grid of little arrows is more effective than color or contours in some ways. I don't know what software is used to make them -- the length and base of the arrows would be easy in gimp but the directions are another matter, probably involve a vector gis overlay.

Where am I headed with this? Oh, just curious if the freezeup by the N of NEGIS is actually a misinterpreted shear margin. Or vice versa. Something is a little fishy with all that basal melt from the geothermal hotspot on the ridge but the nearby freezeups are not associated at all with flow towards Zachariae/89N.

[A-Team]

Cresis is what's politely called a legacy database. In hindsight, unfortunate formatting choices were made in the early years (though 1993 was already five years into Photoshop on a Mac Plus) but changing anything now causes backward incompatibility. Actually it is quite easy to reprocess the entire archive.

Several groups are doing just that but it's not clear if anyone will provide a public server (or even share a big zip file). The main issues are optimal resolution enhancement and rescaling, automatic tracing of isochrons and curve-fitting, and serving data per user-defined restrictions (like EarthExplorer, next post).

We realize now that the mushy late Pleistocene ice between bedrock and the Holocene is critical to icesheet movement and history. It will require separate and sensitive contrast reprocessing. This means 'letting go' of what radar reflectors actually mean in electrical engineering or physics terms (propagation of electromagnetic waves through a variable dielectric medium has been under study since Newton).

Surface velocity vectors vis-a-vis flight track bearing are needed within radar images to interpret deformations, as are bedrock peaks and troughs (already provided), temperature column (especially pressure melt zone and basal melt status), presence of recurring melt lakes, and geothermal gradient (largely unknown).

Cresis still has not posted the kml files for April-May 2014. The y axis, for the first time, provides actual elevation (eg sea level WGS84 rather than surface elevations that end-users had to fix from a DEM.

If you should need those kml tracks, simply save any valid path from an earlier year as a text file (template). Then copy out lon,lat coordinates from one of the pdf files for 2014 before that text is rendered as graphic.

Select-all brings misc text (eg axis labels) along for the ride. However a previously prepared a spreadsheet with a number column of 1's and 0's, a sort can pull out the essential lines 1-6 and 17 out from each batch of 51 lines. It is also possible to reprocess lat,lon coordinates for a straight segment into a compass bearing (haversine formula) using lines 1 and 6..

Then, being very careful not to change spacing, replace the list of template coordinates with your own and give the file a new name in a plain text editor while retaining the .kml suffix

This will now display properly as a track in Google Earth which uses the same coordinate convention as Earth Explorer, negative longitudes for Greenland. The -9999 evidently puts your path on the earth's surface. The rest is kml overhead  -- only the coordinate line counts for anything: lon,lat,-9999 space. Kmz is a compressed version of kml, not needed.

In is also possible to add an image link back to Cresis in segmented kml files. Cresis uses very logical file name s so these urls are easily derived from segment name (eg by appending '_1echo.jpg'). Clicking on the segment in Google Earth then brings up the radar scan itself -- very convenient for fast investigation of interesting areas. That is shown in blue in the template below.

In fact multiple images can be added, creating a scrollable stack when viewed in Google Earth. Urls too: the description section below links back to this blog post from Google Earth as well as the master track pdf at Cresis.

In short, the capabilities of Google Earth are exceedingly under-utilized in Cresis kml files but images and urls are easily scripted in across the entire archive and posted to cloud storage. Alternatively the entire set of radar scans could be permanently added to Google Earth via 'post to community forum', just as touristic photos of glacier calvings are.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
<Document>
   <name>20070910_01.kml</name>
   <Style id="s_frame_highlight">
      <LineStyle>
         <color>ff804000</color>
         <width>3</width>
      </LineStyle>
   </Style>
   <StyleMap id="m_frame">
      <Pair>
         <key>normal</key>
         <styleUrl>#s_frame_normal</styleUrl>
      </Pair>
      <Pair>
         <key>highlight</key>
         <styleUrl>#s_frame_highlight</styleUrl>
      </Pair>
   </StyleMap>
   <Style id="s_frame_normal">
      <LineStyle>
         <color>ff804000</color>
         <width>2</width>
      </LineStyle>
   </Style>
   <Placemark>
      <name>20070910_01</name>
      <Snippet maxLines="0"></Snippet>
      <description><![CDATA[<a href="http://forum.arctic-sea-ice.net/index.php?topic=400.msg35833#msg35833">http://forum.arctic-sea-ice.net/index.php?topic=400.msg35833#msg35833</a> ...
<a href="https://data.cresis.ku.edu/data/rds/2014_Greenland_P3/pdf/20140508_01.pdf">https://data.cresis.ku.edu/data/rds/2014_Greenland_P3/pdf/20140508_01.pdf</a><img src="https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/images/20130402_01/20130402_01_025_1echo.jpg"/><img src=""/><img src=""/><img src="https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/images/20130402_01/20130402_01_025_1echo.jpg"/>]]></description>
      <styleUrl>#m_frame</styleUrl>
      <LineString>
         <coordinates>
            -27.164,75.372,-9999 -60.351,77.213,-9999
         </coordinates>
      </LineString>
   </Placemark>
</Document>
</kml>

[A-Team]

Ice-penetrating radar data is to Greenland and Antarctica as a CT scan or MRI is to medicine. No way can slumpage to the sea be predicted just from surface goings on and GRACE mass balance, any more than a medical issue diagnosed from flushed skin and a bathroom scale. Indeed, we see articles now on ice tomography and even Radon transforms (1917) making an appearance.

Gimp has an astonishing feature that makes it very convenient for reprocessing the Cresis ice-penetrating archive: it can not only read whole flight Cresis pdfs into layers but lets you pick any subset from the startup dialog. Each flight segment has 3 parts: overview maps at three scales (only the middle useful), the radar scan itself, and the radar scan marked up for ice surface and bedrock by work-study students.

The last of these is done wrong. A continuous line should have been used rather than dashed magenta, done as a separate transparency layer which sits over the primary radar scan if needed. The magenta should *never* have been dithered in irreversibly. They redeemed themselves somewhat by saving bedrock and surface lines as plotable numeric data (which however were not fitted to anything).

I'm not singling out Cresis for imagery incompetence here even though this was enabled 20 years ago in Photoshop -- I see the "layer error" every day in peer-reviewed climate science articles. I also see a lot of "secondary layer error" in which lots of information is economically encoded in a single layer (fair enough) but that information cannot be unpacked only because of poor palette choice and gratuitous final dithering for print. It's all so unnecessary -- gif layers kicked in back in '87. Have you ever see a piece of software that couldn't open a gif file?

Do maps right by habit and you, as well as the reader, can get on with the science -- and come back to it years later to do something else with it.

There are multiple reasons for wanting flight path segments as a stack of co-registered layers: crop out the borders with one click, remove the black box and scale ticks (which should be outside -- never, ever crush expensive data with internal scale ticks), remove overlaps so consecutive images can be tiled, rescale individual layers to a master scale, and consolidate segment overview into an animated map. This reduces the number of files in the archive 6-fold.

Not to be believed: on a single flight, the data is broken up into segment images of ~ 50 km but these do not partition the data (the images overlap by variable amounts, not provided) nor do they use the same scale (scale not provided). Since features of interest, like an isochron line or freezeup deformation, can run over several consecutive frames, the user faces a nightmare scenario in reversing segmentation on any scale. This may require crowdsourcing to fix but then we have a crowd.

It is easy in gimp to add map overview to segment radar data: after import, chain all the overviews so that they move up as a block (relative to stationary radar data), just high enough so used portion of the lower right corner overview is sticking its head up. Here canvas size has to be enlarged, one layer brought to 'image size' (meaning canvas size) and then all layers brought to canvas size via 'fit canvas to layers' (meaning, in gimpspeak, 'fit layers to canvas').

Cropping then reduces to final minimal size. However, I prefer to first move the lat,lon text block as high as possible in the image. The filmstrip fuses layers as a single horizontal line, so the text block can be moved up to the lowest bedrock level found by the flight path. The reason for doing this not just file size: radar echoes below bedrock are artifacts that would affect the histogram and so affect contrast adjustment.

The flight path segments literally show the flight path as flown, no convention on decreasing lat,lon. That means on a grid, half the images need to be reversed. That reverses text, which is rendered as raster by this point. Text as text is still around in the pdf but it takes a script (or horizontal db sort) to reverse order, and more to put it back under the horizontally flipped image.

High precision digital lat,lon numbers are crazy-making. Stop,start coordinates have to be retained but intermediate values could be taken from where the track met a sensible grid so disparate frames can be intersected. The flight id should be removed from the top and replace the self-evident km,lat,lon abscissa explanation repeated thousands of times. The lat,lon system itself should use the NSIDC/Google Earth/Landsat convention (negative longitudes for Greenland).

I'm not sure whether hairpin turn data has any value -- it might be better to segregate it out and only retain straight line segments. Most flights are indeed straight lines, with the only useful exception those that follow the summit ridge line.

There is a huge issue around scale and composition: are the images provided at the maximal resolution of the original data; if not, has this undercut our ability to enhance lower ice layer contrast?

The image below shows EarthExplorer being tricked into serving up exactly the radar data someone is looking for:

[A-Team]

Here is pseudo-code that loads the entire Cresis archive, both Greenland and Antarctica, onto Google Earth. The color highlights show two little strings needed for later systemic 'mail merge' insertion.

Clicking on any segment of interest calls up the full resolution radar scan (with or without surface and bedrock annotation) as well as the segment map.

The link back to the Cresis pdf can be replaced one to plain text there, as processed for segment bearing, lat lon start/stop, and properties associated to the segment taken from other databases such as DEM, ice thickness, surface velocity magnitude and bearing. That information could also be placed in the Google Earth 'get info' box.

https://data.cresis.ku.edu/data/rds/
 https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/
   https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/kml/Browse_Data_20130426_01.kml
replace
      <Snippet maxLines="0"></Snippet>
      <styleUrl>#m_frame</styleUrl>
with
      <Snippet maxLines="0"></Snippet>
      <description><![CDATA[<a href="https://data.cresis.ku.edu/data/rds/2014_Greenland_P3/pdf/20130426_01.pdf">2013_[/color]Greenland_P3/pdf/20130426_01.pdf]https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/pdf/20130426_01.pdf</a><img src="https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/images/20130426_01/20130426_01_026_1echo.jpg"/><img src=""/><img src=""/><img src="https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/images/20130426_01/20130426_01_026_1echo.jpg"/><img src="https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/images/20130426_01/20130426_01_026_0echo.jpg"/><img src=""/><img src=""/><img src="https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/images/20130426_01/20130426_01_026_0echo.jpg"/><img src="https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/images/20130426_01/20130426_01_026_2echo.jpg"/><img src=""/><img src=""/><img src="https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/images/20130426_01/20130426_01_026_2echo.jpg"/>]]></description>
      <styleUrl>#m_frame</styleUrl>

    process next file in line 3 folder, repeat until exhausted
   process next file in line 2 folder, repeat until exhausted
 process next file in line 1 folder, repeat until exhausted
post to cloud

[Andreas Muenchow]

@ A-Team:

Are your detailed comments about graphics file or the actual data files that contain x, y, f(x,y) with physical units attached?

Which radar data files do you recommend using in scientific inquiries?

I use the .pdf or .jpg files merely as a guide to the actual digital data where x is longitude, y latitude, and f(x,y) anything the radar (or laser altimeter) measures.

[A-Team]

Andreas, right, there are different ways to go. Cresis is really built around MatLab format as you mention. However I only use open source methods on this blog (not $2300 proprietary software with big learning curve) to encourage broader visitor engagement with data -- someday we may need crowdsourcing help in curating these scans.

Below I finish stripping out the Cresis archive to Google Earth which is freeware widely used by educated laypeople. I also stripped in the main Greenland relational databases Bamber/Howat/Helm/Joaghin to potentially put more blogger boots on the ground.

You raise a very interesting question, whether there is any better resolution in the f(x,y) numeric data than in the default graphics provided. I would say no. Or at least all Greenland journal articles use the latter.

However a couple of people are coloring Greenland scans according to line by line vertical integration of radar attenuation and displaying them Antarctic-style in iView4D (again, proprietary with free viewer). Bump-mapping definitely improves visuals but I have not seen it used yet to implement a scientific parameter. 

C Panton is the only person I have seen publishing anything intelligent wrt horizon enhancement. Obviously Pleistocene ice contrast needs to be sharpened to the max before auto-digitizing stratification. I think it is a mistake to optimize each scan segment separately when there are intersecting flight paths, nearby grid lines, and multiple years of data on NEGIS, Petermann and Jakobshavn.

It is just astonishing to me that no one has reconstructed 3D subglacial deformation structures when fast free and friendly ImageJ is sitting there with all the necessary plugins for analysis and visualization. I would think these would be laterally anisotropic and bilaterally symmetric wrt the direction of ice flow, with the edges less developed and so revelatory of earlier formation history.

It is vastly more efficient for 2-3 people to do the skilled reprocessing so the kazillions can work off an advanced launch platform. We learned that during the human genome project -- far better to have the assembly, gene tracks and browser as a service provided by specialized professionals rather than rebuilt over and over by incompetent mds as it takes time away from their competency in disease research.

Here is pseudo-code that loads all useful text from entire Cresis archive, both Greenland and Antarctica, onto Google Earth, along with surface velocity, bedrock depth and ice thickness at the midpoint of the track segment.

Not all flight paths are perpendicular (resp aligned) to the direction of ice movement and so those motion component magnitudes need to be provided for interpretation of deformations.

https://data.cresis.ku.edu/data/rds/
 https://data.cresis.ku.edu/data/rds/2014_Greenland_P3/
  https://data.cresis.ku.edu/data/rds/2014_Greenland_P3/pdf/20140521_02.pdf

#download pdf, open in any pdf viewer, select all, paste into plain text editor to dump images, retain text
#open in any database reader such as excel, import with break at 78 lines per record
#create a derived database:
 line 21 extract string with LEFT(xxx,15) to RIGHT(xxx,45) to extract scene name (result 20140429_01_011)
 line 31 extract string with MID(xxx,9,6),-MID(xxx,18,6) to obtain start lat,lon (result 69.321,-49.965)
 line 36 extract string with MID(xxx,9,6),-MID(xxx,18,6) to obtain end lat,lon (result 68.963,-49.982)
#haversine bearing of flight segment http://mathforum.org/library/drmath/view/55417.html
  #convert decimal degrees to radians
    mult 0.017453293 radians/degree
  # bearing angle east of north
      = mod(atan2(sin(lon2-lon1)*cos(lat2),cos(lat1)*sin(lat2)-sin(lat1)*cos(lat2)*cos(lon2-lon1)),2*pi)
#extract direction and magnitude of surface velocity field from Joaghin 2012 using central lat,lon above
#determine ice velocity components Vx,Vy into and along plane of radar section
#extract ice thickness from Bamber 2013 using central lat,lon above
#extract bedrock depth from Bamber 2013 using central lat,lon above
#add 8 fields of derived database to Google Earth descriptor <description>put here</description>

    process next file in line 3 folder, repeat until exhausted
   process next file in line 2 folder, repeat until exhausted
 process next file in line 1 folder, repeat until exhausted
post to cloud

[Andreas Muenchow]

Andreas, right, there are different ways to go. Cresis is really built around MatLab format as you mention. However I only use open source methods on this blog (not $2300 proprietary software with big learning curve) to encourage broader visitor engagement with data -- someday we may need crowdsourcing help in curating these scans.

I totally agree with the sentiment and despite being a scientist, I do NOT use MatLab or any other software requiring licensing fees, pay-walls, or black-box-magic. I love coding in shell-scripts and Fortran (not kidding, I am a dinosaur, but one not yet dead  ... have a look at http://muenchow.cms.udel.edu/papers/Muenchow2014-JGlac.pdf (open access) as a remote-sensing and glaciology paper using some of the data streams we are discussing here (I was then only interested in Petermann Gletscher).

You raise a very interesting question, whether there is any better resolution in the f(x,y) numeric data than in the default graphics provided. I would say no. Or at least all Greenland journal articles use the latter.

I respectfully disagree. Native digital resolution (information content) is ALWAYS better than ANY graphic files. These files usually include information loss and even when it does not such as with GeoTiff, then the display of such files on a pixelated surface (a computer screen or piece of paper) ALWAYS reduces actual resolution.

All that said ... I agree totally with your sentiment that public data collected at tax-payers expense should be made accessible in both graphical and digital form. Strength in diversity.

[A-Team]

"Native digital resolution (information content) is ALWAYS better than ANY graphic files."

Mmm, it depends on useable bit depth (aka significant digits base 2). They are entirely equivalent at 8-bit depth. That is, BMP graphics format will take any f(x,y) matrix of numbers normalized and truncated to that bin depth and makes a completely equivalent graphic out of it: run it the other way, the exact same starting matrix will be recovered from the graphic.

Yes, you can use pi computed to 100 million decimal points to figure the area of a circle but no, you won't learn anything from doing it. Insignificant digits are like bad poker hands: anyone can hold them, disciplined players fold them. For a reason.

You can see from histograms of Cresis graphics -- even pure layer cake, below -- there is nothing remotely resembling 16-bit depth in radar significant digits. Notably, the critical Eemian layer is totally blown out, I'm not even seeing 4-bit precision. We're not really trying to do much more here than watch the autosnake follow along on a horizon or measure thinning away from the summit. Just peak and trough position, not values.

In hindsight, probably a total community screw-up in not re-imaging the f(x,y) contrast contextually. We may need to bring in a really bad-ass digital signal processor to squeeze out the last drops of water here. Weak contrast has been beaten to a pulp in software because of medical imaging.

We went round and round on this topic already with Landsat-8 GeoTiff. The panchromatic comes as 12-bit grayscale, advertised as 16 bit. Indeed tight histogram scenes benefit from that extra precision. However once fully exploited by contrast stretching, no utilizable information is lost dropping back down to 8-bit.

ImageJ can do 32- and 64-bit too though it is rarely asked; Gimp can hold 1000 channels of 24-bit RGB color without breaking a sweat. Wavelet decompositions of optical satellite Greenland poop out already at level 5, why do 10. White snow, drab clouds: nobody home.

I've seen quite a few published examples in Greenland science of certifiably preposterous retention of insignificant digits. There is no usable information in presenting the Bølling-Allerød horizon to the nearest micron when the radar reflection appears ten meters thick.

On the other hand, I'm ok with with someone trying to measure a one meter per year slide of upper ice sheet or isostatic post-glacial rebound with every scrap of high precision dual-phase GPS they can get their hands on.

I never had much use for f(x,y) thinking as a math professor. Research mathematics is not actually done that way but rather bootstrapping off a good picture of the first non-trivial example, say a Hopf fibration. That can quickly morph into incomprehensible publications on irreducible representations of exceptional Lie groups breaking on non-abelian gauge theories. Of course those are written up back in f(x,y) by way of obfuscation.

I think f(x,y) thinking is a big mistake here too, same reason. I myself look for something completely mindless in exploring large-dimensional parameter spaces (eg dragging gimp contrast curve ~ the space of differentiable functions, lots of them) -- the human visual system, especially on autopilot, rarely lets a good pattern fly by. Sure, I might write this up as monte carlo convoluting some cost potential function against a numerical f(x,y) array but I certainly wouldn't do it that way. Not when Gimp has real-time preview.

Nice Petermann article ... and thx for sticking to open source! If I may ask, what is your initial reaction to the RE Bell 2014 deformation paper doi:10.1038/ngeo2179 as far as upstream Petermann goes? It is a total zoo over there.

[Andreas Muenchow]

@A-Team:

I suspect that we mean the same thing, but different disciplinary backgrounds make us use words that have different meaning in different communities. A graphic to me is alway a pixelated version generated from measurements that are not necessarily pixelated (= measured on a regular grid). Measurements are expressed as digits (=numbers) that also carry units. In order for the digit to have meaning (be significant), someone else must be able to measure the process and get the same result. We agree on pi and poker.

I do take offence, however, when you judge that f(x,y) thinking is a big mistake, but perhaps I do not know what your words mean as they may originate from a community using language that I do not speak or think. I take f(x,y) as a simple dependent variable f that depends on some other variables (usually space-time). All are measurements that have acceptable ranges, errors, and units.

The number (=digit) with units always suggests a measurement which also suggests a range of what is reasonable and what is not. This measurement error determines the number of significant digits that an f(x,y,z,t) as well as the (x,y,z,t) carries. There is no point to represent a process that only knows 1 and 0 as a 2-bit number when 1 bit will do perfectly. We agree that a process measured accurately (a number with units this also) at the level of a 2-byte number should never, ever be represented as a 1-byte number. This is waste, it throws away useful information. I suspect that this is what you complain about. It is not discretization that matters, it is discretization relative to measurement error in f and x and y and z and t.

Real things in the real world have real units or scales with real units. So, I correct my prior statement that "Native digital resolution (information content) is always better or equal than any graphics files." It is possible that I abused the word resolution which may have different meaning in different communities. In well-designed physical experiments digital resolution should be close to accuracy of the measurement to maximize efficiency.

[A-Team]

Indeed it just sounds like  differences in specialty languages. Great but the discussion has got me fretting about what the actual vertical resolution in these radar images (hopefully not set by printable page sizes, 1993 and all that).

The scale right now is about 3000 m vertical to 51 000 m horizontal for an aspect ratio 17:1 but could the data have supported say 34:1? No one would be so crazy as to set out on striation markup without maximizing this, yet...

It is a curious situation (now that the bedrock DEM is behind us) in that it would be ok to trade off horizontal for better resolved vertical. There would also be advantages in completely reprocessing the Cresis archive using curvilinear surface/bedrock masking prior to contrast adjustment.

The real gain comes from further partitioning that mask with above/below Bølling-Allerød on flight segments where that is available. However the authors collecting that data islandwide never did anything with it, other than posting a spreadsheet with 495,000,000 cells.

Here is the last bit of pseudo code. Its output is a small Google Earth kml file letting anyone load all 21 years of radar overflight attaching radar horizon imagery to flight path segments. That enables very rapid analysis of all data from all years covering a regional sub-glacial feature, for example a freezeup above Zachariae (see grid overlay below).

Since the radar imagary is not degraded in any way in the Google Earth display and captured cleanly by whole-window screenshot, it is very easy to make trajectories through data from all years. On a Mac, 'command option shift space' puts the image into clipboard, open new window Preview on Mac implements that, horizonal flip fixes grid issues, saving as is as an 'Untitled' document series retains capture-order on disk upon name sort, open as layers gives co-registered images in correct sequence and orientation in Gimp, thus animating the trajectory after intermediate frame interpolation.

This yields perhaps ~20x savings in time needed per feature in getting the data to the human interpreter. The alternative described above for the EarthExplorer web portal is more easily scriptable: the analyst draws a line segment over the flight path display, lat,lon intersections are found based and a gif layer animation created that automatically opens in a new browser tab. Either way, all ~200 regions of putative bottom freeze-ups could be galleried up in a day.

Flight paths are broken into segments of ~50 km. These segments are critical to extracting only the radar imagery wanted for a specific investigation but now are only displayed in Google Earth within the lowest level of the Cresis file hierarchy, not within the second lowest level (flight paths for a given year).

Although Google Earth is capable of displaying the attached imagery for each segment, Cresis did not implement that feature which is just a single kml description line). The pseudo code fixes this, building the appropriate jpg url from the blessedly systematic file storage nomenclature used at Cresis. Only the unannotated 1echo image is attached here; 0maps and 2echo can easily be added or substituted. The image appears instantly upon clicking on a segment; the url itself appears in Google Earth's 'Get Info' box.

The segments themselves are broken into 42 sub-segments, probably to record intermediate surface elevations along the flight track. These sub-segments are not displayed in Google Earth and can only be accessed by opening kml as plain text. Since lat,lon are given to 14 decimal points each (hello?) and the kml files are otherwise rather simple, sub-segments take up over 90% of file size. The pseudo code below captures just the start,stop coordinates of the segment, rounding them to 3 decimal places. (The sub-segment data provided local slope, subsumed already in making the surface and bed elevation maps.)

#replace spaces (%) with tabs (^):
%-
#with:
^-

#replace:
^^<Snippet maxLines="0"></Snippet>
^^<styleUrl>#m_frame</styleUrl>
^^<LineString>
^^<coordinates>
^^^

#with:
^^<Snippet maxLines="0"></Snippet>
^^<description><![CDATA[<img src="https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/images/[chars7-24 line2]/images/[chars 7-18 line2]/[chars 7-22 line2]_1echo.jpg"/>]]></description>
^^<styleUrl>#m_frame</styleUrl>
^^<LineString>
^^<coordinates>
^^^[round(col4,line7triple,3)],%[round(col46,line7triple,3)]

^<Placemark>
^^<name>20130410_01_050</name>
^^<Snippet maxLines="0"></Snippet>
^^<styleUrl>#m_frame</styleUrl>
^^<LineString>
^^^<coordinates>
^^^^-48.84072,69.91995,1010.15 -48.84833700000001,69.90869000000001,985.39 -48.85561,69.89740399999999,1053.44 -48.862802,69.886115,1008.66 -48.870437,69.87485599999999,1004.84 -48.87799200000001,69.86359400000001,842.1499999999999 -48.88549699999999,69.852327,967.3199999999999 -48.893065,69.841065,890.01 -48.900456,69.82979,904.54 -48.90784699999999,69.818516,1129.6 -48.915329,69.807247,1079.1 -48.922738,69.795974,1049.71 -48.930155,69.784705,1315.3 -48.937808,69.77345099999999,1318.06 -48.94497499999999,69.76215999999999,1056.32 -48.952355,69.750888,948.4900000000001 -48.959784,69.73961799999999,970.55 -48.966967,69.728329,1079.28 -48.974771,69.71709199999999,1058.1 -48.982143,69.70582,1096.82 -48.98886900000001,69.694501,1143.99 -48.996553,69.68325299999999,1157.22 -49.003971,69.67198399999999,1012.28 -49.011848,69.66075499999999,1003.4 -49.019463,69.649501,1023.64 -49.026066,69.63817,1087.93 -49.033758,69.62692699999999,1073.76 -49.041128,69.615661,990.2499999999999 -49.048318,69.60438000000001,1024.19 -49.05747600000001,69.593271,1106 -49.064368,69.58196599999999,1082.09 -49.071746,69.570701,1112.34 -49.07907,69.559427,1046.94 -49.08600200000001,69.548125,971.03 -49.093245,69.536845,951.67 -49.10017,69.525542,911.59 -49.107079,69.514239,974.0700000000001 -49.11463499999999,69.50298600000001,943.26 -49.121832,69.491702,982.51 -49.12898400000001,69.480418,1015.09 -49.13621899999999,69.46914099999999,920.21 -49.13757400000001,69.467044,916.28

^<Placemark>
^^<name>20130410_01_050</name>
^^<Snippet maxLines="0"></Snippet>
^^<description><![CDATA[<img src="https://data.cresis.ku.edu/data/rds/2013_Greenland_P3/images/20130404_02/20130404_02_062_1echo.jpg"/>]></description>
^^<styleUrl>#m_frame</styleUrl>
^^<LineString>
^^^<coordinates>
^^^^-48.841,69.920,1010.150 -49.138,69.467,916.280

[A-Team]

Easy to get carried away with extraneous capabilities of Google Earth and forget why you came there. Here I have picked an area of study and started marking up 1993-2013 radar track data (bottom layer) I want to extract with thickening of lines indicating the radar horizon image is loaded and color indicating polarity (east to west, north to south taken as positive).

I'll be happy to get the data into gimp. Google Earth has no undo command whatsoever. It responds irreversibly to mouse-overs even when not the active software. It saves but doesn't say where or under what name. It is somewhat aware of standard interface conventions yet one commonsensical but unfortunate click can send it into a tailspin. However it is a very serviceable interface to the Cresis data and would not take much to automate.

[Espen]

A-Team you are unstoppable

[A-Team]

I may have gone too far this time, Espen. No idea how to get back and only a couple hours of battery left. Was trying to make the point (inset, upper right) that there are 2-3 irregular tracks from other years angling across the more favorable rectilinear grid. The idea here is make the 3D model from the grid alone, that is, hold back the cross-grid tracks to test model interpolation.

[Espen]

Easy to get carried away with extraneous capabilities of Google Earth and forget why you came there. Here I have picked an area of study and started marking up 1993-2013 radar track data (bottom layer) I want to extract with thickening of lines indicating the radar horizon image is loaded and color indicating polarity (east to west, north to south taken as positive).

I'll be happy to get the data into gimp. Google Earth has no undo command whatsoever. It responds irreversibly to mouse-overs even when not the active software. It saves but doesn't say where or under what name. It is somewhat aware of standard interface conventions yet one commonsensical but unfortunate click can send it into a tailspin. However it is a very serviceable interface to the Cresis data and would not take much to automate.

A-Team interesting to see there was not much interest in 79 compared to Zachariae.

[A-Team]

Yes and interest waxed and waned even there. The big grid fly-over was in 2010 by DC-8. That was supplemented by P-3 flights in 4 other years. In some cases, those provided exactly the missing grid lines, though probably with quite different radar arrays.

However these flight lines were archived as ~50 km units that are inconveniently chosen with respect to grid cells. The flights themselves were not quite north-south/east-west but approximately aligned with and against ice movement.

Going off into the weeds, one of 'vertical' lines was not up a meridian, moving from 26.914 to 26.662 or 5.5 km off vertical and the 'horizontal' grid line hopefully 'orthogonal' went from lat 78.494 to 79.515 or 3.0 km off constant latitude, both over ~50 km using http://www.movable-type.co.uk/scripts/latlong.html.

I don't know who requested this coverage nor what became of it in terms of publications. It may just represent a parcel of programmatic coverage of marine outlet glaciers: bedrock troughs and sills, surface thinning and ice shelves.

The image below illustrates some of the technical issues involved in using flights here -- one of the most intensively surveyed areas in Greenland -- to extract 3D structure from bidirectional 2D slices. Just pulling up archived imagery, re-tiling flight segments, and aligning relevant parts along a meridian (or subglacial feature axis) is already quite a chore.

I'm just about there with that but then there is the issue of display manipulation and interpolative software for doing this effortlessly (as a petroleum geologist or xray technician would).

[A-Team]

Here is how those flown grid lines up from 89N and Zachariae stack up for lat,lon according to the kml overlays as measured Google Earth.

I've also added the direction of icestream flow down from its summit origin (bright red arrows); it is considerably broader than shown. Three earlier flights came directly down the center (considered later). Ordinary icesheet flow, ~50 m/yr, comes from the left. Flow direction is quite oblique to the grid flown.

Measurements show that grid 'squares' are neither square nor even rectangular, even making allowances for spherical earth approximations, deepening the mystery of flight plan intent. The left edge of the grid is 98 km.

I've added an underlay (yellow spray paint) of very approximate positions of bottom freezeups reported by RE Bell 2014. Even though this is one of most intensively areas in Greenland, track density still does not provide adequate sectioning 'resolution'. That is, the freezeup features, though maybe a dozen sq km in extent are too small for detailed 3D reconstrucion. Drone radar -- not yet available for Greenland -- can easily provide the cross sectional coverage required.

It is also quite feasible, as explained a few posts back, to re-process the entire Cresis archive (in the pdf per-flight format) and mark up every intersection of every flight segment with every other segment after WGS84 y=mx+b considerations, noting every angle of intersection (relative bearing).

This would allow auto chaining up of every flight into one giant islandwide grid system. It is custom and culture for the database host to provide or at least serve these large pre-computes. Conceivably it lies in the matlab sector of the archive. It must have been done at some point within Bamber 2013 to arrive at the bedrock net prior to re-gridding. The EarthExplorer server and mid-level GIS software routinely provide intersection data.

However next post shows a quick way of doing this yourself without writing a line of code, purchasing proprietary software, or waiting upon an institution to implement.

[A-Team]

It is straightforward to build an flight path intersection tool and proximity detector. Begin with the simple flat-file database described above -- all the text, none of the images -- found in the pdf files Cresis provides for each flight.

There are 22 flight groups for Greenland from 1993-2014. These average a dozen or so individual flights, and those flights average a couple dozen flight segments.  For each flight pdf rendered as text extracting cells 61-62, 85 and 120-121 and re-tabbing reduces archive to a manageable 3-column, ~6800 line excel-type database of the form:

Data Frame ID     StartLatCoordN  EndLonCoordW
20140409_01_019   78.798          26.583
20110511_03_001   78.519          23.219
20100413_01_001   78.912          22.885
20030512_01_029   78.313          23.579
19990517_01_014   79.107          26.460

To find all flight segments "in proximity" to a given segment (eg 20100413_01_001), first consider its bounding box (below, dotted box around gold arrow). This consists of its horizontal longitude constraint intersected with its vertical latitude strip, which are determined by the start, end coordinate pairs (lower left, upper right corners of bounding box).

In the example illustrated, the dark blue arrow actually intersects the initial flight segment whereas the green segment is merely in proximity (one foot in bounding box) and could not quite be used to chain out a continuous grid from the initial segment. The purple flight segment arrows might also be considered in proximity depending on how loosely that parameter was set whereas the pink arrow is probably out of bounds in terms of relevance.

Sorting the database first by the latitude column and then by longitude quickly selects all records with a foot within the bounding box (or however conditions are relaxed), in this case the blue and green arrows.  A brief linear algebra consideration (two line equations y=mx+b) gives the common point of intersection of the blue line with the initial gold segment but the point from the green line intersection does not fall on the green arrow.

Note in the case of the flight path of the gold arrow, the previous and subsequent flight segments are known to slightly overlap so both qualify as intersecting segments. Here the points of intersection indicate redundancy and so guide automatic clean fusion (ie tiling) of consecutive flight segments.

Iterating now off the blue arrow, the full grid of intersecting ice penetrating radar sections that include the initial gold segment can be chained out to a specified number of rounds or for a larger bounding box.

This database could be constructed just once and then provided as backend to an search portal, much in the manner of Landsat and Sentinel image servers: the visitor draws a path or a bounding box and receives back a zip file containing the relevant Cresis profiles and metadata describing overlap and intersection that allows their interactive display in a free 3D frame viewer such as used in Antarctica (link given earlier).

[A-Team]

Here is the best single frame for the bottom freezeup due west of 79N in northeast Greenland. The three slides show as-is at Cresis, enhanced grayscale (mostly unsharp mask plus sinusoidal bump map), and colored tentatively by region. The ultimate idea with interpretation is to identify the physical process at work via their impact.

The flow of ice here is west to east, approximately in the plane of the radar section. Thus the main uplift is on the left and the rest is earlier uplift that has moved downstream. Note the uplift is not manifested as a surface disturbance and cannot be attributed to sharp peaks or valleys in the bedrock -- many more extreme bedrock profiles have relatively undisturbed ice profiles.

Holocene layers have slumped as (river analogy) they rose over the boulder and entered the low pressure eddy behind it. This is mostly a story of late Pleistocene ice with enhanced rheology due to warmer temperatures from adjacency to geothermal source and from latent heat released by bottom water freeze-on.

Fifty cubic km of ice didn't lifted up yesterday; the deformation instead represents a process starting some twenty thousand years ago that continues more rapidly today (though still slowly). It's easier to deform sideways than lift all that ice above, given the disappearance of back pressure at the ocean front -- squeezing a tube of toothpaste under a heavy rock.

Next, fill out the shape using nearest grid neighbors, work out the volume better, and make a heuristic animation showing this feature growing from its earliest beginnings.

[A-Team]

Bump maps provide 'unreasonably effective' enhancements of radar imagery, at least perceptually. Mostly gimp/PS/imageJ users explore filter tools and settings at random, occasionally finding something with a nice effect, never looking under at the hood at what the tool is doing mathematically.

That works, but below I chase down how bump maps work and whether parameters can be chosen rationally on a per-image basis (perhaps locally) and so optimally enhance the whole ice-penetrating radar archive as a pre-compute This might follow upon, or be integrated with, Panton's initial reprocessing (elliptical unsharp mask) which already removes a lot of noise from radar horizon data.

On a flat grayscale image, bump maps first compute a very fundamental mathematical object, the gradient: a vector at each pixel whose direction points to steepest descent (pixel values on the 0,255 scale decreasing fastest) and whose magnitude measures that. On a familiar contoured hiking map, the gradient describes the initial route and potential acceleration of a fallen raindrop.

This is already good news for radar profiles because the gradient is physically meaningful being naturally orthogonal to radar horizon bands. At gentle deformations, striations are still follow-able but now sloped so the gradient is no longer quite vertical, with that departure described for each reflector by Panton's slope map.

From the image's gradient, bump maps create a shaded relief map according to how lighting is set by parameter choices. For an ordinary digital elevation map, these vary sun azimuth and elevation until the landscape is favorably illuminated, with shadows providing the visual clues for vertical dimension.

That's done by taking the dot product (projection) with respect to a second unit vector at each pixel representing direction to the light source. This amounts to the magnitude of initial gradient vector x the cosine of the included angle. The resulting scalar is then mapped to the 0,255 grayscale, with flatter gradients at lesser projections resulting in darker shades of gray.

This creates a new image with the same dimensions as the old but now realistically shadowed, representing the gradient and a light source. If realism is not wanted, the x,y components of the gradient itself can be captured in any coordinate system by two special cases using zero elevation and orthogonal azimuths, with gray again giving magnitude.

Gimp provides an additional depth control slider that amounts to changing contrast via 'equalize' histogram followed by a specified degee of 'fade'. That command expands the contrast locally in proportion to the pixel population at each level of gray; it can also done 'rationally' within the 'levels' menu.

So far, this is just a description of 'emboss', only the first round in the bump map process. However it already raises issues of the balance between scientific and esthetic image processing, as well as optimal processing of segments containing deformations, adjacent segments in a flight path, neighboring segments taken in different years with different radar configurations and indeed whether the whole archive could or should be reprocessed.

The first animation below holds elevation and depth constant at 45º and 25% while varying azimuth by increments of 30º. The second holds azimuth and depth constant at 245º and 25% while varying elevation by increments of 30º. The third holds elevation and azimuth constant at 120º and 245º while varying depth by increments of 10%. I reduced file size but you may have to click to get animations started.

[A-Team]

The animation below shows some enhancements that draw out features that might not have been so evident in the original scan, though usually the feature can be recognized once you look back.

The second image shows four consecutive slices north to south on the 79N/Zacharie grid described above. The second frame is the one enhanced separately above at higher resolution. Note the surprising series of little blips to the right that extend more consistently than the any of the large dramatic features. They run some 40 km and are not bedrock induced deformations but possibly incipient bottom freeze-ups induced by sheet water flow.

[Espen]

More calving and further retreat at Zachariae Isstrøm: