Latest Contributions by Robert_LeClair

So there are two bugs that kind of match what you're seeing: BUG-000182323: “The attribute table refreshes after each edit for branch versioned feature services when updating values in the attribute table in ArcGIS Pro.” (Version found: 3.6; Status: In Review) and  BUG-000173120: “The attribute table scrolls vertically and horizontally after saving edits to a branched version service in ArcGIS Pro.” About “Disable auto refresh” in newer Pro versions.  In Pro 3.x, disabling table auto-refresh is handled via the administrative setting DisableAutoRefresh (not the older 2.9-only registry behavior you tried). See: Table settings—ArcGIS Pro (context) Settings that affect data access performance—ArcGIS Pro However, based on BUG-000182323, even with table auto-refresh disabled, the branch-versioned feature-service edit pattern can still trigger refresh/requery behavior at the table level. ... View more

Those long, straight “cuts” are almost always coming from the DEM/flow-direction surface and raster alignment, not from Watershed itself. In an urban DEM with D8 flow routing, small artifacts (flats, embankments, resampling seams) can produce very straight drainage divides. Here are some steps you can try (in order): 1) Verify raster alignment environments for every tool In Geoprocessing Environments for Fill, Flow Direction, Flow Accumulation, Snap Pour Point, and Watershed, set consistently: Snap Raster = your DEM Cell Size = Same as DEM Processing Extent = Same for all steps (often “Same as DEM”) (Optional) Mask = your city boundary (to prevent edge effects) Misalignment/resampling between steps is a common reason for straight-line artifacts. 2) Diagnose whether the lines are in Flow Direction (they usually are) Symbolize/inspect the Flow Direction raster. If you see directional “seams” or large uniform patches, the watershed boundaries will reflect them. Background: Watershed delineation is based on Flow Direction + pour points: How Watershed works—ArcGIS Pro 3) Tune Snap Pour Point (distance matters a lot) Snap Pour Point moves your catch basins to the highest flow accumulation cell within the snap distance; too small = not snapping onto a real drainage path, too large = snapping across a divide into a different drainage path. Confirm snapped points land on the intended “drainage lines” in the Flow Accumulation raster. Reference: Watershed tool, Snap Pour Point function 4) Consider DEM conditioning for urban barriers/flats Road crowns/berms, bridges/culverts, and lidar artifacts create unrealistic divides (often straight). Fill helps with sinks, but it won’t solve barriers/culverts. Esri’s hydrology workflow starts with Fill to address sinks: Hydrologic analysis sample applications 5) Check DEM resolution and vertical quality If your DEM is coarse relative to curb-to-curb drainage, D8 routing can create grid-aligned divides that look like straight lines. ... View more

This behavior is most often due to Create Hosted Imagery Layer wizard limitations/bugs rather than your Weighted Raster Overlay output. 1) Confirm your mosaic dataset’s source rasters are supported by the wizard ArcGIS Pro documentation lists a key limitation: mosaic datasets whose source rasters are in a file geodatabase or enterprise geodatabase are not supported by the Create Hosted Imagery wizard. If your mosaic references rasters inside a .gdb, the wizard can fail during the remote tasks (for example, CreateImageCollection / CopyRaster). Source: Publish hosted imagery layers (ArcGIS Pro 3.7 docs) – Limitations 2) Known issue with the Pro wizard failing to upload/publish There is a reported bug where the Create Hosted Imagery Layer wizard fails to upload data for tiled or dynamic imagery layers; the documented workaround is to publish from ArcGIS Online instead. Source: BUG-000159411 3) If your failure references CopyRaster / ERROR 999999, check Parallel Processing Factor Copy Raster can throw ERROR 999999 when Parallel Processing Factor is set to more than 1. In ArcGIS Pro, open the tool’s Environments and clear/set Parallel Processing Factor to 1 (or blank). Source: Problem: The Copy Raster tool fails with ERROR 999999 in ArcGIS Pro Recommended workaround (given your constraints: AGOL, no Enterprise) Publish the output as a hosted imagery layer directly in ArcGIS Online (Content → New item → Imagery layer), rather than using the Pro wizard (this is also the workaround referenced in the bug above). ... View more

