Yikes – I just saw this draft from yesterday that I didn’t get posted so pardon the untimeliness of it.
The closing Q&A session was over lunch and was pretty calm. A couple issues were raised that I thought I would mention.
VB6 will not be supported at ArcGIS 9.4 and you should really move to .NET.
The File Geodatabase SDK (or whatever it will be called) has been sidelined and they still need to figure out what it will be. The simple solution everyone would like is for them to just work with the GDAL team and get something written into GDAL/OGR (they did at least mention GDAL on stage). I’m just not sure what the problem is on this and why they don’t want greater use of the File Geodatabase (could be why I’m a consultant and they make money selling software).
Dave Bouwman asked them to stop overselling ArcGIS Server. His comment was well received by everyone out there and those on stage all agreed they need to do a better job giving a realistic picture of what it can do and how quickly you can deploy applications.
There was some worry about the future of ArcIMS. Of course the Web ADF works with IMS, but the picture is pretty clear that you need to start seriously working at migrating to ArcGIS Server. There were quite a bit of ArcIMS folks looking at the RESTful API and the JavaScript API. There is a natural progression from AXL to JSON I believe and being able to see the JSON will better help them understand how it all works. The point is though that you probably need to move on as no new features will be incorporated into ArcIMS.
It was the last chance to enjoy an ESRI Squishee
20 Comments
Kudos to Dave for his comments regarding AGS.
I’m disappointed, but not surprised, to read about the File Geodatabase API being shelved. When you think about it, a File Geodatabase API (with things like buffering and spatial select) would be somewhat of an AGS-lite, and would probably infringe on AGS sales.
mmmmm… Frozen/Blended ESRI Koolaid makes for a wonderful Squishee…
It would really be good to have a Squishee/Slushie machine at the IUC this year!
With how hot it is there, they could be quite refreshing, and the brain freeze would fit well with some of the sessions!!
No VB6 support anymore? ?
Is it really time consuming to move VB code to .NET, or is the process fairly straightforward?
I wish I had known this sooner, I jsut had our programmer write a bunch of new code for ArcMap using VB………
Really, MSFT won’t be supporting it anymore by then. It would be impossible for ESRI to properly support it if they themselves can’t get support from MSFT.
What will be the scripting language at 9.4? VSTA? Or do you think that will that kick in with version 10? Is Python beyond a geoprocessing context really likely?
Mark: How would you like map automation with Python (like AML and ArcPlot)?
Hey, hey….AML may be old and passe. But it walks 10 miles through 2 feet of snow and gets the job done.
Oldie, but a goodie.
KoS
So KoS, you like the idea of scripting mapping? Personally I wish this was available since 8.0, but we’ll jump all over this since “DS Map Book” is really not a great solution.
@Bonzo: Check out this presentation. Might answer some questions:
http://edn.esri.com/index.cfm?fa=conferences.detail&id=60&selectedConference=ds08
AML whosie and ArcPlot whatsit, just kidding, but only sort of; these basically predate my GIS awakening. My nursery was 3.x and 9.x (have I dated myself much). Tight MS Office integration is more or less requisite here (more common than you would like to think), so not nearly as much demand for using Python.
Well there is no really good scripting language moving forward as VBA is being dropped as well. I think Microsoft wants us to script using .NET, but we all know that really isn’t a great resource right now.
The feeling out of Redlands is that all scripting will by Python moving forward.
@james…..I’m currently using them, whether I like it or not.
Frankly, in a happy, sadistic way, I love the workstation vs. the desktop.
I’ve recently been dabbling in using python through the desktop with the workflow. If it runs as slow as ever thing else on the desktop vs. the workstation. To do the workload, I’m sticking with my oldie AMLs.
Then again, if IT can’t figure out this new bug with 9.2. I may move over to the desktop.
When the machine is plugged into the network. The workstation is slow and I do mean slow. Of course, runs at normal speed when unplugged from the network.
Surely IT can fix it? Why else they all 12 and 13s.
KoS
If we don’t have vb6 what do we have. Python and Eclipse are wonderful for geoprocessing but if you want to automate the interface itself. IE change the text of a label and print a map your basically stuck with vba. Especially if you don’t wan’t to have to deal with IT on installing an extension. I am guessing there are ways to build .net buttons without needing to build an installer? Or at least I hope so. I would love for the answer to be python. Or perhaps python.net?
Oh and Kos I went AML to VBA to Model Builder To Python and .net. Python is as close to AML as any of them and if you learn a few tips and tricks Python is in my opinion better.
What happens to VBA?
what about manifold?
OK, nevermind on using the desktop. At least with 9.2 and the previous versions. Maybe 9.3 runs faster?
I tried to clip elevation contours for about a 10 sq mile area using the desktop tools. It bailed out with a memory error after running for 7 and half hours.
This morning I converted the shape to coverage and then clipped it using the workstation. Took about 15 mins total.
Grrr!!!
KoS
Python is awkward and very annoying to use. I prefer C# any day.
I noticed at the Q&A ESRI was getting a little annoyed when someone asked them to provide .NET training and then someone asked for training in GIS concepts. You could tell they didn’t like those questions.
Ron If your used to AML Python is closer. Plus its closer to VBA than .net. I can build a script in python and send it to my staff in a toolbox. I don’t have to install a dll or exe on their machine. But I do choose to create python stuff in eclipse so its more like visual studio.
Kos I agree workstation does many things faster ,
my best recomendation would be to try a file geodatabase next time. I have better luck with geodatabases than I do with shapefiles or coverages. Not to say after hours I have not broken down and created a coverage or 100 myself. 
@KoS : You are not alone… true story below…
>>> Clipping issues in ArcGIS 9.2 >>>
Dear ESRI Support: I am having trouble using the clip_analysis function in ArcGIS.
I am clipping polyline contour data with USGS Quarter Quad polygons. The contour data is pretty dense and can be fairly voluminous – on the order of 250 mb.
After a couple of days of fighting this I did a few tests. The results were very surprising and in fact – quite disappointing.
I took one of the files that were proving to be problematic and ran the Analysis: Clip routine from within the ArcGIS toolbox, the command line and via a Python script. From ArcGIS toolbox and the command line I get identical results. After more than 11 hours of processing the process fail with the following message:
I have tried shapefiles and file geodatabases with the same result. When using a Python script it just fails and the same errors appear in the geoprocess messaging framework.
I ran the same clip routine using a clipping routine I created in ArcView 3.x using avenue and the same data in shapefile format. This process took less than 7 minutes!
I have validated these results on several different file that fail in ArcGIS but all run to completion in ArcView 3 in under 10 minutes.
I have tried many things to improve performance including creating shape indexes etc with no change in results.
>>> “ESRI Support” >>> *** Do not write below this line ***
Hello Sir,
My name is ESRI, and I have taken ownership of this incident. I understand that when running the Clip Tool, you receive an “Out of Memory” error.
In ArcGIS, adaptive subdivision processing was added to help improve performance. This comes into play when data cannot be processed when there is not enough physical memory on the computer. It divides the data into sections and processes each section.
An Out of Memory error can occur if:
The computer has to process an extremely large dataset. The subdivision approach does not help because features with millions of vertices are being split and reassembled along section boundaries, and this uses a lot of memory.
A second application is being run while trying to clip data.
To learn more about this process, please refer to this link to the online help: Tiled processing of large datasets http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Tiled%20processing%20of%20large%20datasets
Some things I recommend to help avoid the “Out of Memory” error: 1) Increase the amount of RAM on the computer. 2) End all other processes on the computer. 3) Clear Temp folder. 4) Defrag the hard drive. 5) Break up the large dataset into smaller datasets.
Please let me know if you have any questions regarding this incident.
Regards,
Hi ESRI,
I don’t mean to insult but apparently the adaptive subdivision process doesn’t work very well and certainly not better than earlier versions of the software.
The PC that I am using to do the processing is a really beefed up machine with 4gb of main memory that is basically optimized to run ArcMap. It’s got very little disk space used on the c: and d: drive. All of the suggestions that you make are the same that one would do for optimizing the machine for printing and we’ve been using ArcMAP long enough to have those practices in most of the things that we do.
Breaking the large dataset into pieces is simply not a solution I’m willing to accept. I’ll go back to using ArcView 3 to do that part of the work.
Regards,
>>> Office Conversation >>>
The sad thing is that on the help page they say that “In order to improve the performance and scalability of feature overlay tools such as Union and Intersect, operational logic called adaptive subdivision processing was added. The use of this logic is triggered when data cannot be processed within the available amount of physical memory.”
Then later on they say: “The subdivision approach will not help process extremely large features. Splitting and reassembling extremely large features multiple times across tile boundaries is very costly in terms of memory, and may cause “Out of memory” errors if the feature is too large.”
I read the the whole adaptave subdivision page and all I can think is that this process must have been introduced for a reason… not explained.
Obviously someone at ESRI knows how to clip large features since it works fine in Workstation AI and AV 3.x without over-consuming memory… This is a kludge that exposes how inefficient the current generation of ArcGIS software really is.
When will we get a fully functional GIS…. 10.x ? It is very lame to be moving backwards on the basics like clip, erase, identity, intersect, union, split, symmetrical difference.
IncidentNumber : Unfortunaly I can agree. I have seen many of these particularly with Raster.
Any chance we can turn this corner and head back to the lack of VBA for 9.4? I don’t want to write any more VBA code if I have to write it again later but I don’t want to have to build installers for simple tools. Python will do everything that doesn’t talk to ArcMap directly ie toolbox but what about the stuff that needs to print maps and such? Does anybody have any ideas?