"resolution" in meters of the underlying source data and/or DEM being used to estimate elevation

Moses's Avatar

Moses

09 Jan, 2021 07:32 PM

Feature Request: On CalTopo maps (desktop and apps) provide the estimated "resolution" in meters of the underlying source data and/or Digital Elevation Model (DEM) being used at the center point of the map (ex. 1 meter, 3 meters, 30 meters, etc.), from which the elevation estimate at the center of the map is being obtained.

This information could be provided in the upper right portion of the map in the "infobox" below where the elevation estimate is provided..

Thanks, great products!

  1. Support Staff 1 Posted by matt on 13 Jan, 2021 07:32 PM

    matt's Avatar

    It's a good idea, but I don't see us doing this as I think it would be misleading more than helpful.

    The biggest distinction in data quality is between LIDAR-derived and non-LIDAR-derived datasets. For areas that have LIDAR coverage, the underlying resolution (say 1m vs 3m) does not feel terribly relevant, and either way, the data is resampled to fit a given web mercator zoom level. As you move towards the poles, the scale on the mercator projection changes, so 1 meter source LIDAR dataset that's resampled to zoom 16 might be ~2 meters in San Diego but ~1.5 meters in Washington. Do we communicate the 1 meter source resolution even if the data has been resampled to something lower than 1 meter? If we report our native resolution, do we pick a given latitude and assume it will be close enough?

    Before we added LIDAR data from the USGS 1/9 and 1m datasets, shaded relief and slope angle shading for the entire US was based on the USGS 1/3 NED, which is nominally a 10m resolution but packaged in a lat/long projection, so the X and Y axes actually have different resolutions since a degree of longitude shrinks as you approach the poles. However there was a huge quality difference between areas that were based on resampled LIDAR data, like Mt Rainier, and areas that weren't. Our contour layer is currently based on the 1/3 NED, so you can see this by comparing contours on Mt Rainier to contours from say Yosemite.

    There's a lot of information floating around out there with regard to slope angle shading accuracy and dataset resolution, and while I won't argue with the intention of convincing people not to blindly trust their map, IMO it's extremely misleading. When I compare the old 10m Mt Rainier slope angle shading layer to the current (3m?) data, there is very little fidelity loss in the 10m dataset.

    Conversely, there's a huge difference between the USGS 1/3 NED in a place like Yosemite, and areas that have been flown with LIDAR. That's because the 1/3 NED there is based on surveys and/or stereo imagery (the USGS doesn't specify, only listing it as "diverse source data"). Even though the file has a 10m resolution, that's not the resolution of the source data. I don't think the source data even has a "resolution" - in doing LIDAR/non-LIDAR A/B comparisons, there are areas where the survey-based data shows steeper slopes that don't exist in LIDAR and vice versa. It was a human process with human errors, and it also produced contours rather than a grid of numbers. Either way, calling it a "10m dataset" is not an accurate representation, except in areas where it's based on downsampled LIDAR data.

    It would would take some work, but we could supply a source dataset resolution number in the UI. However, it's a solution that would fall into the category of a "clear, simple and wrong" solution to a complex problem.

  2. 2 Posted by Tom Cal on 13 Jan, 2021 09:57 PM

    Tom Cal's Avatar

    Thoughts about instead of a number, providing something in the map infobox
    indicating if the DEM is "high resolution", such as "hr"?

  3. 3 Posted by Tom on 14 Jan, 2021 04:54 PM

    Tom's Avatar

    Matt,
    Thanks for your thoughts and insights!

    Given "The biggest distinction in data quality is between LIDAR-derived and non-LIDAR-derived datasets. "

    Maybe, on a map, communicate to the user if the underlying data is LIDAR-derived, that does not require the user to click anything, and that does not require the user to load another layer (ex. the CalTopop layer at  https://caltopo.com/l/CM87 . 

    Perhaps this can be done by adding "hr" to the map infobox or elsewhere on the map, when the elevation data at the center fo the map is LIDAR-derived, and/or when all the data on the map is LIDAR=derived?

    (Currently, my workaround to this "feature" is to load and unload the "High Res Coverage data this mao offers https://caltopo.com/l/CM87 , and it would be convenient to not need to load and unload that layer.)

  4. Ben Lantow closed this discussion on 04 Feb, 2021 03:48 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

07 Mar, 2021 05:06 PM
07 Mar, 2021 06:18 AM
07 Mar, 2021 06:05 AM
05 Mar, 2021 09:54 PM
05 Mar, 2021 07:19 PM

 

04 Mar, 2021 05:26 PM
04 Mar, 2021 05:20 PM
04 Mar, 2021 04:23 PM
04 Mar, 2021 02:53 PM
03 Mar, 2021 02:51 AM
02 Mar, 2021 07:18 PM