Back in 2010, I posted a python script and an ArcToolbox tool for zipping a shapefile.
Well, I had a request to modify the code so it would not error out if it encounters a .lock file. While .lock files exist for a reason and shouldn’t be totally ignored, in some cases it is safe to do so, so I went ahead any modified the code, which can be downloaded from Github.
The guts of the code is here, though:
theShapeFile = sys.argv
outputZipFile = sys.argv
skipLockFile = sys.argv
def zipShapefile(inShapefile, newZipFN, skipLockFile):
print 'Starting to Zip '+inShapefile+' to '+newZipFN
if not (os.path.exists(inShapefile)):
print inShapefile + ' Does Not Exist'
print 'Deleting '+newZipFN
print 'Unable to Delete'+newZipFN
zipobj = zipfile.ZipFile(newZipFN,'w')
for infile in glob.glob( inShapefile.lower().replace(".shp",".*")):
if not ((os.path.splitext(infile.lower()) == ".lock") and (skipLockFile.lower() == "true")):
Someone mentioned an idea on ArcIdeas for making various display settings on a feature classes scale-dependent. Right now some of that can be accomplished by loading a feature classes multiple times, adjusting the settings, and setting the visible range. Working more and more in ArcGIS Server, I can see the value of increased scale-dependent settings.
I’m not sure how rapidly ESRI takes “Ideas” into consideration but if you feel like it would benefit you, why not promote this idea: Scale Range, SQL Query and Symbology Rendering in ArcMap.
Have a good weekend, all!
I was making an edit (adding leading “0”s) to a coded-value domain in an SDE database and realized that my edits were changing the order of the rows of my domain. Rows were moved to the bottom of the list when they were edited.
So I went through the process of converting my domain back to a table, made my edits in Access and exported the rows to a .dbf in the order I wanted them.
I removed the domain from the field I knew it was assigned to but when I tried to delete the domain, I received an error (The domain is used as a default domain).
The Google Machine led me to an ArcForums post by with some python code for listing all the fields with a domain.
I tweaked the original a bit, first because it was only examining feature classes in a feature dataset, not stand-alone feature datasets. And secondly, I updated it to use arcpy. I posted both the 9.3 version and the 10.0 version, but here is a quick look. The key addition is the ‘listfc(“”)’ line that is the first line of the def listds() module.
min_workspace = r"C:\Users\mranter\AppData\Roaming\ESRI\Desktop10.0\ArcCatalog\min.minstaff.sde"
arcpy.env.workspace = infgdb
featureclasses = arcpy.ListFeatureClasses("","",inDataset)
for f in featureclasses:
print "feature class: ",f
for lf in lfields:
if lf.domain < "":
print " domain",f, lf.name, lf.domain
for d in datasets:
print " dataset: ",d
In building our Enterprise GIS Database, we need to support users with different needs. Some of our users just need to see the data on a map while others may want to download a copy of the data so they can use it within their own desktop system.
After doing some exploring, one of the options that looks like it will feel the bulk of our internal needs is to create a Map Service/Geodata Service pair–by creating a Map Service, we can make an easy-to-use visual representation of our data. Combining that with a paired Geodata Service–a Geodata Service with the same name as the Map Service–we can accommodate those users who want to extract the data to their hard drive.
A user who has added paired Map & Geodata Services to an ArcMap dataframe can use the Distributed Geodatabase Toolbar to extract data to a local geodatabase. The Extract Data button is on the far right of the Distributed Geodatabase Toolbar.
Unfortunately, my first attempts at testing this did not work. It would look like it was processing, I would end up with a .mdb or .gdb file on my hard drive but I could not open it. I would get a “Failed to connect to database. This release of the GeoDatabase is eitehr invalid or out of date. [Unknown GeoDatabase release.] The Microsoft Jet database engine cannot find the input table or query ‘GDB_ReleaseInfo’. Make sure it exists and that its name is spelled correctly.” error.
When exporting to an .mdb file, I could open it in Access and see the data.
Luckily the error is fairly helpful–I was getting an ArcGIS 10 Geodatabase even though I am running ArcGIS 9.3.1 on my desktop. I was able to open the exported geodatabases using a copy of ArcGIS 10 on another machine. The reason for the inconsistency is pretty interesting. Our office is, and for the foreseeable future, running in a mixed-version environment. We have a mixture of 9.3.1 and 10 desktops, a 9.3.1 ArcSDE server and a 10 ArcGIS Server. The Extract Tool is a server-side function apparently that creates a version 10 Geodatabase.
The way to get around this is to extract the data to XML and then import the XML workspace into a geodatabase. Not sure if that will work for all schemas but it was successful for me.
We finally installed an instance of ArcSDE 10 today. My first attempt at connecting in ArcCatalog 9.3.1 failed with the following error:
Failed to connect to the specified server.
This release of the GeoDatabase is either invalid or out of date. [Please run the
ArcSDE setup utility using the -o install option.]
DBMS table not found[sde.sde.GDB_Release]
Turns out the solution was simple, this article points out that Service pack 2 is required. After updating my ArcGIS, the problem was solved:
I was the proud, new recipient of a non-misleading error message. After some minor head-slapping, I realized that 9.3.1 and older versions of ArcGIS are not able to connect to ArcSDE 10. Doh! My bad–I should have read ESRI’s clear information on this topic. At least I never actually tried to install ArcSDe with the -o option as the first error message instructed me to do.