Latest Contributions by KShak

‎03-28-2025

Found a cheater way to determine the paths to the tiles but still not perfect - in Catalog View, right click on the mosaic and select "Modify" then select "Repair Mosaic Dataset Paths" which will bring up a list of the tile paths. Normally this is used to repair the paths as named but this can also be used to just see where your tiles are located. Still looking for the option to see the properties of a mosaic in Catalog by viewing the list of tiles without opening a map to see the table. Hope this helps others looking at this thread.

‎03-20-2025

Tried updating a domain today in Pro 3.3.2 and yes, there is the option to sort alphabetically but I (and others in this thread) need my "unknown" and "not applicable" domain choices to be at the bottom of the list, not in the middle. It is customary for us to put the default domain at the top of the list and the unknown and NA at the bottom. Sorting alphabetical doesn't help this. This thread has been going for a long time and this suggestion seems simple and important. Yes, the table to domain tool will work but it would be MUCH EASIER to drag and drop or use a tool to reorder the domain table that already exists that is partially editable just not fully editable like we are suggesting. Thank you for considering Esri 😉

‎03-13-2025

How To: Copy a Field Value from Polygon Features to the Intersecting Point Features Using - this is a "solution" but it would be great to have a tool again in Pro!! Please bring this idea back!!

‎08-09-2024

👍this idea as well. I'll provide a use case in which I was hoping to be able to do this. Use Case: I had a request with a quick turn around for data to be added to contractor provided pdf maps. A co-worker georeferenced the pdf's in Pro, the data was added on top, and then the maps were exported back to pdfs for use in Avenza while in the field. While reviewing my co-workers pdf's, I tried dragging the pdf back into Pro to review them and that was a no go in v3.2. It was going to take too long to attempt to upgrade to 3.3 (and hope it worked in this version) so I tried to add them to a map in AGOL and that is when I found this thread, 🤓 😑. We ended up doing a screen share and using the co-workers pro project that still had the georeferenced pdfs and data as separate layers before output. THIS IS an ARCHAIC way to do that review. IMHO I wish that when I hovered over the thumbnail, it would recognize the georeferenced part of the pdf and ask me to add it to a map 😁 Thank you for considering this idea. ps -It would also enable the ability to bring in georeferenced CAD data as a base map.

‎03-11-2024

Since being forced into Pro I will be doing more searches to find solutions or ideas like this one (no solution/lost functionality) to comment on and provide my support. This is a simple ask! Come on! Thank you in advance for implementing this idea 😁

‎03-11-2024

Currently trying to figure out why a very large mosaic is acting up and cannot locate the source of each of the tiles being used in the mosaic as this post demonstrates the lack of a streamlined method in Pro to figure this out. IT recently removed ArcMap and now I'm realizing this very huge gap in my workflow needs. This is critical to figuring out mosaic issues related to source tiles and/or the possibility of incorrect source tiles. Please add this functionality back! An output table is not acceptable. 👉I would also like to see the raster mosaic footprint table within catalog and be able to figure out (by right clicking and opening properties of the tile) the location of each tile within the mosaic footprint via catalog just like in ArcCatalog. There is no need to open a map, add data, open the table of the mosaic footprint in the map to see this information. Not sure why Pro is missing this and why the users have to request it when it existed in previous versions of software. Yes, this is still important! A possible easy solution may be to add it to the Explore Rater Items ((View/Selection/Explore Raster Items/Raster Item Explorer) to show the source of the tile in the Inspect tab as shown below. Add the Source of each tile as a line item for the Raster Item Inspection similar to the mosaic source properties as shown below. Thank you in advance for implementing this idea 😁

‎07-06-2023