@redchelle123 - this is the ArcGIS Pro Questions forum.  You will likely have better feedback if you move this to the ArcGIS Experience Builder Questions - Esri Community community instead. ... View more

The Export Features (Conversion Tools) | ArcGIS Pro documentation tool may be what you're looking for.  It has a filter parameter to select a subset of records and a fields parameter where you can add, delete, rename and reorder fields as well as other field properties. ... View more

This “everything greys out” behavior usually means ArcGIS Pro is blocked on a background operation (often Catalog browsing / geodatabase I/O), and network/NAS paths can trigger long waits. Here are some focused things to try that commonly resolve this when clicking/expanding geodatabases: 1) Make sure you’re using UNC paths (not mapped drives) If your NAS is mapped (for example Z:\), remove those connections and re-add using the actual UNC path (for example \\NASName\Share\Folder) via Add Folder Connection. Esri has documented problems with mapped paths for geodatabase operations. Unable to create a file geodatabase using a mapped drive in ArcGIS Pro 2) Avoid connecting to huge folder roots (Catalog browsing/indexing overhead) If your folder connection points at a very broad location (root of a share, or top-level that contains lots of data), replace it with a connection to a narrower subfolder that only contains the specific project data. Esri notes indexing/search considerations and that network locations behave differently. Connect to a folder (Indexing considerations) 3) Check for file geodatabase locks / stuck ArcGIS processes If a .gdb is locked (including by a hidden/hung process), Catalog expansion can stall. While Pro is greyed out, open Task Manager and look for lingering ArcGIS/GP/background processes; end any that are clearly stuck, then retry. File geodatabases and locking—ArcGIS Pro 4) If it happens even with local data, consider a Pro “soft reset” (last resort) There’s a known remediation for freezes when working with connections that involves resetting the Pro user profile/registry and confirming Pro is not set to work offline (ARCPROWORKOFFLINE = FALSE). Problem: ArcGIS Pro freezes when adding a database connection 5) Capture what Pro is hanging on (useful for Support) Esri describes collecting evidence for “APPLICATION UI IS GREYED OUT” hangs using performance troubleshooting/logging so the specific operation can be identified. Troubleshooting Performance Issues in ArcGIS Pro ... View more

You're welcome Michele - ArcGIS Pro 3.7 is already out/public - the team is working on 3.8 now. ... View more

You can model this in ArcGIS Pro with Raster Calculator using a Con (conditional) that only modifies the “bad” cells (where Lower > Upper) and uses Focal Statistics (Mean) to estimate the local typical separation outside/around the error. Try these steps using the Raster Calculator: Compute the separation (gap) raster: gap = upper - lower Get a local mean gap (choose a neighborhood large enough to extend beyond the erroneous intersection) gapMean = FocalStatistics(gap, NbrRectangle(15,15,"CELL"), "MEAN") Lower only where it violates Upper, using the local mean gap lower_fixed = Con(lower > upper, upper - gapMean, lower) This sets the corrected lower surface to be below the upper by the local average gap (rather than just clamping to upper). ... View more

In ArcGIS Pro 3.6, Save Edits and Discard Edits apply to all edits made since the last save—there isn’t a built-in option to pick specific layers to save/discard. The dialog can only show where edits exist (click Show edits and review the Layers or Source tab), but it’s not a selectable checklist. You could author an ArcGIS Pro Idea for this item so it gets some visibility with the ArcGIS Pro development team. ... View more

