Features effectively disappear from map

5868
7
Jump to solution
09-15-2021 08:20 AM
ZacharyUhlmann1
Occasional Contributor III

I've noticed this issue on multiple times, and seems time to troubleshoot.  Thsi time, simply added a layer to the map - a polygon with ~40 features.  Relatively small features, about the size of a house or pretty large house.  For some inexplicable reason I can only see them when zoomed in to a particular and arbitrary scale or scale range which changes per feature in the feature class.  

There are NO scale constraints on the Visibility range set in Properties

ex1) Zoom to objid5 -then scroll wheel out one zoom-in to 1:856.  Visible!

zoom_in1.JPG

ex2) see its neighbor objid6?

zoom_in2.JPG

2a) zoom in to objid6 (right click --> Zoom to Feature.  1:292

zoom_in3.JPG

In ex1 - I R-click on feature in table--> Zoom to Feature --> see nothing --> zoom out two scrolls 1:856, and the features appear.

In ex2/ex3) however (polygon in ex1's neighbor) I R-click on feature in table--> Zoom to Feature (1:292) --> see the feature! --> zoom out multiple times.  It remains visible to approx. 4th scroll  (1:1,743), after which the feature disappears.  Note that the first scroll back to 1:457 from 1:292 (Zoom to Feature)  the feature disseapers.  But then reappears for the 3 more zoom outs (scroll wheel) to 1:1,743

ex4) 1:457

zoom_in4.JPG

ex5) 1:1700ish

zoom_in5.JPG

ArcGIS Pro 2.8.2

Tags (2)
1 Solution

Accepted Solutions
David_Brooks
MVP Regular Contributor

@ZacharyUhlmann1 drawing errors like this can happened for a variety of strange reasons. A couple of ways of troubleshooting this:

1. Have you opened a fresh ArcGIS Pro project and tried the same navigation with those layers? Sometimes a corrupt Pro project causes it.

2. Did you create the project by importing layers from an MXD?

3. Have you tried setting the coordinate system of your map to match the basemap, and see if your test works then?

4.  In the Display settings of your layer, try changing these settings, to see what happens?

Brooks_SummitGeo_0-1631719611008.png

5. If the data is located on a network share, bring onto a local drive to test that version.


David
..Maps with no limits..

View solution in original post

7 Replies
David_Brooks
MVP Regular Contributor

@ZacharyUhlmann1 drawing errors like this can happened for a variety of strange reasons. A couple of ways of troubleshooting this:

1. Have you opened a fresh ArcGIS Pro project and tried the same navigation with those layers? Sometimes a corrupt Pro project causes it.

2. Did you create the project by importing layers from an MXD?

3. Have you tried setting the coordinate system of your map to match the basemap, and see if your test works then?

4.  In the Display settings of your layer, try changing these settings, to see what happens?

Brooks_SummitGeo_0-1631719611008.png

5. If the data is located on a network share, bring onto a local drive to test that version.


David
..Maps with no limits..
ZacharyUhlmann1
Occasional Contributor III

Thanks @David_Brooks  - 4) I'd attempted - mostly. 3) did not seem applicable since I constantly have basemaps not matching the coordinate system of features on the map. 2) and 5) were not applicable.  So I tried 1) and my feature class was missing from the catalog somehow!

Turns out I messed up when creating the layer.  Not 100% sure what I did, but when I opened a new project to troubleshoot per your recommendation, the feature class was not in the .gdb anymore.  BUT there was a standalone table (excel or csv deal NOT an FC) of the same name.  I think my previous zoom in zoom out debacle was using either the deleted FC from memory or the mystery table.  I THINK the mystery table was the result of some geoprocessing I had done to create the culprit FC initially.  The FC was a partial product of this: 

with arcpy.da.SearchCursor(table_in, ['att1', 'SHAPE@XY'] as cursor:
  for rw in cursor:
    # extract centroid coords and proceed
#create new geometry called points and create new fc
#arcpy.CopyFeatures_management(points, fp_out 

It may have been from not:

del cursor
del rw

After "arcpy.da.SearchCursor..." Despite the "With arcpy.da..." this post suggests (based off of ESRI docs) that we should STILL "del cursor/row" (https://gis.stackexchange.com/questions/254013/why-del-cursor-row-objects-of-arcpy).

So I added, reran and output a new culprit feature class which original produced the problem.  Now it's working.  

The recurrent problem of features disappearing is probably a separate issue of mine related to not closing an editing session properly.  This situation was related to probably running flawed code multiple times and the Table of Contents referencing a Table that wasn't a Feature Class.  Either due to not deleting cursors/rows or possibly just erroring out a couple times after the table was created incorrectly and not realizing it.  Phhhheeewww- long winded.  Thanks Brooks!

0 Kudos
ZacharyUhlmann1
Occasional Contributor III

Note - my solution was not necessarily on this list, but these are great reference!  Refer to my long response detailing my arcpy.da.SearchCursor woes if curious about my specific problem, but I suspect anybody arriving at this post were here due to @David_Brooks troubleshooting list hence marking it as the solution.

0 Kudos
David_Brooks
MVP Regular Contributor

@ZacharyUhlmann1 no problem. Glad i managed to help in a roundabout way 😉

The majority of my display issues come from working on client systems with network shares or remote desktop environments. So not often to do with the data itself, which can be a head scratcher.

I guess the other issue you had was that at some point the geometry was there, but during your latter testing you were seeing a cached image of the data that Pro thought was still there?


David
..Maps with no limits..
0 Kudos
JohnWatt
Occasional Contributor

Just ran into this same problem.  What worked for me was to delete the spatial index for the layer in layer properties.

Screenshot 2022-02-21 120750.png

ZacharyUhlmann1
Occasional Contributor III

Prescient timing John.  I haven't run into this problem enough to warrant more research, but a geometry editing task involving copying rows to new features, editing vertices, merges and unions has reproduced this problem multiple times today.  I just tried your solution, except I 'Recalculate[d]' the index, and it worked!  Thanks for that.  Clearly a bug, but at least I don't have to remove and reload the layer every time now.

KW_AE
by
New Contributor

Just had the same problem, and the "recalculate" trick solved it.  Thanks!

0 Kudos