I agree with this. Bringing extra domains that are not needed into an existing geodatabase leads to bad data management. We have all seen it happen. It would also be nice to make it an option to remove domains in the feature class to feature class tool. I was trying to figure out a way to quickly disconnect one domain from many fields prior to using the feature class to feature class tool because I didn't want the domain attached to the input data to be output into my geodatabase. The Remove Domain from Field tool is burdensome to have to go to each field and remove it. I looked at what the batch of this tool does and it just allows multiple inputs. I was hoping it would allow multiple field inputs but that wasn't the case. If there was a tool that allowed for selecting a domain to remove from all fields in a feature class, that would be great! I then looked at the Domain Usage table and if there was a way in there to quickly disconnect a domain from all the fields at once to no avail. It would be another great location to have the option to disconnect the domain from all the fields or some of the fields listed.

‎02-02-2022

UPDATE: the raster group layer (lyr) issue in Pro was resolved with Pro version 2.9.1. Yay!

‎12-20-2021

We are using ArcMap (10.7.1) layer files (*.lyr) to serve a massive amount of symbolized data to our users that are connected to datasets on our server. The *.lyr files are forward compatible into Pro (most of the time). I've run into an interesting issue I thought I'd share and see if anyone else has experienced this and has a better work around. We have a raster mosaic containing elevation data where we have created an individual symbolized layer file for shaded relief, aspect, slope, elevation (meters) and elevation (feet). Each one of these layers references the same mosaic. Each of the symbolized layers are added to a single group and then saved as a single layer file as shown in the image below: When I bring this single Raster Mosaic Group layer file into Pro 2.6 or 2.8, the symbology in Pro takes on the very top layer in the group and applies that to all the layers below. In the example image above, all those layers in the group within Pro turned to symbolize in Shaded Relief. Another Pro example shown below using Aspect as the example: It seems as though the layer files (*.lyr) work just fine outside of the group if I save them out individually and then bring them into Pro. We are using Processing Templates in the mosaic which could be part of the issue? I've removed the default processing template but that didn't seem to matter. I would think since the individual layers work fine, it doesn't have to do with the mosaic itself, more the way Pro is handling the Group layer file in my opinion. We do have Pro users and this is very confusing on their end if they don't realize what they are seeing and expect to do any analysis. Thanks in advance for any ideas!! ps -switching to Pro lyrx files - We are still finding the need to be back compatible with ArcMap and since *.lyr files should work in Pro, we are keeping with the *.lyr file workflow until we are fully, across the region, moved to Pro. Thanks!

‎12-05-2019

Miaogeng Zhang As far as I can tell, using Classic Collector, M/Z data still cannot be utilized reliably. I'm assuming the comment that the Collector 17.0.3 release, having fixes for Z/M was referring to Classic Collector and not the Aurora version. Also, in doing research to see if this is still an issue, I found this article that doesn't even mention M/Z when preparing data for Classic Collector. I'm going to go with Classic Collector cannot use M/Z aware data to be safe.

‎10-18-2019

We discovered something similar in ArcGIS Pro yesterday. We have a Python script that tags feature classes with the word "Archive". I ran the script using Pro and next thing I knew there was a red exclamation next to the updated file geodatabase in Catalog View that said the database needed to be fixed. I couldn't even click into the geodatabase to see the feature classes. I then opened ArcCatalog and could see the changes in the geodatabase feature classes no problem to confirm the script worked. We shouldn't have to do these work-arounds to confirm success. At this point I'm confused on why Pro would throw an error after the script successfully ran. I now understand that Pro gets confused when using scripts etc. outside of Pro. Our python guru then looked into using arcpy.RefreshCatalog and discovered that Pro doesn't have this capability and it needs to be added to functions in Pro. My concern with Pro throwing that *false* red exclamation error is that others will take this serious and go down a rabbit hole, similar to my reaction and the discussion in this thread, and never recover. I don't feel that a user of the software should "know" that "oh, if you just refresh it should work". To me, this is not good enough when this capability exists in ArcMap. I think Pro should catch up and add arcpy.RefreshCatalog to functions in order to avoid confusion later with this refresh issue. We would be adding it to our script if we could to avoid the red exclamation scenario.

‎09-27-2019

