ArcSDE Databases Have Extent Randomly Change

[EthanHunt1]

Hello,

I've been having a problem with the extents of feature classes in our SDE here at work.  Our database is divided into feature datasets that have various feature classes in them.  The problem is as follows:  The feature classes are all in GCS NAD 27.  Sometimes, when editing data (digitizing features and filling in the fields), at some point, the extent of the feature class will change.  The data source is still set correctly, and while the top and right extent are still correct, the bottom and left extent get changed to -400.00 dd.  It's always the bottom and left extent that get changed as well.

I can't think of anything in particular that I'm doing to cause this.  There are a couple of us editing the SDE at the same time, but we are always working in different feature classes. 

It's possible to fix the extent by resetting the data source from a feature class that still has the correct extent, but I'd like to know why this is happening so that we can fix it permanently.

Thanks,

Ethan

[SteveSalas]

I don't have a solution but I can say we have a similar issue...  we use GCS NAD 1983 and sometimes the max extents of the feature class get changed to very large values that make no sense in terms of degrees of latitude/longitude.  If there is no data outside of our normal extent, we use the Feature Extent property tab in ArcCatalog to fix it, or sdelayer -o alter -E.

Other times we have data entered during editing that ends up a complete revolution around the world from where it should be.  To fix that I have to select those features in ArcMap and use "Move..." in the Editor toolbar pulldown to subtract 360 degrees from their location and the features are then in the correct location.  Then I can change the extents as above.

I've also had to fix dirty areas in topologies that go far outside the extent of the data - they cannot be validated as-is and you need to use sdelayer -o alter -E on the dirtyareas feature class as there is no topology extent property in ArcCatalog (10.2.0).

I've talked to several editors and tried to use their recollections of their editing workflows to duplicate it in my test SDE geodatabase, but so far I have not been able to make it happen.
http://forums.arcgis.com/threads/101700-SDE-Feature-Class-envelope-(max-x-y)-too-large

[EthanHunt1]

Good to know we aren't the only ones having this issue.  I did also find the feature extent tab and recalculating the values from there, which was nice.  My continuing research into this hasn't turned up much, but what I have noticed is that the extent of the feature classes is being changed to match the spatial reference domain values (Domain, Resolution, and Tolerance tab in ArcCatalog).  Of course, that brought up something else that puzzled me, which is why our Domain values are so bizarre (Max X/Y: 9006799.254, Min X/Y: -400 degrees).  The extent seems to be matching the Min X/Y values, but I still don't know what is causing it to change.

I don't have much experience with SDE's having just graduated recently (1 year ago) and not being responsible for anything but editing data, so I'm trying to learn about more than just our problem as I figure this out.

