Recalculating full extent of File Geodatabase feature class?

Recalculating full extent of File Geodatabase feature class?

I have a featureclass in an Esri file geodatabase. When I edit the features using the editor in ArcMap, and I delete most of my features and keeping only the ones in the middle, the zoom to layer command doesn't work as expected. Instead of zooming to the extent of the features remaining in the feature class, the extent will be the former one (containing all deleted features). When reviewing the extent values in the properties dialog for the feature class, I can clearly see the old values. So the edit session doesn't seem to alter the full extent values.

Is there a way to recalculate these values?

I am pretty sure that this problem should occur to everyone editing features in ArcMap…

Esri now has a tool for this in 10.4 (hooray): Recalculate Feature Class Extent.

I was running into this issue when I was creating a feature class and writing geometry into it with arcpy. Apparently those tools do not update the extent (probably a good idea for performance reasons).

I have been successful resetting the extent in 10.2.2 with @Lou 's suggestion:

arcpy.CompressFileGeodatabaseData_management(output_workspace) arcpy.UncompressFileGeodatabaseData_management(output_workspace)

Right-click the feature class in ArcCatalog and go to the Properties. In the Feature Extent tab, click on Recalculate. And voilà!

I'm using ArcGIS 10.2.1

Compacting the Geodatabase will tidy up your spatial index

"If you frequently add and delete data, you should compact your file or personal geodatabase on a monthly basis. You should also compact a geodatabase after any large-scale change. Compacting tidies up storage by reordering records and eliminating unused space. After compacting, the data in each file can be accessed more efficiently. Compacting also reduces the size of each file-it's possible to be able to reduce the size of a geodatabase by one-half or more."

Compact (Data Management)

"It is recommended to compact personal geodatabases when they become larger than 250 MB. If data entry, deletion, or general editing is frequently performed on a database, the database should be regularly compacted to ensure optimal performance."

Here is an ArcCatalog add-in for ArcGIS 10 that adds a command to update the feature class extent, likely using the same method as @Ragi's VBA code:

The GeoDatabase Extent always expands out - never shortens automatically. Compacting and Compressing only optimizes storage and fragmentation, but not the Extent itself. I would try recreating the spatial index first and see if that does the trick.


Since the spatial index rebuilding doesn't do the trick, I am sure the following VBA code will:

Public Sub reCalcExt() Dim pGXApplication As IGxApplication Set pGXApplication = Application Dim pGxObject As IGxObject Set pGxObject = pGXApplication.SelectedObject If Not TypeOf pGxObject.InternalObjectName Is IFeatureClassName Then Exit Sub End If Dim pName As IName Set pName = pGxObject.InternalObjectName Dim pSchemaLock As ISchemaLock Set pSchemaLock = pName.Open pSchemaLock.ChangeSchemaLock esriExclusiveSchemaLock Dim pFeatureClassManage As IFeatureClassManage Set pFeatureClassManage = pSchemaLock pFeatureClassManage.UpdateExtent Exit Sub ErrHandler: pSchemaLock.ChangeSchemaLock esriSharedSchemaLock End Sub

You can do this in any other ESRI supported programming language. The trick is to get a schemalock and to use the IFeatureClassManage::UpdateExtent method.

I don't know exactly what causes it in File Geodatabases, but I am indeed able to replicate it and it is something I've faced before. The only way I was able to find out how to bypass it is to Compress the file geodatabase. That will fix the extent issue. You will need to Decompress it when you're done, because you can't edit a Compressed file geodatabase.

During an edit/ArcMap session when you're actually using the data, you can always select all | zoom to selected as a workaround. It's not great, but I've used it in my workflow until I got to a breaking point where I could do that compress/decompress trick.

Note, Compacting will not work (at least, not reliably). It will rebuild your indices, but I've found it unreliable for fixing extent issues. It's still something you should do from time to time. I just tried it again right now, and it didn't work on my sample dataset. YMMV.

If you want to update extent of feature classess in your mxd document this chunk of code might help you:

Dim pLayer As ILayer Dim pEnumLayer As IEnumLayer Dim pFeatureLayer As IFeatureLayer Dim pFeatureClass As IFeatureClass Dim pFeatureClassManage As IFeatureClassManage pEnumLayer = pMap.Layers pLayer = pEnumLayer.Next Do Until pLayer Is Nothing If TypeOf pLayer Is FeatureLayer Then pFeatureLayer = pLayer pFeatureClass = pFeatureLayer.FeatureClass pFeatureClassManage = pFeatureClass pFeatureClassManage.UpdateExtent() End If pLayer = pEnumLayer.Next Loop

Recalculating full extent of File Geodatabase feature class? - Geographic Information Systems

I'm wanting to upgrade Mapnik on a production system from 2.2.0 to 3.x to take advantage of improvements to data-driven rendering. Fortunately the install instructions for Ubuntu have been updated very recently (11 days ago as of this post), however I'm wondering what happens if I run the installation on a system with an existing install. Has anyone tried this?

We're using TileStache to render several map tile endpoints, most importantly some UTFGrid json files, and I am concerned that I will pollute the system— maybe irreparably!—by running the install.

Can anyone comment on what might happen if I run the latest Mapnik installation on a system with an existing, properly functioning install?

[Edit 8/22/2018]

I got through the transition on a test server and incorporated my prior edits into an thorough answer below.

I remembered I had a tiny Rackspace instance that I setup once upon a time to test code portability. It has a nearly identical version of our webstack, particularly the Ubuntu and Mapnik versions, so it made a reasonable test bed to experiment with moving from 2.2.x to 3.x.

In a nutshell, this was a complicated transition that involved sincere troubleshooting, research, stack resets, some code modifications to XML stylesheets, and although I got things working again, my confidence is a little weak. Were this a production system, downtime would have been considerable.

What follows is a list of the 'gotchas' I encountered trying to nail down the build dependencies (c++ compiler version, clang version, git version, etc.) and some configuration/usage issues I ran into after the fact. Hopefully consulting this list can help avoid some unnecessary downtime and hasten the transitional process..

In attempting to install and configure Mapnik on Ubuntu using the official instructions found here, under the heading "Install Mapnik from Source", I suggest augmenting those instructions with information provided below. FWIW this is relative to Ubuntu 12.04.5 LTS.

First, before installing or uninstalling anything Mapnik..

Update the g++ compiler. Building Mapnik requires c14 compiler features, and you'll be unable to build if your compiler fails the dependencies/versioning test. In your terminal, type g++ --version and if your version is below 4.9 go ahead and update. I used the guide found here, specifically these commands:

2) Fix Clang

I had an issue with clang versioning and fixed it by adapting the instructions found here under the heading "Source install of Mapnik Master (3.x)" I changed all instances of 3.6 to 3.8 , and based on an error/warning I received on my fist install attempt, I added the --force-yes flag to the actual apt-get install instruction. These are the terminal commands I used to install the proper clang version:

When you're finished, you should be able to type echo $CXX and get terminal output clang++-3.8 or echo $CC and get clang-3.8 , respectively. If you don't get these responses, something may fail during a later configure/build step.

3) Upgrade Git

I initially ran into a git usage error related to use of a -C parameter the first time I executed the source command, which appears to establish some traits of the build environment. Googling for solutions, it seems I had two options, either modify the file by replacing instances of -C with --git-dir , as apparently these have equivalent functionality, or upgrade git.

You can run git --version in terminal—mine was prior to upgrading. After upgrading, my version increased to 2.18.0 , and the -C parameter issue disappeared. Upgrading was this easy:

4) not found

I forgot where I encountered this issue, during either source or possibly the ./configure.. step. But I got the error:

Based on the instructions under Set up build environment, manually installing libgdal1-dev like this fixed the issue:

I suspect you can do this before removing old Mapnik or starting any of the formal installation steps.

5) Honorable mention, severity unknown

When executing make test , I got errors like:

They might have been related to my installed PostGRESql version (9.1), which works fine. I never resolved these errors/warnings, but my Mapnik build/install seems to be working okay in spite of them. FWIW, elsewhere in the instructions, a note points Ubuntu 14.04 users toward pg 9.3.

6) Actually install Mapnik

At this point I uninstalled Mapnik, then started my fresh build/install. I'm not sure if it's 100% essential to remove your old Mapnik first, but I saw instructions recommending it, from Dane no less. So I removed Mapnik as my first step.

Everything went like this:

A few of these steps, particularly the make instruction, took quite awhile, probably because my server instance is tiny. But knowing this, at least don't expect just one or two minutes of downtime. Unless you play by wild-west rules, you'll want to do this upgrade during a reasonable maintenance window.

At this point I ran into issues importing Mapnik libs in Python. TileStache was throwing errors at Apache, which is how I noticed.

7) Install Mapnik Python bindings

First install the Mapnik Python bindings. It's super easy. Just make sure you have pip >= 1.4, which has something to do with the Python Wheels dependency. Use pip --version to check. Mine's pip 7.1.2, so I suspect pip version is a non-issue:

This will probably fix the issue.

8) Check ldconfig

You might not need to do this but the troubleshooting instructions call for a tweak to the LD config in the case of Python not finding Mapnik. I deviated slightly from the troubleshooting recommendation, based mostly on what I read here. Rather than add a path directly to /etc/ , I created a new file in /etc/ and added my path values there, like this:

Inside niklib.cof , add the following three lines:

After saving the file, update the environment with:

Note: If you dir /etc/ and see libc.conf , and if you vi /etc/ and see /usr/local/lib in that file, then you can skip this step #8, as your LD environment should already reference the necessary paths.

9) Mapnik XML design files (i.e. XML map stylesheets)

At this point I could launch Python and import Mapnik libs, but TileStache still wasn't rendering (most) tiles! By tailing the Apache log like this:

I noticed errors popping up that looked like this:

This took awhile to understand and fix. It turns out default build-from-source configurations for Mapnik use a different XML library ( rapidxml ) than was used for some turnkey builds ( libxml2 ), which I suspect a lot of people used around the 2.x release, most likely because those builds were promoted by one or more popular tutorials. The issue stems from so-called XML Entities, and it seems the (older?) Open Street Map (OMS) XML map designs used these XML entities, which further propagated this approach. You can find a longer discussion of this here.

As it happened, some of my own map designs were using XML entities to set the map srs/projection attributes, which were the source of my Apache errors. I got a lucky break by noticing that my UTFGrid tiles were actually rendering, and a close inspection of the map designs revealed a different manner of setting the map srs/projection. As such, I was able to make small changes to these XML files to eliminate the last of my show-stopping errors, bringing full functionality back online.

9a) What I did..

Basically I looked through my map files and changed every instance of something like this (notice the ENTITY tag):

9b) What you may prefer..

Optionally, if you need to fix/check A LOT of XML designs, you might want to check out xmllint , which has an option to sanitize XML Entities, and which you can incorporate into automation and use to mass-render all your XML files, then overwrite them into place with a single command.

Try calling xmllint --version . If you don't get any feedback, you can install the utility like this:

Once you've got it installed, look at a problematic XML file (one that contains an ENTITY tag), make a copy of it, and run xmllint on it like this to see how it morphs the code:

It'll pump XML right into the console, and you'll see those ENTITY tags replaced by their actual values.

10) Honorable mention, inconsequential (mod_python version)

At this point I cleared my Apache log file, rebooted, then tailed the log to see if any more errors were appearing. Of course on serious systems it's better to make a backup of this file before clearing it:

When I did this I saw the following (note mention of "version mismatch"):

I was concerned this might have been related to my build or my bindings, etc., but turns out it's related to mod_python , which TileStache uses portage internet requests and responses through Apache. Since my install is working, I chose not to rock the boat any further and stopped there. ..I probably had this error/warning all along. But if you get this error and you're so inclined, it seems removing and reinstalling mod_python may be a solution:

That concludes my experience going from a working Mapnik 2.2.x to a working Mapnik 3.x on Ubuntu 12.04. Hopefully this helps someone transition quicker than I was able to and avoid some of the frustrations.

Recalculating full extent of File Geodatabase feature class? - Geographic Information Systems

Stack Exchange network consists of 177 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Current community

Your communities

More stack exchange communities

Connect and share knowledge within a single location that is structured and easy to search.

Lecturer in Geospatial Technology, South Dakota School of Mines & Technology * USGS (retired) * Esri Certified Desktop Professional * Esri Geonet MVP >>> Go To Mines! <<<

Top network posts

Keeping a low profile.

This user hasn't posted yet.

Badges (1)




site design / logo © 2021 Stack Exchange Inc user contributions licensed under cc by-sa. rev 2021.6.28.39592

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.



Hydroxyethyl methacrylate and methyl methacrylate were purchased from Merck, Germany. Triethylene glycol dimethacrylate, dimethyl itaconate, 2,2′-azobisisobutyronitrile (AIBN) and 3-(trimethoxysilyl) propylmethacrylate, were supplied by Sigma-Aldrich, Germany. AIBN was recrystallized in methanol prior to synthesis in order to remove any impurities. Methacrylate polyhedral oligomeric silsesquioxane (POSS-acrylate) was obtained from Hybrid Plastics, USA and used as received. 3-[4,5-Dimethylthiazol-2-yl]-2,5 diphenyltetrazolium bromide MTT, alizarin red staining, dexamethasone and ascorbic acid (Sigma) were purchased from Sigma, UK, Roswell Park Memorial Institute-1640.


Polymerization reaction

The synthesis of silicon acrylate lens materials in combination with POSS-acrylate was the objective of this study. The polymerization of a number of carefully selected monomers was carried out taking a free-radical bulk polymerization approach for which the kinetics data as well as degree of conversion is reported here. Therefore, hydroxyethyl methacrylate, methyl methacrylate, triethylene glycol dimethacrylate, dimethyl itaconate, 3-(trimethoxysilyl) propylmethacrylate, and POSS-acrylate mixture were carefully mixed under N2 atmosphere until a homogenous mixture was obtained. Then, AIBN was added and the mixture was transferred into a proper mold. In the first step, polymer compounds were heated at optimized temperature (65 °C) for 24 h. The lenses were removed from the mold and maintained at 45 °C for 48 h to complete the polymerization. In Fig. 1, the polymerization reaction is shown schematically.

Watch the video: Book 1: Tutorial 4-1 Geodatabase