POST
|
HOLY COW TI ! Your solution, although a roundabout one, worked pretty slick! I can't believe it's been so hard to find a SIMPLE solution.. Cheers.
... View more
03-22-2024
03:16 PM
|
0
|
0
|
800
|
POST
|
Why do we have to perform all this coding when simply importing a saved layer file (lyr or lyrx) should work programmatically? In other words, what's the point of having the "Apply Symbology From Layer" function when it's not doing what it's supposed to be doing?
... View more
03-22-2024
01:59 PM
|
0
|
0
|
2093
|
POST
|
It seems like a basic function but in my experience, it's not. There is one function that comes very close and it's a quick one-step solution. It's called "Raster Domain".. However, the Downsides: it requires 3D Analyst, and more importantly, the final polygon goes through the centroid of each cell at the data extent of the raster, so it's not an exact 'footprint' as it falls a half cell short on all sides of features represented. But if you want something quick and approximate, this would be the ideal solution. For something more exact, the simplest method would be to use Raster Calculator (which requires a Spatial or Image Analyst license). Set the "NoData" Environment variable to something other than Zero. If you have a floating point or non-discrete raster like a DEM, you will first need to convert your raster to integer. Second, multiply the raster by Zero, so you get a single value for the entire raster where there were valid values. Third, convert the Zero raster to a polygon. Now you have your extents based on features in a raster.
... View more
02-16-2024
01:27 PM
|
0
|
0
|
541
|
POST
|
I was wondering if this issue was ever resolved. I am getting the same problem. The original raster tiles can be displayed as unique integer values but when combined into a mosaic, the unique value option is no longer available even though the bit depth is the same as before (unsigned 8 bit). Is there a work around?
... View more
12-17-2023
07:43 AM
|
0
|
0
|
350
|
POST
|
Thanks Jon for the update. Looking forward to the fix. As a workaround, I keep adding the disable/enable combination for each network created, which seems to be doing the trick. I found a bigger issue regarding a performance hit in Pro of the DA Update Cursor when processing data in loops compared to ArcMap. I will have to report this in the appropriate forum when I have a chance as it was enough to halt my development and turn to other pressing matters in the interim.
... View more
01-20-2021
11:30 AM
|
0
|
0
|
2358
|
POST
|
UPDATE #3: Even stranger finding... I tried to remove the enable topology functions and it logically came up with an error that topology was not enabled when trying to set flow direction. So basically, I found after creating each network, I had to first disable and then enable topology before setting flow direction and performing a trace successfully. Very weird behaviour, but I seem to be getting results now, which are not exactly the same as I was getting in ArcMap but at least I can troubleshoot my trace results now. Below attached is a code snippet showing 1 of the 3 network/traces being performed and the weird logic that made it run successfully.
... View more
11-18-2020
06:58 AM
|
0
|
0
|
2429
|
POST
|
Thanks for fixing my problem. Unfortunately, with it resolved, I can no longer access this other 'new' account so I can't flag the issue as resolved... ;(
... View more
11-16-2020
06:42 AM
|
1
|
1
|
291
|
POST
|
UPDATE: I tried saving the results of the first trace to a dataset in a new file geodatabase, created a new network (wc_net) and still got the same 'table already exists' error when I try to enable the network. Nothing else exists in the geodatabase because I just created it. So I have no clue why it's doing this...
... View more
11-09-2020
01:55 PM
|
0
|
0
|
2440
|
POST
|
Thanks Jonathan, this sounds very promising and actually very similar to the way the older geometric network tracing functioned. For now, I am trying to utilize the AGGREGATED_GEOMETRY option by exploding the results of my first trace and using that in a second network. But when I try to enable it, I get a 'table already exists' error, which I suspect is related to the first network I created/enabled. Details are in a more recent post I made in this forum a few days ago. When I get a chance, I may try a test of creating the second network in a brand new geodatabase to see if that works any better?
... View more
11-03-2020
06:47 PM
|
0
|
0
|
1440
|
POST
|
Hello, I am trying to port over an 10.3.1 script which used the old geometric network functionality in Python scripting. I am running ArcGIS Pro 2.6.2. In my script, I am creating multiple trace networks to set up a cleaned watercourse network for further hydrology and DEM processing (burning and flow directions etc). It creates the first network (wc_clean_net) to find connected segments (isolated segments are dropped) and enables the network no problem. It also successfully creates a second network (wc_net) in the same dataset (called "Layers") using an upstream trace this time from a particular pour point at the edge of the study area. But when I try to enable the network, I get the following error: 160326: The table already exists. Traceback (most recent call last):
File "C:\_Workspace\Toolboxes\MNRF_TerrainToolsLocal\Pro\TerrainScripts\Step A.2. Prepare Water_new.py", line 756, in <module>
arcpy.EnableNetworkTopology_tn(wc_net, "", "ENABLE_TOPO")
File "c:\program files\arcgis\pro\Resources\arcpy\arcpy\tn.py", line 174, in EnableNetworkTopology
raise e
File "c:\program files\arcgis\pro\Resources\arcpy\arcpy\tn.py", line 171, in EnableNetworkTopology
retval = convertArcObjectToPythonObject(gp.EnableNetworkTopology_tn(*gp_fixargs((in_trace_network, max_number_of_errors, only_generate_errors), True)))
File "c:\program files\arcgis\pro\Resources\arcpy\arcpy\geoprocessing\_base.py", line 511, in <lambda>
return lambda *args: val(*gp_fixargs(args, True))
arcgisscripting.ExecuteError: ERROR 160326: The table already exists.
Failed to execute (EnableNetworkTopology).
Failed to execute (CreateGeometricNetwork). I can enable it manually by running the Toolbox command when I load the network into a map but I can't do it through python. Below is a sample of the script. First I try to clean up previous runs of the script deleting the networks before creating them again to help try isolating the problem. I am also checking for "TN_" tables (related to the trace network) that might not be cleaned up properly from previous bailed runs. As a last ditch effort, I tried copying all input feature classes and datasets to a new geodatabase to try running on a 'clean' geodatabase. No luck. Line 58 is where it bails. # Network clean-up from previous runs
arcpy.AddMessage("Checking for Networks from previous run...")
if arcpy.Exists(wc_clean_net):
arcpy.AddMessage(" >> Deleting 'wc_clean_net'...")
arcpy.Delete_management(wc_clean_net)
if arcpy.Exists(wc_net):
arcpy.AddMessage(" >> Deleting 'wc_net'...")
arcpy.Delete_management(wc_net)
arcpy.Delete_management(WC_Clean)
if arcpy.Exists(wc_select_net):
arcpy.AddMessage(" >> Deleting 'wc_select_net'...")
arcpy.Delete_management(wc_select_net)
arcpy.Delete_management(WC_Select)
#arcpy.env.workspace = Output_Vector_GDB_Workspace
arcpy.AddMessage("Workspace = " + arcpy.env.workspace)
CurrentLayer = "TN_*"
arcpy.AddMessage("Checking for '" + CurrentLayer + "' orphan Network Tables...")
GDB_Tables = arcpy.ListTables(CurrentLayer, "All")
tbl_ctr = 0
for tbl in GDB_Tables:
tbl_ctr += 1
arcpy.Delete_management(tbl)
arcpy.AddMessage(" >> " + str(tbl_ctr) + " '" + CurrentLayer + "' tables deleted.")
arcpy.AddMessage("Performing Connected Trace to create WC Clean layer...")
WC_Name = os.path.basename(WC_Dissolve2)
arcpy.AddMessage(" >> Dissolved WC Name = '" + WC_Name + "'")
arcpy.AddMessage(" >> Creating Trace Network...")
arcpy.CreateTraceNetwork_tn(Layers, "wc_clean_net", "", [[WC_Name, "SIMPLE_EDGE"]])
arcpy.AddMessage(" >> Enabling Network...")
arcpy.EnableNetworkTopology_tn(wc_clean_net, "", "ENABLE_TOPO")
arcpy.AddMessage(" >> Snapping buffer and pour points to network...")
arcpy.Snap_edit(wc_bf_and_pour_pts, [[WC_Dissolve2, "EDGE", "0.1 Meters"]])
arcpy.AddMessage(" >> Tracing network...")
# Process: Trace Geometric Network
##arcpy.TraceGeometricNetwork_management(wc_clean_net, WC_Selection3, wc_bf_and_pour_pts, "FIND_CONNECTED", "", "", "", "", "", "NO_TRACE_ENDS", "", "", "", "AS_IS", "", "", "", "AS_IS")
arcpy.Trace_tn(wc_clean_net, "CONNECTED", wc_bf_and_pour_pts, "", "", "", "", "", "", "", "", "", "EDGES_ONLY", "", "", "AGGREGATED_GEOMETRY", "NEW_SELECTION", "", "Connected_Network_1", "", wc_traceout)
arcpy.MultipartToSinglepart_management(wc_traceout, WC_Clean)
wc_clean_lyr = "wc_clean_lyr"
arcpy.MakeFeatureLayer_management(WC_Clean, wc_clean_lyr)
arcpy.AddMessage(" >> Retrieving connected network results...")
arcpy.AddMessage(" >> Layer name is: {0}. Count is: {1}.".format(os.path.basename(WC_Clean), str(arcpy.GetCount_management(wc_clean_lyr))))
arcpy.AddMessage("Performing Upstream Trace to create initial WC Select layer...")
try:
WC_Name = os.path.basename(WC_Clean)
arcpy.AddMessage(" >> Cleaned WC Name = '" + WC_Name + "'")
arcpy.AddMessage(" >> Creating Trace Network...")
arcpy.CreateTraceNetwork_tn(Layers, "wc_net", "", [[WC_Name, "SIMPLE_EDGE"]])
except:
arcpy.AddMessage(" >> Network exists... bypassing creation")
arcpy.AddMessage(" >> Enabling Network...")
arcpy.EnableNetworkTopology_tn(wc_net, "", "ENABLE_TOPO")
arcpy.AddMessage(" >> Snapping pour points to network...")
arcpy.Snap_edit(Flags_or_Sources_for_Tracing, [[WC_Clean, "EDGE", "0.1 Meters"]])
arcpy.AddMessage(" >> Tracing network...")
arcpy.Trace_tn(wc_net, "UPSTREAM", Flags_or_Sources_for_Tracing, Barriers_for_Tracing, "", "", "", "", "", "", "", "", "EDGES_ONLY", "", "", "AGGREGATED_GEOMETRY", "NEW_SELECTION", "", "Upstream_Network_2", "", wc_traceout2)
if Barriers_for_Tracing != "":
arcpy.MultipartToSinglepart_management(wc_traceout2, Output_Vector_GDB_Workspace + "\\" + wc_inside)
wc_inside_lyr = "wc_inside_lyr"
arcpy.MakeFeatureLayer_management(Output_Vector_GDB_Workspace + "\\" + wc_inside, wc_inside_lyr)
arcpy.AddMessage(" >> Retrieving upstream 'inside' network results...")
arcpy.AddMessage(" >> Layer name is: {0}. Count is: {1}.".format(wc_inside, str(arcpy.GetCount_management(wc_inside_lyr))))
else:
arcpy.MultipartToSinglepart_management(wc_traceout2, WC_Select)
wc_select_lyr = "wc_select_lyr"
arcpy.MakeFeatureLayer_management(WC_Select, wc_select_lyr)
arcpy.AddMessage(" >> Retrieving upstream 'select' network results...")
arcpy.AddMessage(" >> Layer name is: {0}. Count is: {1}.".format(os.path.basename(WC_Select), str(arcpy.GetCount_management(wc_select_lyr))))
All I can think of is that the Enable function is trying to use the same system table name for the second network that was created for the first network. Am I missing something or is this a bug? Thanks, John
... View more
10-30-2020
08:11 AM
|
0
|
5
|
2478
|
POST
|
Similar to Ben Coakley's issue about "Function Outputs", there is practically no documentation that I can find about how to utilize the results of a trace (SELECTION option) using arcpy scripting. Basically, I want to save the selection to a layer so I can do further tracing or analysis on the derived selection. There should be an option similar to AGGREGATED_GEOMETRY which saves NON-AGGREGATED results. I don't see a rationale for aggregating geometry anyway as it produces just a single mult-part feature which seems useless to work with. Will exploding the aggregated geometry always maintain flow direction of the individual features? Even so, if there were important attributes on the original network, they would now be lost in the aggregated dissolve, which means you can't do any attribute queries or further selections on the aggregated output. By comparison, the old TraceGeometricNetwork function allowed you to work with the Group Layer output and save the results to a separate feature class with the attributes intact. I would like to see this functionality in the new Trace function (or at least the ability to save the selection with original geometry and attributes as optional output).
... View more
10-27-2020
03:00 PM
|
0
|
5
|
1479
|
POST
|
I would argue the printed image is not correct. I would say it's more related to the rendering capability of Pro/ArcMap when trying to handle projections and maybe scale. Logic might dictate that images would appear at their best in their native projection, but oddly that's not the case. Using the ESRI World Imagery in its native WGS 84 Web Mercator projection, the image appears blurry exactly like Theodore's example above. The blurry phenomenon happens at various scales. For example, it's blurry at 1:8000 (and coarser scales) and seems best when viewed at 1:6000. However, when I change the map projection to NAD 83 CSRS UTM Zone 17N, it appears clear within a larger range of scales (between 1:3000 and 1:10000). Note I was able to replicate this in traditional ArcMap Desktop 10.3.1 (I know.. ancient!) as well. So this rendering issue does not seem to be platform specific. Perhaps it could be the graphics card?? My specs are the following although I personally think it's still a pretty good card: https://www.nvidia.com/content/dam/en-zz/Solutions/design-visualization/documents/75509_DS_NV_Quadro_K620_US_NV_HR.pdf
... View more
06-25-2020
06:21 PM
|
1
|
2
|
8828
|
POST
|
Sorry Jacob.. I may have not responded directly to you.. see below or my comment earlier today on this thread.
... View more
07-18-2019
11:38 AM
|
1
|
0
|
2139
|
POST
|
Here you go: https://community.esri.com/thread/105831-arc-hydro-installation-versions-and-documentation Yes you're right.. they are responsive when it comes to infrastructure, cartographic and online type applications. Their user base is large and some 'niche' users are left struggling, but we'll have to adapt one way or another eventually. Cheers, John
... View more
07-18-2019
08:49 AM
|
1
|
0
|
2139
|
POST
|
Hi Jacob. There are several reasons why we decided not to take the jump to Pro.. this being one of them. But I imagine the Arc Hydro team is getting close to a viable update (I would keep track of their main thread for this). They're not totally to blame though. As an 'old school' programmer, I've always exercised the concept of 'backwards compatibility' when versioning software or you run the risk of upsetting or alienating your user base (and I sort of see the Arc Hydro team as part of this 'user base' even though they are affiliated with ESRI). In Pro, the decision not to support traditional simple geometric networks (forcing folks towards the more complex Utility Network model instead) and dropping the ability to view read only fields on toolbox forms are a couple things that have really irked me personally. I've raised these issues as well, but they are not seen as priority which is unfortunate. But the main reason is we've built a lot of Python tools for specialized auto processing of large datasets and producing informed status updates/error reporting which Arc Hydro alone lacks.. so for us to needlessly rework the entire workflow (which works perfectly fine otherwise) just makes it not worth our while to port over to Pro. For the foreseeable future, we're sticking with ArcGIS Desktop for surface water related processes, and may also explore open source alternatives (Whitebox is a promising contender for handling LiDAR big data in surface water applications).
... View more
07-17-2019
01:06 PM
|
1
|
2
|
2139
|
Title | Kudos | Posted |
---|---|---|
1 | 06-25-2020 06:21 PM | |
1 | 11-16-2020 06:42 AM | |
2 | 11-09-2017 12:19 PM | |
1 | 07-17-2019 01:06 PM | |
1 | 07-18-2019 08:49 AM |
Online Status |
Offline
|
Date Last Visited |
03-23-2024
04:39 AM
|