Latest Contributions by FrancesBiles1

This happened to me for the first time today. Got both "Failed to open map view" and "Failed to open table" (I had a table open with the map when the project was last saved). I deleted one of the 2 maps shown under Maps in the Catalog window - it pointed to a service and I thought that could be causing an issue. Saved the map. Now it opens without the errors, but the map window is still closed and if I try to open it I get the "Failed to open map view" pop-up.  If I select "Update data sources" from the map context menu, the full list of datasets I had in the map window is shown. I exported the list so I can rebuild the project later, but it was a large project - aargh!  Nearly all datasets that were in the map are on my local external hard drive or our office NAS drive. Data from these sources are behaving normally in another project I am working in. Three datasets are National Park Service service layers from sites that I checked are still live. Nothing is accessing One Drive. Aprx file was ~2.3 Mb. Running 3.5.6 Not using classify or doing any raster processing last time the project was open, which was late May. A field calculation was the last operation according to the history tab. None of the suggested fixes worked. The copy on my backup drive was also corrupt.   ... View more

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

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... ... View more

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. ... View more

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? ... View more

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. ... View more

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. ... View more

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

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. ... View more

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. ... View more

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: ... View more