Skip to content
October 24, 2006 / Steven Pousty

Geoprocessing error translation – alternate solutions

Alright so you want to make some contours of your DEM and you are using ArcGIS 9.1 SP 2. You go to the spatial analyst menu and choose surface analysis and then contour and then, voila, you have locked up ArcGIS. So then you think – GP will solve this like it has on so many other occasions and suprise suprise you get this helpful error message:

Executing (Contour_1): Contour elev10m C:\data\\newModels\geodatabase\scratch.mdb\elev10countour 4 0 1
Start Time: Tue Oct 24 14:29:56 2006

An error was encountered while executing Contour.
(“esriGeoAnalyst.GridEngine”) Error in executing grid expression
Failed to execute (Contour_1).
End Time: Tue Oct 24 14:31:56 2006 (Elapsed Time: 2 minutes 0 seconds)

And you think the helpful part was that it chose to throw the error message after 2 minutes rather than 10 minutes later. Then you start to sweat a bit and wrack your brains, resist the urge to spark up AV3.3 and remember the raster calculator.

You enter:

C:\temp\countours.shp = contours([hcpnccp10m], interval, 5)

and holy cow you actually have a countour coverage.

My Question ™ in this exercise is what is the difference in algorithms or routines between raster calculator (RC) and GP? I consistently get RC to work when GP fails. My sneaking suspicion is that RC is using something from Workstation while GP is using gerbils and bubble gum. Perhaps ESRI should make it easier to script RC.

update (20 minutes later): It seems the error may have been that I was asking GP to make a geodb bigger than 2 gigs which is a no-no. I am not sure if this is why since the error message from GP tells me nothing that helps tell me where to go next. But I could get GP to work by having it write to a shapefile and a grid contour of 6 rather than 4. So for now I take back some of the bad things I said about GP. But still in general RC just seems more rock solid than GP.

Advertisements

4 Comments

Leave a Comment
  1. Matt / Oct 24 2006 5:29 pm

    There is a registry workaround to allow pgdbs to be larger than 2g (if you dare). It’s in the Jet Engine’s MaxLocksPerFile key, set that to say 999999 and you shouldn’t see that problem again 🙂

  2. thesteve0 / Oct 24 2006 5:47 pm

    K, Mr. Matt but that is a scary option. Thanks for the hint but I am not going to touch the registry on that one. I could just see the call to ESRI tech support…”how did you get your geodb to be bigger than 2 gigs and how fast can I hang up the phone…”
    Though I am serious about thanking you for the hint…

  3. dylan / Oct 24 2006 11:46 pm

    Hi Steve, been especially fun reading your posts lately. Check out some of the posts on the GRASS/GRASS-dev mailing lists about large file support. While this has been a no-brainer on linux for quite sometime, getting LFS (large file support) working on other archs has been a bit of a headache. However it looks like many of the bugs are being worked out for having portable LFS source code.

    Cheers,

    PS: good luck with those cyptic error messages!

  4. thesteve0 / Oct 25 2006 9:05 am

    Hey Dylan:
    I will look into those GRASS posts – for me it is the cyrptic error messages which are the problem. If I knew it was the 2gig limit then I would have known what to do next. With such a general message I am left confused about what went wrong and what I should do next to get my work done.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: