I created 2' contours for all of Garrett County, MD and have them all in tiles provided to us with the LiDAR data. When I generated the contours from the 1m DEM, I was unable to do it county-wide so I broke it down into 3 regions (top right, top left, and bottom). I also have 17 of what I'm calling "groups" of tiles (screenshot) that fit into one or the other region (except for group 11 ... read on to the 3rd paragraph). I had some overlap in all the regions to be sure that I had good data covering those boundaries. This actually causes some problems when I go to merge contours back together.
I finally fixed something that has been bugging me for a while now. When adding new addresses in our GIS database, certain zip code values (owner zip only) from out of state would be kicked out. It happened to me today so I decided to look at the properties of the fields in the database. It turns out that field was set up as a short integer. Now short integers (unsigned ones) allow values from -32,768 to 32,767 so a zip code of 34465 (the one I just tried) is out of range.
This post should have been narrated by Rod Serling. I was trying to select some records from a feature class. I noticed that the fields were in brackets [FIELD1] which I thought was different from what I usually see and I tried querying using the LIKE operator MDE_BNUM LIKE 'GA120208%' which should have retreived a number of results. I thought it must have something to do with the hyphen (aka dash) in the value but I can put a hyphen in a shapefile with no problem and select it this way. I suppose it is because this was in a personal geodatabase (thats all I can figure). It had an mdb extension. Just another reason not to use the personal geodatabase.
The project of the day a week or so ago was to make a fishnet layer to use for detailed large-scale maps made using data driven pages. I used existing coordinates for points along the y-axis and the cells should be 3,000 by 3,000 feet.
WARNING 001003: Datum conflict between input and output.
Except that all the inputs and the GDB specified and the data frame are ALL in the same coordinate system. The problem was that I still had an open edit session on the pour point feature class.
That is a pretty misleading and quite bogus error message. I'm using ArcMap 10.1.
A short script with a few inputs and outputs is one thing but when you have a script that performs a series of operations, some outputs are bound to be temporary intermediate outputs. For this reason, I wanted to explore using the scratch workspace in the general environment when formulating a large python script for ArcMap.
I finally found some useful information showing that you can output temporary feature layers like this ...
TMP_OUTPUT = "%SCRATCHWORKSPACE%\\OUTPUT1"
This works just fine for me and when I'm done I'll typically do this sort of thing to clean up the mess.
Like most things on my GIS blog, this serves to remind me of something. I'm a little late getting on board with the Geodatabase but more and more I'm adopting it for everything that I do (especially when working with ArcGIS 10.1). Not only have I finally started using the File Geodatabase but I recently started having output put into different Feature Datasets within the Geodatabase.
One thing that I need to remember is that you can't name two feature classes in two different feature dataset with the same name. It would be convenient if you could but it will scream at you that “it already exists”. You can argue that it does not but in the mind of ArcGIS ... it does.
I googled the title of this blog entry several ways and couldn't find any useful information so I wanted to post it here. I had the need to do a spatial join (in a script) but the tool in the toolbox doesn't give you the ability to get all the useful statistics (mean, max, min, sum, standard deviation) that you get by checking check-boxes doing a spatial join by right-clicking in the ArcMap table of contents.