Thanks for the info! A non-insert (listed under Updates) should normally have a Common ancestor representation available in the Differences pane—because Pro defines Common ancestor as “the state of the feature in the current version before it was edited.” If Pro can’t retrieve that representation for a feature that’s categorized as an update, it’s typically pointing to an inconsistency in branch versioning metadata or a service/query issue, not an expected editing scenario. One known, relevant class of problems is branch versioning metadata becoming inconsistent under conditions (features may end up “referencing a moment before the common ancestor moment” or otherwise not participating correctly in version operations). Esri documents this as a workflow issue and provides guidance for reviewing branch recovery versions after upgrades here - https://support.esri.com/en-us/knowledge-base/000032501  Also, there are ArcGIS Server fixes/patches around branch queries and the “ancestor moment timestamp” being used correctly for branch requests (again, not exactly your UI symptom, but related to retrieving the correct historical representation) Now to why it might be for only one approver - perhaps it's because you’re seeing it only via the feature service, and only intermittently, two things to consider: whether Pro is intermittently failing to retrieve the ancestor representation from the service (auth/token/session/network/cache), or whether only a subset of rows has missing/incorrect branch metadata (so only certain features/versions show it). To isolate the cause, try these checks the next time you catch/see the issue. Have the approver reproduce, then immediately test the same version/feature on another machine/user.  If only one user sees it, collect their Pro version/build, Windows profile, and whether they’re using the same portal connection. Compare through a different path (service vs direct admin inspection. You can’t view/edit named branch versions via an .sde connection (only Default), but you can use an .sde connection for version administration and inspection. Check whether the feature has odd system field patterns when the issue occurs (GlobalID, editor tracking fields, etc.) and whether the “Update” might actually be a delete/insert pattern coming from your workflow (some edits can be represented that way depending on the operation). To get your approvers unstuck, here's a potential workaround - when this occurs, have them use the map pop-up / attribute table plus the Version Changes list to identify which fields the editor touched (editor tracking fields can help), since the Differences grid isn’t reliable for that record in that run. Not ideal, but it’s the fastest operational workaround. Hope this helps! ... View more

This is not something I’d consider expected behavior for a non-insert in branch versioning. In the Differences pane for branch version changes, ArcGIS Pro is intended to show three representations per feature—Current, Target, and Common ancestor. The Common ancestor is defined as “the state of the feature in the current version before it was edited.” If the feature is categorized as Update (not Insert), Pro should generally be able to show that pre-edit state so only the truly changed fields are highlighted. "Is there a valid scenario where a non-insert has no common ancestor with default?"  At a version lineage level, a “common ancestor” moment exists (it’s the last moment the version and default referenced the same state). But what you’re describing is more specific: Pro can’t retrieve/represent the feature’s ancestor state in the Differences grid, so it flags everything. That usually points to a limitation/defect or a data/state edge case (rather than a normal editing scenario). What I need to narrow this down In the Differences list, is the feature under Update, Delete, or Insert? Does this happen for all approvers / machines, or just one? Is the layer coming from the branch versioned feature service only, or can you reproduce it when connecting directly to the enterprise geodatabase branch version (not through the service)? Has Prune Branch History been run recently, or do you use replicas/offline workflows? (These can affect what historical “moments” remain available, and are called out in branch history docs as related to referenced moments and pruning.) If you answer those, I can check for known issues/KBs specific to Pro 3.5.x + Enterprise 11.3 and the Differences pane/common-ancestor display. ... View more

Try these common fixes for ERROR 999999 with Transform Route Events in ArcGIS Pro 3.6 (it’s a generic “unhandled” tool failure): Repair geometry on the routes and any feature class inputs involved, then rerun: Data Management > Features > Repair Geometry. Avoid shapefiles/CSV for inputs or outputs: export everything to a file geodatabase (FGDB) table/feature class and use those. Use a short, simple output path and name (no special characters; don’t start with a number; avoid deep folders). Test a small subset (select a few routes/events and export to a new FC/table; run the tool on that). If it works, process in chunks. Run ArcGIS Pro as Administrator to rule out permission/write issues. ... View more

There's this BUG-000177883 for ArcGIS Pro that says it was fixed at 3.7 but it does make me wonder... ... View more