I'm not sure if this is a bug, or an error on my part .... [DEM tile missing data]

Another question from an OpenTopo user regarding potential data gaps:
--------------
A new Message has been Submitted:

Entry Date: 2008-12-30 12:42 PM
Subject: Report Bug
Message: I'm not sure if this is a bug, or an error on my part ....

Several data files in the OpenTopography (No Cal LiDAR GeoEarthScope) project are apparently missing large chunks of data, even though they are not called out in the metadata or other materials (as far as I can tell) as areas that need to be reflown.

Examples: grid574_4130 and grid574_4129. (And to a lesser extent: grid573_4130, grid574_4131, and grid573_4129.)

Is there really a full 1 km square of 0.5m DEM data in these files, or is this a bug?

Thanks for looking into this.

My reply (initially via email, reposted here):
-----------------------
Hi,
Those files are not missing data. The geometry of the dataset is generally a long, narrow swath parallel to the major faults in the region. The data are arbitrarily tiled out into 1 km^2 tiles regardless of how much data falls in the tile. So, for tiles that fall on the edge of the data acquisition there may be very little data in a tile. You can see this issue clearly if you overlay the hillshade data on the tile index in Google Earth (both files are available via OpenTopography under "Google Earth files" ( http://www.opentopography.org/kml).

I've discussed this issue in a post on the forum related to the Garlock (GeoES SoCal data) because it is a common misconception among users.
Direct link to the topic related to "data gaps", including a screen capture to explain the issue is here:
http://opentopo.sdsc.edu:8080/jforum-2.1.7-b3/posts/list/27.page

Hope this helps,

-cc

More on this issue of incomplete DEM tiles downloaded from OpenTopo - because this is a problem that has been encountered by other users, I am going to continue to post the dialog here.
--------------------------
Christopher,

Thanks for the swift reply. I had been aware of the "edge" issue, but perhaps mistakenly thought it applied only to the edges near the lines indicating the extents of the data collection.

The data missing from 574_4130 is on the "interior" side of the tile, but I realize that still makes it a bit like the case of 502_3938 which you've already addressed in the Forum.

But in the case of 574_4129, it is surrounded by 8 other tiles and is therefore entirely "non-edge" as far as I can tell.

So is it true that the "edge" issue can apply to any tile in the whole collection, regardless of how far it is from the acquisition edges?

Response to above followup question
----------------
Hey,
So, you've stumbled into another subtle complexity caused by the way the data are organized and delivered by NCALM (the guys who actually did the data acquisition). Tile 574_4129 is in an area of overlap where data was acquired on two separate days (day 088 and day 089). Therefore there are two DEMs for one km^2 tile area. If you click just right on the Google Map or Google Earth tile download interface the button explodes into two buttons, allowing you to download both DEMs available for that tile. In this case, the two urls for tile 574_4129 are:
http://cordillera.la.asu.edu:8080/NoCAL/MapServlet?mapid=574_4129_07_089.ZIP
http://cordillera.la.asu.edu:8080/NoCAL/MapServlet?mapid=574_4129_07_088.ZIP

One of these gives a complete DEM, the other is the edge of an acquisition and hence is incomplete despite appearing to be in the middle of the acquisition. Take a look at the attached screen cap...you'll note that the cyan lines show the edge of the acquisition area and each day of acquisition is a separate polygon. In this case, tile 574_4129 falls inside both the acquisition to the north and the acquisition to the south, hence the two tiles.