Latest Contributions by VinceE

‎07-07-2020

Thanks taking a look Dan, but it performs this way for me as well--see below. The issue is on the export. I am getting errors on the last line where I'm attempting to use CopyFeatures. The goal is to extract the selection to a new feature class. Trying to perform the selection followed by the export is giving me issues. Specifically (with CopyFeatures), I am getting "SHEETS_Layer23 does not exist or is not supported." Since it clearly exists, my guess is that I am not referring to it in a format that CopyFeatures can understand. As it is, I suppose I'm passing in a Result object, but I'm not sure how to get a Feature Layer object from the Result to pass to CopyFeatures. Please excuse the formatting, it's not clear to me how to get the code block up on a "Reply." ---------- import arcpy arcpy.env.workspace = r"C:\FULLPATH\TEST.gdb" sheets = "SHEETS" parcels = "PARCELS" with arcpy.EnvManager(overwriteOutput=True, addOutputsToMap=False😞 tmp = arcpy.management.SelectLayerByLocation(sheets, "INTERSECT", parcels) #arcpy.management.CopyFeatures(tmp, "Output") print(f"{*tmp,}") ('SHEETS_Layer23', 'SHEETS_Layer23', '37')

‎07-07-2020

I am attempting to perform a SelectByLocation on a feature class and export that selection. I am running this code directly in the Python Window in ArcGIS Pro. Eventually this operation will be ported over to a larger script that will become a tool in a toolbox. If I use EnvManager as shown below to set "addOutputsToMap=True", the below works fine. When set to False, it does not. import arcpy arcpy.env.workspace = r"C:\FULLPATH\TEST.gdb" sheets = "Sheets" parcels = "Parcels" with arcpy.EnvManager(addOutputsToMap=True): sheet_lyr = arcpy.management.SelectLayerByLocation(sheets, "INTERSECT", parcels) arcpy.management.CopyFeatures(sheet_lyr, "Sheet_Intersect")‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ I have tried all sorts of combinations using MakeFeatureLayer(), using r"memory\XXX" as a workspace, using getOutput() from the Result, etc., and cannot figure out any combination that avoids adding the unnecessary intermediate layer "sheet_lyr" to the map. There seems to be several different methods that all work when adding the "sheet_lyr" to the map, but none when "addOutputsToMap=False". Is there no way to perform a SelectByLocation and export the result entirely within memory workspace, without adding a layers to a map? Or is it just not possible to do directly in the Python Window?

‎07-05-2020

If this is just a bug, that's fine, I'll obviously have to figure out a workaround. I'm still trying to figure out if that is in fact the case, or if I'm improperly using these functions. Thanks for the link.

‎07-05-2020

I still haven't been able to figure this out. All of the above solutions seem to hinge on the output feature class being defined as a tool parameter, which is not applicable in my case. The UI takes inputs and an output location--the name of the output is generated within the script, not provided by the user. The below is the same as my first post (I believe), just cleaned up a bit. current_project = arcpy.mp.ArcGISProject("CURRENT") map = current_project.listMaps()[0] cont_file = r"FULLPATH\Contours_2" cont_layer = map.addDataFromPath(cont_file) cont_symbol = r"FULLPATH\Index_Contour_Symbology.lyrx" arcpy.management.ApplySymbologyFromLayer(cont_layer, cont_symbol) The above is the final function in my python script. It adds the layer, but it does not apply the symbology. When the exact same block is run from the python window, it works as expected--it adds the existing feature class as a layer, and applies the symbology from the predefined .lyrx file. For clarity, FULLPATH in the snippet above is replaced with the actual path in the code. It's not clear to me why this is considered "GP output symbolization" and not "mapping workflow automation." If this is not an applicable use case, then when would someone opt to use ApplySymbologyFromLayer?

‎05-20-2020

EnvManager is definitely helpful for temporarily changing the workspace (when it works!), disabling Z or M values, changing raster cell size, etc. Glad you'll find that useful. Hopefully we'll hear something from Esri, curious to see what could be happening here.

‎05-20-2020

Thanks Joe. I usually do that as well (f"{outWS}\output") and completely skip the env.workspace setting because it isn't reliable. It would just be cleaner to use the workspace if possible. I've used the workspace setting successfully in other scripts, but it seems to have issues with spatial analyst, maybe other scenarios, but I can't diagnose what causes it. Also, RasterToPolygon isn't an SA tool, so that might invalidate my theory that spatial analyst is to blame. The documentation says "Tools that honor the Current Workspace environment setting use the workspace specified as the default location for geoprocessing tool inputs and outputs." Both Contour and RasterToPolygon are supposed to respect Current Workspace. All I'm doing with EnvManager is restating the same workspace that I initialized at the top, so it's not clear to me why that works.

‎05-20-2020

I'm having issues using arcpy and spatial analyst functions. The workspace environment seems to get selectively ignored. I am running this code directly in the Python window in ArcGIS Pro 2.5.1. The behavior appears the same in an existing project versus a brand new unsaved project. import arcpy as ap from arcpy import env from arcpy.sa import * testing = True env.workspace = r"C:\Users\Desktop\Prop\Prop_Slope.gdb" dem = r"F:\5_Tools\SlopeClass\AARM.gdb\DEM_AOI" demfs1 = FocalStatistics(dem, "Circle 5 CELL", "MEAN") demfs2 = FocalStatistics(demfs1, "Circle 5 CELL", "MEAN") demfs3 = FocalStatistics(demfs2, "Circle 5 CELL", "MEAN") #with arcpy.EnvManager(workspace = env.workspace): Contour(demfs3, "Contour", 10, 0, 1) remap = "0 19.999 1;20 49.999 2;50 10000 3" rclass = Reclassify(demfs3, "VALUE", remap, "NODATA") #with arcpy.EnvManager(workspace = env.workspace): ap.conversion.RasterToPolygon(rclass, "Reclass_Polygon", "SIMPLIFY", "VALUE", "SINGLE_OUTER_PART") if testing: demfs1.save("FS1") demfs2.save("FS2") demfs3.save("FS3") rclass.save("Reclassified") del demfs1, demfs2, demfs3, rclass‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The code itself executes without a hitch, however the outputs get saved in different locations. Calling the .save() method on the returned raster objects will create permanent saves in the location specified in "env.workspace". However, both the outputs of "Contour" and "RasterToPolygon", get saved to the Default geodatabase for the project (either a named default, or just the "Default.gdb" in an unsaved project). Using the currently commented-out "EnvManager" and "with" blocks corrects this problem. Why does it appear necessary to explicitly define the workspace for these tools, when I have already done it globally at the top? What aspect of the workspace environment am I missing? Perhaps the use of spatial analyst tools here is coincidental, but it's when using these tools that I tend to experience strange behavior with the workspace environment. Any help would be greatly appreciated.

‎05-11-2020

To follow up though, it appears setting a subtype field via arcpy (SetSubtypeField) removes the contingent values. Does that sound like expected behavior? The CVs also seem to get removed if the subtype setup is done through the UI, where the specific subtype field, the codes and descriptions, and the default subtype can all be set at once. Rather than automatically populating the CVs across each of the newly defined subtypes, they just get removed. This seems contrary to what happens with both domains and default values, which will get populated across newly defined subtypes if they had previously applied.

‎05-11-2020

Hey Kory thanks for taking a look at this. The issue I described was not a result of using the Create Field Group tool, but the UI method you provided above. Only reason I'm sure of that is that I was just following along in the book, and that is how it is done there. I just tried the Create Field Group tool from within the UI and am experiencing this bug though. I was able to build the geodatabase, set the domains, and populate the CVs successfully all via arcpy (which does use some form of the Create Field Group tool I suppose). If I then go and delete the Field Group (manually, or with the GP tool), re-add the Field Group (manually), I can then go in an add the CVs back in (manually again). Since I haven't rebuilt the whole geodatabase and domains by hand to get to this point (just using the existing GDB I created with the script), I'm not totally recreating the situation. Could certainly have been some user error along the way in the manual building that I just happened to get right when I did the whole thing using arcpy. Looks like problem solved, aside from the GP tool, but seems like the workarounds are just fine. Thanks again for the help.

‎05-07-2020

This is a similar issue another user posted (with nearly the same title), however this is occurring in Pro v2.5.1, and my experience with the "Save" button is slightly different. Original post about a similar issue: Unable to Save Contingent Values in ArcGIS Pro 2.3.0 To address some issues that came up in that thread: I have an Advanced License, there are no subtypes involved here (should there be?), and I am not currently editing anything (same experience in a fully loaded map vs. a new, unsaved project). My issue is that I am able to add new contingent value "pairs" using the drop downs in the Contingent Values window, and can then hit the save button, however upon "saving," they are just removed and I am left with a blank list again. I am not getting any error messages or warnings, and the colored indicator square in the table is green. The general setup: I have two fields in the field group (both TEXT type) from the same feature class. Each of the two fields has a unique domain, both of which use Coded Values. Both of the fields do not allow NULL values. While creating new features, I can successfully set the values for both fields, from their respective domains, and then proceed to create the feature. I have tried setting up the geodatabase, feature class, fields, domains, and the grouped fields for the contingent values using arcpy, and also doing the whole thing manually in the GUI, both to no avail. Everything else up to this step appears to work just fine. I have not tried adding the specific contingent value pairs using arcpy, but my feeling is that I'm doing something incorrectly before the adding values part, so I'd like to figure that out first. Not entirely sure I understand the setup for the CSVs to be used in the arcpy/geoprocessing tool either. As a side note, if anyone has a link to examples of what these look like, that would be helpful. I can't quite decipher how these are set up from the help docs. First image shows the CVs added, second image shows them disappear immediately after save. This is coming straight out of "Focus on Geodatabases in ArcGIS Pro" (2019) if the field group, fields, or individual CVs look familiar. Thanks in advance if anyone has ideas. UPDATE: Adding via arcpy does seem to work. Interestingly, once one has been added, doing it manually via the GUI seems to allow saving as well. This probably solves my issue, but I'd be curious if others have the same problem.

‎04-07-2020

Drew, Thanks for the helpful response, it appears I was approaching the problem from the wrong direction. Your last line in particular about the intended purpose of arcpy mp clears things up for me. Sounds like one of that above options will do exactly what I need.

‎04-06-2020

Scott, Yes, I think that's it. Thanks for pointing that out, I missed that request. I appreciate the info.

‎04-05-2020

Thanks Dan, this is very helpful. I assumed something like this was happening, but couldn't quite get there. The disconnect between the rotation of the actual map object versus the map frame/layout object, and how the XY axis is re-oriented, is starting to make sense. That being said, I'm not entirely sure how to bridge that disconnect--i.e. communicate to the mapframe object/layout that the reference frame in the actual map object has changed orientation. As a workaround, I have done the following in the script: For this particular use case, since I just need the coordinates of the map corners as visible in a map frame on a layout: mapframe = active_object.listElements("MAPFRAME_ELEMENT")[0] # active_object derived from aprx.activeView heading = mapframe.camera.heading # Read original rotation of map frame mapframe.camera.heading = 0 # Change rotation property of map frame's camera to 0 extent = mapframe.camera.getExtent() # Get extent of the camera for the now un-rotated map mapframe.camera.heading = heading # Set the rotation of the map back to original rotation This gives me an extent from an un-rotated map, from which I can derive coordinate values, that will match the actual shape of the map view within the layout's map frame. Then, I can use the preserved rotation value in the trig functions that are required to actually rotate the corner points so that my new polygon aligns to the rotated map. This is perhaps a clunky workaround, so suggestions welcome, but it appears to do what I need.

‎04-05-2020

Thanks Dan, are you able to expand on this? My goal is to get the coordinates of the "view" while in a Layout so I can eventually generate a polygon that matches up exactly; perhaps I'm using the term "Extent" in a technically incorrect way here. What do you mean "extents that are appropriate to the layout?" I'm sure getExtent() is doing what it is supposed to, I'm just not sure why I'm seeing different behavior when it is called on a rotated MapView vs. a rotated MapFrame. It's not clear to me why the size of the extent is larger when a MapFrame's Map is rotated, but not when a MapView's Map is rotated. I've looked through the documentation, and still not following some aspect of this, so I my be confusing some terminology, etc. I'd appreciate any further guidance you can offer.

‎04-05-2020

My goal is to create a python script that generates a current view polygon in ArcGIS Pro (2.5). I am testing the code below by just running it in the Python Window. I'd like this to function much like all the "data frame to polygon" tools for ArcGIS Desktop. When looking at a "Map" tab, I use the following code to get the extent of the view (not a specific layer, the whole view of the frame): current_project = arcpy.mp.ArcGISProject("CURRENT") active_object = current_project.activeView extent = active_object.camera.getExtent() print(extent)‍‍‍‍ As I understand it, activeView returns a MapView object, and camera.getExtent() gets an Extent. The printed extent results are the same for a map with a rotation of 0 and a rotation 45. This is what I want, as I'd like the output polygons to be the same size (if the map is at the same scale) regardless of rotation, and then I just rotate the final output polygon if I need to using the value from camera.heading. The end result of the larger script, ran once at "0 rotation" and once at "45 rotation," are two equal-sized polygons, just rotated accordingly. Map at 0 rotation, Extent: (675,978 728,153) (676,606 728,496) Map at 45 rotation, Extent: (675,978 728,153) (676,606 728,496) However, this does not seem to work with a MapFrame from a Layout. When looking at a "Layout" tab, here is the code: current_project = arcpy.mp.ArcGISProject("CURRENT") active_object = current_project.activeView map = active_object.listElements("MAPFRAME_ELEMENT")[0] extent = map.camera.getExtent() print(extent)‍‍‍‍‍ In this case, there is the extra step of getting the MapFrame from the Layout, as activeView returns a Layout object. I can't tell if if is possible to get a MapView from a Layout. When printed, the results of a map at 0 and 45 rotation are as follows (doesn't matter that they are different from above, the area may have been different, I only care that they are different from one another): Map at 0 rotation, Extent: (676,162 728,233) (676,437 728,379) Map at 45 rotation, Extent: (676,151 728,157) (676,448 728,455) Since the initial size of the "Extents" are different, I get different sized polygons for the rotated and non-rotated versions. The images attached show what all this looks like in the first (map tab) and second (layout tab) cases. getExtent() appears to do different things if it is called on a MapView versus a MapFrame. For a MapView, rotation does not appear to impact the extent; in a MapFrame, rotation does appear to impact the extent. Is there a better approach to getting the visible extent boundaries while looking at a layout? Or is there a method of obtaining a MapView from a MapFrame or Layout object when I'm working in a Layout tab so I avoid this issue?