I am wondering if there is some correlation between something I'm doing while editing and the extent changing.  Occasionally when I'm editing, I'll accidentally copy/paste some info into the bottom entry that doesn't actually exist (usually by accidentally hitting ctrl + down arrow and pasting before I realize I've jumped all the way to the bottom), but which gets created once I put info into it.  I always delete the entry, but zooming to it puts me just off the coast of Texas in the gulf, near Houston, which is within the FC extent. After the last time I did this (admittedly on purpose this time), I came back the next day and the extent of that FC had changed again, although it hadn't changed when I left work (I made sure to check).  I have a suspicion my problem is related to this, but I can't figure out how exactly.

I hope something I've said above helps you either duplicate or find a solution to this/your problem.  Thanks for the details about your struggle with this.  If I didn't explain something clearly enough or you have any other questions/comments let me know.

Ethan

[VinceAngelo]

Keep in mind that there are two extents at play here.  The first is the envelope property
of the data in the table (SE_layerinfo_get_envelope()).  This is a user-specified value,
and is maintained by ArcGIS automagically (data added outside the existing envelope
updates the envelope). 

The second is the absolute limits of the coordinate reference (SE_coordref_get_xy_envelope())
which are absolute for a given coordref (from the falsex,falsey LL corner to the HIGH precision
64-bit integer limit in map units). You can learn more about this in the coordinate management
whitepaper.

If you mistakenly add data outside the limit then delete it, the layer envelope will not be
automatically recalculated (it's too expensive to query all features then and there to repair it).
There have also been bugs in the past where projected data, when added in native coordsys,
accidently updated the layer envelope in projected units (but I don't think this is your issue).

I usually initialize my GCS coordrefs to have extent {-180,-90,180,90}, just to eliminate
natural growth in the envelope (which is used in initial map extent and query optimization).
If they get out of whack, it's easy enough to set them right again.

- V

[SteveSalas]

Thanks for jumping in the thread, Vince...

"There have been bugs in the past..."  - how far in the past?  We're at 10.1 on both the desktop and ArcSDE and that was my first thought (adding projected data to the GCS SDE feature class), but I haven't been able to reproduce it...  I've asked the GIS editors to explain their workflow but unless you see them do it, most are hard pressed to recall what they did (typically they are natural resource specialists, etc. and GIS is not a primary function of their jobs).

Also, do you know if ArcCatalog 10.3 will support updating the envelope in T_n_DIRTYAREAS?  I've had to fix this with SDELAYER a few times and I understand 10.3 will not include SDE command line tools.

Thanks!

[VinceAngelo]

I don't know how far into the past.  It may have been a "feature" fixed in a late 10.0 SP,

but due to release overlap, may have been present at 10.1 (Final).  I can't imagine

it wasn't fixed by 10.1 SP1 (and there's been several years to get SP1 applied).

Reproducing this kind of compound error bug is usually very difficult, but if you do find

a use case, please let Tech Support know.

Without 'sdelayer -o alter'  at 10.3, the fallback would be SQL, though there might be

a tool which is less risky.

- V

[RandyKreuziger]

Steve,

  We started seeing problems with strange extents only after upgrading to ArcSDE 10.1 SP1.  I did the upgrade at the same time SQL Server was upgraded from 2008 to 2012 but it's probably the SDE upgrade that did it.  I've encountered more serious bugs in ArcSDE 10.1 then previous versions.

[RandyKreuziger]

We are still seeing this problem at 10.2.2.  Don't know why the feature extent changes to absolutely unreal values when the editors never zoom out beyond Washington state.  Performance when digitizing with snapping on goes from very slow to unusable!  In the past recalculating the feature extent, then recalculating the spatial indexes fixed the problem but not this time. 

We have several feature classes in a single feature database with topology set.  I'm opening a ticket with ESRI but if anyone knows of a solution for this or even ideas I'd love to hear them.

[JohannaKollin]

Has anyone come up with a solution to this? I´m having the same problem but so far with only one featureclass (sdelayer) in one of our datasets and we are using arcgis 10.3.

I have to recalculate the extent every few weeks, but then again it´s the featureclass we edit the most. But I would like a more permanent fix than to recalculate it everytime it gets messed up, because it can go a long time before I notice it has inconsistent extent. Tried exporting it to a shape to see if there´s something wrong with the layer but the shapes extent was fine. In my case only "max Y" remains the same.

In the printscreen the above values are after it gets all messed up and after recalculation it gets the right values (shown below). I tried searching for the problem, but the only thing I found was Error: Warning, inconsistent extent! and other unanswered topics. But that doesn´t help me at all. And I don´t think the problem is the coordinate system we are using or that it´s defined wrong since I created it from scratch like most of our other featureclasses that do work.

//Johanna

[SteveSalas]

I still have not found a consistent way to reproduce the problem, but in our case it usually looks like UTM values for our area instead of the decimal degrees that we have as the defined coordinate system - perhaps some problem with users editing the GCS data when their data frame is in UTM.

I'm considering rebuilding the data with a new spatial spatial domain/resolution/tolerance instead of the default values but not sure when I could do that as these are heavily edited feature classes.

For now I have a ArcPy script that runs nightly to loop through all data owner accounts and describe the feature classes.  If the extents are outside of a certain geographic area, I put that feature class in a list that I email to myself and the other SDE Administrator for correction when we arrive in the morning.