My notes on the meeting with John Sharrard (ESRI Olympia) 4/26/01

Update on Arc8.1 release: Shipping 4/26/01 to high priority site. Many improvements over 8.1 pre-release. John was gong to work on getting us moved up in the queue.

Version 8.2 is next release (good year out) and you should see more functionality being developed for the new model. Dynamic segmentation should be in the October patch of 8.1. John noted that this is the biggest software implementation that Microsoft has seen on their operating system (even bigger than the operating system).

John likes Windows 2000 better than NT (it’s more stable, better performance).

John recommended using coverage or shape files to exchange data out of the geodatabase. He was going to look and see if the data got cleaned when exported out of the geodatabase into a coverage or shape file (this could be a problem).

John recommended that we don’t use ArcMap to edit coverages. The software actually takes the coverage, converts it into a geodatabase and the edits are done on the geodatabase. When you stop editing and save, the coverage is cleaned with the default fuzzy tolerance. ArcMap was not designed for editing coverages. It works best on shape files and geodatabases.

Why convert to a geodatabase? You can assign characteristics to your data that travel with the data. You can assign ranges of valid attribute values, relationships (this arc is connected to the next arc, change a line on one layer of data and it changes on all identified layers). You don’t have to program these relationships and ship the programs when you send the data to someone. The object characteristics go with the data.

The biggest reason to convert was a big improvement in speed with data across a network (especially from data in coverages)

Replacing the log file: 8.2 will have feature metadata and they are looking at how to replace the &watch file (it’s hard to do this with a multi thread program).

Raster data: Lots of problems with the pre-release. The use of the .vat file will not be available until later this year. Watch out for projecting raster files on the fly. It does not do a cell by cell project. It does a warp, which can result in some weird looking data (but it’s faster).

ArcToolbox will get smaller and smaller as more functionality is incorporated into ArcMap and the geodatabase. Right now, the analysis and topology results in the geodatabase are stored as temp files (not back in the geodatabase).

Duel processors will help but you can’t direct processing to one or the other.

Problems with the network: Need to know the delay time for packet transfer and optimize. There is an optimization white paper on the ESR website.

Realistic PC configuration: 512 GB Ram, 600 mh processor, Windows 2000.

Relational databases may need to be tuned differently for data loads (especially Oracle).

SQL Server, turn off transaction recovery. This has to do with the way RDBMS programs deal with transactions/changes. When you are converting large datasets, you need lots of scratch space and you don’t need backup and recovery (slows things down). Performance will increase if you pay attention to these things.

Levels of RDBMS

Access Personal use

SQL Server Middle tier up to 100 people

Oracle/DB2/etc. 24-7 redundancy and data recovery

Oracle More stable, more expensive (mostly in help)

Versioning same on both

Windows 2000 more stable than NT

Primary development of ArcSDE is done on Oracle (mostly because it is more difficult)

SQL Server easier to use, but not available on Unix.

Permissions are set by database (some are available in the geodatabase)

John’s recommendation was that SQL Server would be the way to start. If at some time we needed to migrate to Oracle, it would be possible and wouldn’t be too difficult.