Online Status	Offline
Date Last Visited	Wednesday

My Ideas

Latest Contributions by VinceE

Re: How to SelectByLocation, in memory, without adding to current map?

How to SelectByLocation, in memory, without adding to current map?

Re: Cannot Apply Symbology From Layer Using Python Script

Re: Cannot Apply Symbology From Layer Using Python Script

Re: Workspace Environment Issue for ArcPy Spatial Analyst

Re: Workspace Environment Issue for ArcPy Spatial Analyst

Workspace Environment Issue for ArcPy Spatial Analyst

Re: Unable to save contingent values in ArcGIS Pro 2.5.1

Re: Unable to save contingent values in ArcGIS Pro 2.5.1

Unable to save contingent values in ArcGIS Pro 2.5.1

Re: Cannot Apply Symbology From Layer Using Python Script

Re: Possible to move multiple annotation labels in ArcGIS Pro?

Re: ArcPy getExtent() on rotated Map are different for MapView versus MapFrame?

Re: ArcPy getExtent() on rotated Map are different for MapView versus MapFrame?

ArcPy getExtent() on rotated Map are different for MapView versus MapFrame?

How to SelectByLocation, in memory, without adding...

Re: Deleting a feature using arcade - help with co...

Re: Calculation Attribute Rule Fails with Domains

Re: How to select 3 points per polygon grid featur...

Re: Cannot See All Fields in Field Maps