Metadata and Reports Download Links

[rkelson]

It looks like there is an issue with the Metadata and Report links in Step 4 of the application.

Below is an example of one of the incorrect links: https://raster.utah.gov/n/aFEMAHQ_2018_Metadata.zip

I have a feeling these were broken when we migrated away from FTP storage and started showing n/a for FTP_Path in the more info window.

I've often wondered where else _FTPPath in the Extents layers were being used.

I think there is somewhere in the code that looks to see if the Extents layer's METADATA and REPORT field values are or not based on project vs. tile based metadata or reports, In addition to evaluating if FTP_Path is populated with somethings like https://storage.goo...

Let me know what you find. We could 1.) scrap the Reports and Metadata links in Step 4 or 2.) start using/populating the FTP_Path differently.

[stdavis]

I took a look at this code. Here's the code that builds those links:

const checkProjectLevelLink = (fld, node) => {
  const value = this.graphic.attributes[fld];
  const hasValue = value && value.length > 0;
  if (hasValue) {
    node.href = this.graphic.attributes[config.fields.common.FTP_Path] + value;
  }
  domClass.toggle(node, 'hidden', !hasValue);
};

checkProjectLevelLink(config.fields.common.METADATA, this.metadataLink);
checkProjectLevelLink(config.fields.common.REPORT, this.reportLink);

If there is a value in either the METADATA or REPORT fields in the extent feature, it prepends it with the value in the FTP_Path field and sets the link.

Here's an example feature:

Average_File_Size: "63 MB"
Category: ".5 Meter {2013-2014 LiDAR}"
Contact: "AGRC - Rick Kelson - RKelson@utah.gov - 801-538-3237"
Coverage: "2013"
Description: ".5 Meter Bare Earth LiDAR DEM / DTM"
Estimated_Date: "11/15/2013"
FTP_Path: "n/a"
File_Extension: ".img"
File_Format: "IMG"
FlightDate_Location: "n/a"
HTML_Page: "https://gis.utah.gov/data/elevation-terrain-data/2013-2014-lidar/"
Horizontal_Accuracy: "n/a"
In_House: "Yes"
Interval: "n/a"
LYR_File: "n/a"
METADATA: "WasatchFront_2013_2014_LiDAR_Metadata.zip"
OBJECTID: "49"
Product: "Bare Earth DEM / DTM"
REPORT: "WasatchFront_2013_2014_LiDAR_Report.zip"
REST_Endpoint: "n/a"
Resolution: ".5 Meter"
SHAPE: "Polygon"
SHAPE_Area: "6398765230.546559"
SHAPE_Length: "1326110.621818"
SHOW: "Y"
ServiceName: "Null"
Tile_Index: "LiDAR2013_2014_50cm_WasatchFront_DTM_Tiles"
Total_Size: "~ 70 GB"
Total_Square_Miles: "1,422 sq/mi"
USGS_QualityLevel: "QL1"
Upload_Date: "9/14/2014"
Vertical_Accuracy: "FVA 9.25cm RMSEz, and 18.1cm at the 95% Confidence Level"
Year_Collected: "Fall 2013 Spr 2014"

Is there a way that I can build a valid link to the metadata and report from this data? If not, then maybe we scrap the project-level links and just focus on tile-level links?

[stdavis]

I make some changes so that it hides the project-level links if FTP_Path is n/a. Does that solve the issue from your perspective, @rkelson?

[rkelson]

Sorry I am just seeing this. Let me look at it more after todays meetings

Rick Kelson Utah AGRC 801.433.7891 gis.utah.gov

On Fri, Apr 9, 2021 at 1:03 PM Scott Davis @.***> wrote:

I make some changes so that it hides the project-level links if FTP_Path is n/a. Does that solve the issue from your perspective, @rkelson https://github.com/rkelson?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/agrc/raster/issues/48#issuecomment-816896291, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPJ43LYQBA3CBQP32WSAEDTH5FRNANCNFSM4VGJ72MQ .

[rkelson]

I am not sure the changes you made are working as expected. I think there is code that says something like:

if ftp_path like 'https%'
     ftp_path displays 'n/a' in the _more info_ window

In the Lidar extents ftp_path, Metadata and Reports are populated so I am not sure what is going on. I am not seeing any links for project level things anywhere.

• We could display the GCP paths in the more info window even though a hyperlink would not be of value. It would only be useful for scripting bulk downloads.
• If you are going to get angry we can just leave it as is.

[stdavis]

This commit was the key to fixing this issue: 5fdb9db28f26a8c602b0601c733e2c5bb16926e4

Pushing a new build to prod shortly...