I�??m concerned about observed inconsistency in an exported tiff layout. Some of the cells are clearly processed at a much coarser resolution than neighbours, and in a region than the source data should be heterogeneous. See attached screenshot. (I don�??t have coordinates for the area because Arcmap doesn�??t know how to export an image with geo-referencing from a layout. It�??s in Northern British Columbia, approximately 56.5N to 57.5N). If this kind of random cell size change also happens when doing analysis we can�??t trust any of the results.
It�??s not clear what could be the reason for this (may be data is not rendered fully before export). Can you try again and see if you are getting same output? Can you send us the shapefile of the area with detailed steps of your workflow upto the point where you get the image below to further investigate. Please send the details to worldelevation@esri.com.
It�??s not clear what could be the reason for this (may be data is not rendered fully before export). Can you try again and see if you are getting same output? Can you send us the shapefile of the area with detailed steps of your workflow upto the point where you get the image below to further investigate. Please send the details to worldelevation@esri.com.
Thanks Rajinder Nagi
My previous post included a map package which should have everything needed to reproduce the error.
Later: Oh. There's something buggy with Arcgis.com. Even though that package is marked share with Everyone (Public), only organization members are allowed to download it. I've attached a duplicate to this message. Is it still necessary to email (e.g. do they monitor this forum)?
Also I see page size is not saved in map package. Here are my steps:
open the map package
set page size to 79.9 inches wide by 60 inches tall
turn off all layers except "Hillshade_Clip_WorldElevation\Terrain"
File > Export map > TIFF
[INDENT] General: 300 dpi, 23969 x 18000 pixels Format: 8-bit Grayscale, LZW compression, background color: untouched (a neutral gray) [/INDENT]
Host machine is: [INDENT] Win7-Pro x64, 12GB RAM, Dual Xeon 2.5GHz (4 cores each) 43GB free on Windows and Programs drive (C:) 25GB free on output drive (D:)
ArcGIS Desktop 10.2.1 License: Advanced Version: 10.2.1.3497 64bit background geoprocessing installed (but this doesn't seem to be used for map exports[/INDENT]
During export Task Manager reports ~15-20% CPU usage (spikes to ~90% on a single core) and 7.2GB physical memory consumed (4.5GB free). Network usage is ~1.5% (of 1Gbps). Arcmap.exe itself is only using ~115mb of memory; about a dozen programs are open (typical work day: browsers, Outlook, Word, Onenote, text editor, command prompt, another Arcmap, folder windows).
The export takes a little under an hour to complete, and the results are near identical, meaning the coarse/fine resolved areas occur in the same locations. Indeed, now that I examine more closely, the fine resolution (and more faithful to the original) is the exception rather than the rule. Basically everything North of 60 degrees has been downsampled to the extreme, using almost 1000m cell sizes whereas (most of) south 60deg is ~100m (closer to the nominal scale of ~30m). See attached screenshot which clearly shows the gross discrepancy.
The reply is sent to your e-mail and cross posted here:
Thanks for sending the details. After investigating the issue you described, I am providing the solution/reasoning below. World Elevation Image services are multi-resolution and multi-source product which gives a seamless experience while panning/zooming anywhere in the world. Depending on the scale being viewed; data from one of the datasets within the service will be returned. This image service uses a default mosaic method of �??By Attribute�?�, using Field �??Best�?? and target of 0. Each of the rasters has been attributed with �??Best�?? field value that is generally a function of the pixel size such that higher resolution datasets are displayed at higher priority. At the scale (1:1,500,000) you are exporting your map, there are two datasources visible in your map extent viz. GMTED2010 7.5 arc second (~232 m) and SRTM (~93 m). However SRTM coverage is only upto N 60 degrees, which is right at the edge of your AOI which gives partial coverage for the map extent you are working with. Since SRTM has higher display priority, it covers part of GMTED which has full coverage and that's the reason you are seeing the output of two different resolutions. Map export is based on what you see what you get principal. Moreover when you are comparing the output with dynamic service, you zoomed to a larger scale 1:1,50,000 where a finer resolution datasets i.e. NED 2 arcsec (~60 m) kicks in, which invalidate the comparison. This is not a bug but how these multi-resolution services are designed. For doing analysis, you should use single resolution of dataset which covers whole area of your AOI and in this case it�??s GMTED. You can use definition query on field ProductName or DatasetID on the service to limit the product/resolution you want to work with. You can also display the footprints for each raster from display tab of Image service layer properties. In few days we will be releasing a coverage map showing data extents and also improved item descriptions for these services. There will be an ArcGIS item for each server function defined on the services. Please visit Elevation Layers group in few days for the updates.
Hope this helps and you can now produce correct results. You can contact technical support for any issues and they would be able to walk through your workflows. Rajinder Nagi
Thank you for the increased info on the background structure. I'll definitely explore using definition queries to restrict the desired sources. I hadn't thought of that.
At the scale (1:1,500,000) you are exporting your map, there are two datasources visible in your map extent viz. GMTED2010 7.5 arc second (~232 m) and SRTM (~93 m). However SRTM coverage is only upto N 60 degrees, which is right at the edge of your AOI which gives partial coverage for the map extent you are working with.
I still think there's something else going on:
There is the band of coarse pixels from 56.5N to 57.5N, well within the SRTM coverage
In the export the pixel size north of 60 is ~1000m, not the ~272m of GMTED2010
Thank you for the increased info on the background structure. I'll definitely explore using definition queries to restrict the desired sources. I hadn't thought of that.
I still think there's something else going on:
There is the band of coarse pixels from 56.5N to 57.5N, well within the SRTM coverage
In the export the pixel size north of 60 is ~1000m, not the ~272m of GMTED2010
In April release of World Elevation, we have improved the item descriptions.
Also we released a elevation coverage map which can help to investigate the data available at a particular location.
