topic Re: ArcSDE Databases Have Extent Randomly Change in Data Management Questions

ArcSDE Databases Have Extent Randomly Change

EthanHunt1 — Tue, 24 Jun 2014 15:20:14 GMT

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

Re: ArcSDE Databases Have Extent Randomly Change

SteveSalas — Wed, 02 Jul 2014 18:45:32 GMT

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

Re: ArcSDE Databases Have Extent Randomly Change

EthanHunt1 — Wed, 02 Jul 2014 19:57:44 GMT

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

Re: ArcSDE Databases Have Extent Randomly Change

VinceAngelo — Wed, 02 Jul 2014 23:08:33 GMT

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

Re: ArcSDE Databases Have Extent Randomly Change

SteveSalas — Fri, 11 Jul 2014 15:26:39 GMT

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!

Re: ArcSDE Databases Have Extent Randomly Change

VinceAngelo — Fri, 11 Jul 2014 15:57:56 GMT

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

Re: ArcSDE Databases Have Extent Randomly Change

RandyKreuziger — Wed, 08 Oct 2014 23:58:41 GMT

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.

Re: ArcSDE Databases Have Extent Randomly Change

RandyKreuziger — Wed, 27 Jul 2016 17:38:31 GMT

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.

Re: ArcSDE Databases Have Extent Randomly Change

JohannaKollin — Mon, 24 Oct 2016 12:28:15 GMT

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

Re: ArcSDE Databases Have Extent Randomly Change

SteveSalas — Mon, 24 Oct 2016 14:52:05 GMT

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.

Re: ArcSDE Databases Have Extent Randomly Change

RandyKreuziger — Wed, 30 Nov 2016 17:18:47 GMT

This issue is killing us when the data is being edited and snapping is on even though the user is zoomed way in! Our users are asking if they can move their data editing from SQL Server to a File Geodatabase but that may be the only option since ESRI tech support couldn't help us with the randomly changing feature extents.

Re: ArcSDE Databases Have Extent Randomly Change

BarbaraS — Tue, 28 May 2019 20:39:09 GMT

We still have this issue, and reading this thread, it seems like we imported the error from copying data from old sde's. We never had an issue before, until we created a new sde on a new server in 2018. Features are shown in the default coordinate system of the database (ED50), but as soon as we use a projected coordinate system, some features (not all) disappear! The remaining features have in common, that they stem from the same project, so they most likely were added to the sde at the same time.

See screenshots of what is happening here:

Feature extent:

After using a projected coordinate system in the data frame:

We only manage to fix this error by taking a backup of the feature class, rebuilding the spatial index, removing the faulty features and copying them to the database again.

I think we have the same workflow as @Steve Salas, since we usually work in a projected coordinate system and then load the data into our sde, which has a geographic coordinate system. Something gets messed up here in this process... Just today we had the case of a user loosing features in a map with projected coordinate system, she then copied the missing features in but that caused ALL other features to go corrupt and disappear!

Is there any way to restrict the feature extent of our feature datasets or feature classes? Also, what would be the ideal workflow for our data? Creating features in a projected coordinate system in a gdb and then adding the data to the sde? What is the safest and best way to do it (since there are so many and we use all of them actually: tool Append, copy paste in an edit session and Load from the right click menu on the sde)?