Latest Contributions by FrancesBiles1

‎05-06-2024

Thanks to Joel and Michael for highlighting this issue. Well put Michael, agree 100% with every point you made.

‎06-15-2021

Kudos to @BojanŠavrič for pointing out the mixed horizontal and vertical reference systems and the need to install the additional Coordinate System Data file. However, BEWARE there are bugs in the ArcGIS Pro Project Raster tool when using it for vertical transformations. These are confirmed ESRI bugs that were identified when going from NAD 1983 (2011) State Plane Alaska 1 FIPS 5001 (Meters)/NAVD88 (Geoid12b) --> ITRF08 geographic coordinates and ITRF08 ellipsoid heights. The issues go back to at least version 2.4.3 and vary depending on the software version. The issue particular to 2.7 is that the vertical transformation does not occur. The data appears to move correctly in the horizontal but is not being transformed in the vertical. In addition, deleting or retaining the tildes in the transformation strings seems to have no effect (suggesting they are being ignored). As of version 2.8 this bug is still unresolved. [#BUG-000137632]. The bug was only verified for the NAD 1983 (2011)/NAVD88 (Geoid12B) --> ITRF08/ITRF08 case, not when going from EGM96-->NAVD88. I don't know whether the bug persists with different datum transformation combinations, but I would suggest a careful inspection of your output to verify the transformation occurred and the output elevations are what you expect. For anyone using earlier versions of Pro, a different bug exists in versions 2.4.3 - 2.6.3 [#BUG-000128301, originally submitted 1/31/2020 and never resolved as far as I know]. For the datum case above, going from NAD83(2011)/NAVD88(Geoid12B)-->ITRF08/ITRF08, if you accept the auto-populated, default geographic transformation method (~NAD_1983_2011_To_NAVD88_Alaska_GEOID12B_Height + ~ITRF_2008_To_NAD_1983_2011), your output will be moved horizontally in the wrong direction (the opposite direction it should move) unless you manually delete the tilde in front of the 2nd half of the transformation string (the horizontal portion). Manually deleting this tilde, using an ArcPro version from 2.4.3 - 2.6.3, is the only way I've found to perform a successful horizontal + vertical datum conversion for a raster with ESRI geoprocessing tools. If you do not delete the 2nd tilde, your output will be moved horizontally in the wrong direction if your input is a geotiff. If your input is a file geodatabase raster and you do not delete the 2nd tilde, the horizontal conversion looks correct, but heights are slightly lower than if you delete the tilde. Complicated, I know...

‎01-13-2021

In the properties of a file gdb raster, the NoData entry is blank, however, it is still there. From my understanding, described here, NoData in a file gdb raster is stored as a mask in the dataset rather than using a pixel value. I can display the file gdb raster and specify a color for the NoData value. The NoData cells show up correctly and in exactly the same location as the NoData cells in the .tif raster. I ran another test setting the cell size projection method = preserve resolution. The result is the same, the projected outputs (extents and cell values) are slightly different (page 3 in the attached). When comparing values on a cell-by-cell basis using the explore tool and clicking across the screen, the values are different throughout the raster. For example, for 2 coincident cells, one is 1.317897 and the other is 1.29102. For more background, the .tif raster was created from the file gdb raster using 'Export Raster'. So, the tif file is the same as the file gdb raster (extents, cell size, alignment, statistics, cell values are the same), just a different file format. ...Yet, projecting each one yields a different result. Could this be a bug? Thank you for your insights.

‎01-13-2021

Hi Dan, Thanks for the reference. I usually select 'Preserve Resolution', but in this case, where the same Snap Raster is being used for both Project Raster runs, as well as the same raster being specified to use for the Cell Size, wouldn't the Cell Size Projection method be irrelevant?

‎01-13-2021

Hello, I have 2 identical raster DEMs. The alignment, cell size, extent, and cell values are the same. This can be seen in the attached screenshot of the raster properties (page 1). I also verified this by comparing the pixels on screen. The only property not showing in the attachment is both rasters also have a vertical projection of NAVD88 defined. The only difference between the 2 rasters is that one is a .tif file and the other is a file geodatabase raster. Each raster is then projected (using Project Raster) to ITRF08 (horizontal) and ITRF08 (vertical) using the ~NAD_1983_2011_To_NAVD88_Alaska_GEOID12B_Height + ~ITRF_2008_To_NAD_1983_2011 geographic transformation method. [note: there is a documented ESRI bug (BUG-000128301) when doing vertical transformations on .tif rasters in ArcGIS Pro. The transformation is incorrect unless the tilde is removed from the 2nd half of the compound transformation string. When I projected the .tif, I removed the 2nd tilde. It is not necessary to remove the tilde in the case of file gdb rasters]. When projecting the 2 rasters all the settings in Project Raster are identical. For both runs a 3rd raster is specified in Project Raster as the snap raster and a cell size raster. Bilinear resampling is used in both. The .tif raster is output as a .tif raster. The file gdb raster is output as a file gdb raster. However, when comparing the outputs after projecting, the 2 rasters are slightly different. The pixels are aligned, but the extent and pixel values are different, as can be seen in the raster properties on the 2nd page of the attachment. The only difference between the 2 input files is the file format (.tif vs file gdb raster). The Project Raster settings were identical. Why are the 2 output rasters different?? This is creating confusion because subsequent analysis results differ depending on which DEM is used. I am using ArcGIS Pro 2.6.3.

‎10-26-2020

Yes, it can be opened and symbology changed. It is not the raster that is corrupt. The error has been happening on file sizes ranging from ~3Gb to 83 Gb. At the beginning of our workflow testing, the files (.tif format) would occasionally complete successfully using Project Raster, then we had the failures described above every time. We eventually had a successful Project Raster run when using a file geodatabase raster as the input and output file format on a 100.17 GB file. Processing time was 14 hours, 36 minutes on the 64 Gb RAM PC. Still don't know why the geotiff files would fail.

‎10-09-2020

We are trying to project large rasters (.tif), horizontally and vertically, using Project Raster. This has been run many times successfully, but now we are getting a 999999 error. The Project Raster has actually completed on an ~83 Gb tif (after many fails, the process completed once or twice), and on 53 and 23 Gb, and many times on 8 Gb tifs, but now the 999999 error occurs every time no matter the size. The error occurs within the first second with a message "Failed to open raster dataset, No such file or directory." But that is not the case! We were using ArcGIS Pro 2.6.1 on Windows 10 Desktop PCs. This is occurring on 3 separate PCs, having 24, 32, and 64 Gb RAM. The computers are in different physical locations and there are 2 different users running this using their own files on local machines. I have tried: updating to Pro 2.6.2, restarting the computer many times, starting with a fresh ArcGIS Pro project, making sure I have write permissions to all directories, clearing out the Default.gdb, home and scratch folders, cleaning out the user\AppData\local\temp folder, using short filenames with no spaces or odd characters and doesn't start with a number, using short pathnames, putting the input on a secondary internal hardrive and writing to an external drive, ran a different geoprocessing tool (hillshade) on one of the rasters to make sure the file wasn't corrupt, tried file gdb raster format, there is plenty of disk space. Any ideas? Anyone else have this problem?

‎09-17-2020

Thank you Mehdi, that worked! Is this a bug in the tool? If so, any plans to fix it? It sounds like it hasn't worked for a long time judging by the old post I found.

‎09-16-2020

We are trying to split a raster (DEM) into chunks based on boundaries in a polygon feature class (hydrologic units). We'd like the raster chunks to be larger than the polygon boundaries so that each chunk overlaps each other slightly. It sounds like the Overlap option in the Split Raster tool should so this. The screenshot below shows what we entered for the tool, specifying a 100 pixel overlap. However the rasters output from the tool follow the polygon boundaries and have no overlap with adjacent polygons. Either the tool is not working correctly or I'm not understanding how the Overlap function really works. I found an older post with this same question here, but it was not solved. I cannot find any more details about the Overlap option other than what is on the ESRI help page. We are using ArcGIS Pro 2.6.1. The Snap raster is set to the Input Raster. Both the raster and the polygon features are in the same coordinate system & datum. Is the Overlap option meant to produce essentially "buffered" output rasters? If so, what are we doing wrong? If not, what does the Overlap function do?

‎09-11-2020

I've refreshed the folders a million times. Tried again on both the C-drive folder and external drive. No luck.

‎09-11-2020

This time, when I selected file type = Files, the .asc showed up for the Copy Raster tool (I tried this before, why it works now who knows, probably operator error): However the .asc files still don't show up for Input Raster in the Contour List tool. It is so weird that it worked the first time I tried, now nothing. The file type in the pulldown by the red arrow only offers this one choice. The .asc files are visible in Catalog and Windows Explorer. Moving files to the C drive did not change anything.

‎09-10-2020

Thanks Dan, As described above, it's not the version. It first happened on 2.6.0, then I installed the update to 2.6.1, restarted the computer, and got the same result. The files are on a USB external hard drive attached to my PC, which is where all my data files reside. It is my normal storage device and that has never been an issue. All other files are found just fine.

‎09-10-2020

Hi Dan, Thank you for your suggestions. I had already tried all the possible selections under the file type dropdown to no avail. It doesn't matter what I select, the result is the same:

‎09-10-2020

This question is similar to the problem here. Today, using Pro 2.6.0, I used the Contour List tool to directly extract a contour line from an ESRI ASCII file (e.g., file1.asc). For Input Raster I was able to select file1.asc by browsing to the file. It ran successfully. I tried to run Contour List again, selecting file2.asc for the Input Raster, however, the file does not show up when browsing to it from the tool. I can browse to and see the .asc files in Catalog, but cannot load them into a map window (the solution that worked for people in the above link) and they no longer show up when browsing to them in the tool. Next, I tried to use Copy Raster to covert the .asc to a .tif first, then run Contour List. However the Copy Raster tool will not show .asc files either: The ArcGIS Pro Copy Raster help here does not show .asc as a file option, but numerous other pages and help discussions say that 'Copy Raster' is the way to convert from ASCII to Raster now that the 'ASCII to Raster' conversion tool has been retired. Next, I installed the Pro update to 2.6.1 and restarted the computer. Same result. How can I get Pro to recognize the .asc files so I can convert them to a tif? Or use them in the Contour List tool directly? Note, I did see here that says you cannot use ASCII files in the Contour List tool directly, but it did work the first time I tried it and i have the geoprocessing history and resulting vector contour to prove it! This is very perplexing! Extra info: The .asc files were created from .tif files (DEMs) in Pro using the Raster To ASCII tool, then run through another piece of software (VDATUM) that exports results to ESRI ASCII format. When I open the .asc files in a text editor I see nothing wrong with them, except unfortunately the Pro Raster To ASCII tool uses the X & Y LL corner coordinates and the VDATUM software exports using the X & Y LL center coordinates. Grrr. Is there a way to convert from raster to ASCII in Pro and specify using the LL pixel center coordinate instead of the corner? A separate question, I know....

‎01-03-2020

Great article! Thank you for providing this level of detail, exactly what I was looking for. My question is: are there any situations where CU is the better method to use? GCS-to-GCS? Makes me wonder why CU is still the default method for geoprocessing in the latest software releases - is ESRI just waiting for people to be better acquainted with the new options?

Online Status	Offline
Date Last Visited	3 weeks ago

My Ideas

Latest Contributions by FrancesBiles1

Re: Hi-Accuracy Storage of Coordinates with Web mercator basemaps and NAD83(2011) augmentation Not Possible

Re: Vertical datum conversion in ArcGIS Pro not recognizing vertical coordinate system

Re: Projecting identical .tif and file gdb rasters produce different results

Re: Projecting identical .tif and file gdb rasters produce different results

Projecting identical .tif and file gdb rasters produce different results

Re: Project Raster and 999999

Project Raster and 999999

Re: Split raster "overlap" option not working?

Split raster "overlap" option not working?

Re: Problems with ASCII to Raster in ArcGIS Pro 2.6.x

Re: Problems with ASCII to Raster in ArcGIS Pro 2.6.x

Re: Problems with ASCII to Raster in ArcGIS Pro 2.6.x

Re: Problems with ASCII to Raster in ArcGIS Pro 2.6.x

Problems with ASCII to Raster in ArcGIS Pro 2.6.x

Re: Introducing the new resolution preserving cell size projection method

Projecting identical .tif and file gdb rasters pro...

Re: Conversion of Trimble GPS Data to NAD83(1986) ...

Re: Error calculating raster percentiles by polygo...