I have seen this behavior in stand alone ArcMap in the past. Not sure what versions but I do recall that it might depend on how the person chooses to view the table fields by "code" or by "description" which can be switched using the table options by checking or unchecking: Appearance/Display Coded Value domain and subtype descriptions. I have seen where depending on how this is checked, the table will populate appropriately or at least this is what I've witnessed in ArcMap when the table shows code vs description for the same field. I know this is pre 10.7, could be as far back as 10.3 I saw this occurring. It may still be an issue. I'm not sure viewing by code vs description is a choice in Pro, I haven't researched or tried but am curious for someone to test it and report back.

‎05-21-2019

Kory Kramer‌ I have a coworker who is using ArcMap 10.7 while I am using ArcMap 10.6.1. "Save a Copy" was used on the 10.7 mxd to be compatible with 10.6 so I could open the mxd. The following is the error message I received when trying to open the compatible 10.6 mxd output from 10.7: We then tried saving it to a 10.5 mxd to see if 10.6.1 could open it and received this message: When I did some research and read the ArcGIS Enterprise 10.7 release highlights and updates by Victor Tey I found this page below that may or may not apply to this situation: Just throwing it out there that we're having trouble using the Save a Copy and getting it to work out of 10.7. Currently upgrading my computer to 10.7 to try and open the mxd. Thanks for reading!

‎04-25-2019

Thought I'd mention to Kory Kramer‌ and Thomas Colson in case you can help elevate this 😃 Its now 2019, and I'm working in Pro v2.3.2 and this is still an issue for this tool. I just created two separate file geodatabases on output because that is the only option I have for individual KML outputs. While using the KML to Layer tool, for the Output Location it only gives a folder option and then it only gives an Output Data Name option. There is an existing file geodatabase in my Output Location "folder" that was created the first time I used this tool but Pro doesn't see it because its only looking for a folder so I can't use the geodatabase to put the new feature class into. On output its going to create a new file geodatabase with the new Output Name feature class and that is not what I want, more clutter. It would be nice to be able to put the output into an existing geodatabase. I also think this issue may relate to another idea that was mentioned back in 2012 relating to being Consistent in Output Field and Location. Thank you, Kerry

‎04-25-2019

Thought I'd mention to Kory Kramer‌ and Thomas Colson in case you can help elevate this 😃 Its now 2019, and I'm working in Pro v2.3.2 and this is still an issue for this tool. I just created two separate file geodatabases on output because that is the only option I have for individual KML outputs. While using the KML to Layer tool, for the Output Location it only gives a folder option and then it only gives an Output Data Name option. There is an existing file geodatabase in my Output Location "folder" that was created the first time I used this tool but Pro doesn't see it because its only looking for a folder so I can't use the geodatabase to put the new feature class into. On output its going to create a new file geodatabase with the new Output Name feature class and that is not what I want, more clutter. It would be nice to be able to put the output into an existing geodatabase. I also think this issue may relate to another idea that was mentioned back in 2012 relating to being Consistent in Output Field and Location. Thank you, Kerry

My Ideas

Latest Contributions by KShak

Re: View Mosaic Data Item Paths in ArcGIS Pro

Re: Re-order a Domain

Re: How do I transfer attributes between features in Pro?

Re: Allow Import GeoPDF

Re: Auto hide attribute table in ArcGIS Pro

Re: View Mosaic Data Item Paths in ArcGIS Pro

Re: Export Table GP tool — Option to remove field domain

Re: Group layer (*.lyr) file issues when bring into Pro - buggy?

Group layer (*.lyr) file issues when bring into Pro - buggy?

Re: Using Z-enabled layer in Collector - Offline Sync Mode

Re: Pro doesn't update folders or files "in real time" within GDB when modified outside of Pro

Re: Domain Values in mixed ArcMap/ArcGIS Pro environment

Re: ArcGIS Desktop 10.7 compatibility

Re: Allow an output location to be specified in KML to layer tool.

Re: Allow an output location to be specified in KML to layer tool.

Group layer (*.lyr) file issues when bring into Pr...

Re: Using Z-enabled layer in Collector - Offline S...

Re: Pro doesn't update folders or files "in real t...

Re: AGOL Show/Hide Columns not sticking

AGOL Show/Hide Columns not sticking

Wildfire Response GIS