SRTM Download in V11.00 and V11.01
schufti
Global Mapper User
Hi!
There seems to be a bug in the download of SRTM data. If I directly dld for example the 38_03 tile from http://srtm.csi.cgiar.org/ or the area 6-7E/ 49-50N from http://seamless.usgs.gov and compare them with the same area dld via the inbuild SRTM download, I can see a shift of the tile and some distorting along the 30' lines. A comparison between the 2 manualy downloaded areas results in <1m differences.
rgds,
Gottfried
There seems to be a bug in the download of SRTM data. If I directly dld for example the 38_03 tile from http://srtm.csi.cgiar.org/ or the area 6-7E/ 49-50N from http://seamless.usgs.gov and compare them with the same area dld via the inbuild SRTM download, I can see a shift of the tile and some distorting along the 30' lines. A comparison between the 2 manualy downloaded areas results in <1m differences.
rgds,
Gottfried
Comments
-
Gottfried,
The built-in SRTM access comes from a NASA/JPL server and should be the actual SRTM data, but it may be sampled differently, so there could be some difference within the SRTM horizontal resolution (3 arc seconds, or about 90m). Given such a large sample size differences of <1m could certainly be expected.
Let me know if I can be of further assistance.
Thanks,
Mike
Global Mapper Support
support@globalmapper.com -
Hi Mike,
thanks for the fast reply.
Is srtm data from the online data download displayed directly (in orig. sampling, resolution) or is the data resampled depending on the entered limits?
If I download a 1°x1° tile from http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Eurasia/N49E006.hgt.zip (download facility of NASA/JPL) and import it in GM (with .hrd built as mentioned in the relevant doc) I still get differences compared to the same tile downloaded with the online data download. The online downloaded data is displayed exactly 1/2 cell shifted to the SE.
It seems to be a case of interpretation of the coordinates reference. From the building process for the srtm3 it seems logical that coordinates refer to the height value of the center of the cell (as being built as average from the center 1" cell and 8 surrounding 1" cells). That also conforms with the example for the building of the .hdr file (according to ESRI ulxmap and ulymap refer to the center of the cell) and data loaded via this way displays accordingly (6.0°E/50.0°N is the center of a cell).
Data downloaded via the "online data download" is displayed with 6.0°E/50.0°N being the corner of a cell, what I asume in error.
rgds,
Gottfried
P.S.: the config for autom. antialiasing seems to have no function. every raster I load gets interpolated -
Gottfried,
The online data SRTM source comes from a WMS server and is thus provided in numerous different zoom levels for display and export, so depending on your zoom level you may be pulling from a different layer with different cell alignments. I'm honestly not sure what type of sampling method was used for the online SRTM source from the NASA/JPL server. We have no control over that data., but it is possible there is a half sample shift, or you may just be seeing an artifact of different sample locations with perhaps a nearest neighbor sampling algorithm used rather than interpolation. The data comes down from the WMS source as a PNG file with 16-bit samples for the actual elevations within a grid cell.
For the best available SRTM data that has been fixed with other sources and had other enhancements applied, I would directly download the data from the CGIAR site rather than using the built-in SRTM or the seamless.usgs.gov site.
By default, all elevation layers have interpolation enabled on import. For non-elevation raster layers (like imagery or scanned maps), interpolation is not enabled by default unless you check the advanced option to do so.
Let me know if I can be of further assistance.
Thanks,
Mike
Global Mapper Support
support@globalmapper.com -
For the differences between tiles downloaded directly from NASA/CGIAR, and through Global Mapper via WMS, is there really any call for resampling?
Gottfried seems to be talking sense, that there seems to be a problem of coordinate referencing, though it may not be GM that's at fault.
Does GM interpret SRTM data as cell-centred or corner-centred? Does it make the same interpretation for SRTM data loaded from source (as .hgt or GeoTIFF) as it does for data loaded via WMS?
Gottfried suggests that GM reports cell-centred data for direct loads, but corner-centred data for WMS access.
I wonder why. Is it that GM assumes corner referencing for all WMS data? Or is NASA's WMS server broadcasting incorrect metadata? -
The corner-vs-cell center referencing is a function of the data format used. For most elevation formats, the data is cell centered, although there are some exceptions for some formats that specifically specify corner-centered regardless of the data type. For the WMS SRTM downloads what you request from the server is a rendered bounds, so that is how it is interpreted.
I wonder if what you are seeing is the edge render issue in Global Mapper caused by interpolating rendering in GM not crossing individual layer/tile bounds, causing a visual boundary along tile/layer boundaries, even if the data itself doesn't have any discontinuity. With the tiled WMS access you would see a lot more of these boundaries as compared to larger downloaded files.
Thanks,
Mike
Global Mapper Support
support@globalmapper.com -
Hi Mike,
I attached a screenshot from the situation I am talking about (see upper left corner). First the .bil was loaded and zoomed, then the SRTM downloaded with preset boundaries.
If it is that "SRTM3" data dld via GM isn't sure to be SRTM3, it would be wise not to reference it as such. It might also be considered misleading to refer to CGIAR data in case of failure, if originaly NASA/JPL is loaded which has different "improvements".
All sources of SRTM3 I could get hold of (streaming server, http://dds.cr.usgs.gov/srtm/version2_1/, even http://srtm.geog.kcl.ac.uk/portal/srtm41/) with their different delivery formats load and display matching in GM (except where CGIAR has different improvements)
But I understand now that the SRTM download has to be used with care and where critical should be replaced by manual download from appropriate sources.
Anyways, thanks for generally providing such sophisticated software for free!
rgds,
Gottfried
Categories
- 12.8K All Categories
- 5.7K Features Discussion
- 345 Downloading Imagery
- 1.3K Elevation Data
- 385 Georeferencing Imagery Discussion
- 636 GM Script Language
- 54 User Scripts
- 114 GPS Features
- 417 Projection Questions
- 826 Raster Data
- 1.3K Vector Data
- 6.6K Support
- 178 Announcement and News
- 913 Bug Report
- 558 SDK
- 1.2K Suggestion Box
- 3.7K Technical Support
- 569 Other Discussion
- 131 GIS Data Sources
- 27 Global Mapper Showcase
- 238 How I use Global Mapper
- 107 Global Mapper Forum Website