Tag Archives: Road Ahead
We’ve extended the one-way replication model at 9.3 to include file and personal geodatabases. So now when you are creating a one-way replica, the destination doesn’t have to be an ArcSDE geodatabase, it can also be a file or personal geodatabase.
This opens up a host of new replication scenarios since the child replica doesn’t need to be versioned or have SDE technology. This will also leverage one-way implementations such as production-publication scenarios or mobile users working in the field.
Here are a few more sources of information on replication topics:
- Gary MacDougal and I put together a whitepaper detailing common scenarios for replication called An Overview of Distributing Data with Geodatabases.
- The help topic Working with geodatabase replication offers a good walkthrough of implementing replication with links to other essential replication topics.
- Also, a new video in the 9.3 help system offers an example of how to create and synchronize replicas in a connected environment.
The following post was written by Simon Woo, a product engineer on the geodatabase team specializing in Raster support in the geodatabase.
Previous versions of ArcGIS have provided various mosaicking workflows. We’ve tried to make the mosaicking experience better in each version, but have had varying feedback on performance, especially when outputting to a file format.
Prior to ArcGIS 9.3, the workflow to create a mosaic was to create a raster dataset and then use the Workspace to Raster Dataset tool to populate the new dataset.
In ArcGIS 9.3, we have provided a new workflow to make your mosaicking experience faster.
The new workflow is to:
- Create an unmanaged raster catalog with the Create Raster Catalog tool.
- Load all the raster datasets into the unmanaged raster catalog with the Raster to Geodatabase tool.
- Use the Raster Catalog to Raster Dataset tool to mosaic the datasets together.
From the tests that we have run, this new workflow is considerably faster. Below are a couple examples of comparison tests that have been run.
Mosaic Test 1
Here’s the test data we used:
Type of data: 3-band
Input format: TIFF
Number of files: 20
Average file size: 38.8 MB
Output format: TIFF
Using the old workflow of creating a raster dataset and then using the Workspace to Raster Dataset tool, this data took 1 hour and 35 minutes to mosaic.
Here are the steps with the new workflow:
First create an unmanaged raster catalog.
This creates an unmanaged raster catalog. Now load the data into the new unmanaged raster catalog:
Now use the Raster Catalog to Raster Dataset tool to mosaic the rasters in the unmanaged raster catalog into a single raster dataset.
We conducted a similar test using GRID data and it yielded the following results:
Mosaic Test 2
Type of data: single band data
Input format: GRID
Number of files: 60
Average file size: 5.7 MB
Output format: GRID
Old Workflow – 45 minutes
Create Raster Dataset time: 1 second
Workspace to Raster Dataset time: 45 minutes
New workflow – 4 minutes
Create Unmanaged Raster Catalog: 1 second
Raster to Geodatabase tool: 1 minute
Raster Catalog to Raster Dataset tool: 3 minutes
The new workflow is shown in model form in the following graphic:
The following post was written by Kasia Tuszynska, a product engineer on geodatabase team specializing in PostgreSQL and the geodatabase.
The release of ArcGIS 9.3 will see an addition to the list of databases supported by ArcSDE. PostgreSQL 8.3.0 is joining the ranks of Oracle, Sql Server Informix and DB2 and is the first open source database to be supported by ArcSDE. I previously worked with SQL Server and Oracle and did not really know what to expect from Postgres, but I found it a very clever and well thought out database, I loved the online community, and I learned more from reading forums than any book out there.
We had an interesting time implementing ArcSDE for Postgres because we wanted to support the PostGIS spatial type and our own spatial type implementation st_geometry. This was a conscious decision so our customers who use both our software and open source software would not have to choose between one and the other but could use both, and potentially even keep it all in one database. We also implemented our own spatial type, st_geometry, it was designed to work with the different geodatabase functionality, we implemented it to make sure that any customer who wants to try out what geodatabases have to offer or who would choose to transition from one database to another would not loose any geodatabase functionality.
ArcSDE for Postgres will be released on Windows, Red Hat Linux and SUSE Linux. Since Postgres is open source and released with a BSD license we could include it in our installation, so if a customer wanted to install Postgres and SDE in one swoop they could do that in windows by executing one installation wizard, or two shell scripts for an install on Red Hat Linux. With SUSE we were halted by the lack of precompiled binaries for Postgres so installation will have to be done the old fashioned way – from source, but the rest of the setup can be done with scripts.
Implementing ArcSDE on Postgres had us learn the ins and out of the MVCC concurrency model, altering the way we send updates to postgres. We spent quite a long time tweaking the sql related to editing, trying to shave seconds off of the performance time. A lot of effort has also been put into the documentation, for folks already familiar with ArcSDE administration moving to postgres will probably be a snap but there a couple of small things to remember for postgres, so when in doubt please check the help. For instance, to avoid having your feature classes looking like tables in ArcCatalog and to make them accessible to everyone the “usage” privilege has to be granted on a schema to the public role. Also, installing Postgres on Windows has to be done through an admin account but the account under which Postgres (postmaster) is to run can not belong to the admin user group … Postgres idiosyncrasies like this can drive one crazy especially if you are not used to it.
This is our initial release and I am hoping that all of our testing caught every annoying little bug, but in case we missed something please do not hesitate to drop us a bug in Nimbus.
Ever connect to a version of a Geodatabase and ask “How is this Version different” ? At ArcGIS 9.3 we added the Version Changes Viewer to the Versioning Toolbar to answer this very question. The Version Changes Viewer provides the capability to view the changes made to a version since it was created or last reconciled with an ancestor version.
This is useful because:
- You can quickly see all the changes in a version without doing a Reconcile.
- The tool can be used to see the changes just within the current edit session or current map extent.
- You do not have to be editing to see what has changed in the version
How it works:
When the dialog is opened you select a version to compare changes with. The dialog lists all modified classes, inserts, updates and deletes, and allows you to view these in a similar experience to the interactive Conflicts Resolution dialog. It also allows you to view the changes made during your current edit session.
The Version Changes dialog will list all the changes made to the version for all layers in the map document based on the selected workspace. If the layer is not currently visible, changes on that layer will still be present in the dialog. Optionally, the changes can be restricted to only those changes in the present map extent by selecting the “filter changes using map extent” check box in the initial Version Selection dialog.
The Version Changes dialog box displays the number of changes that have been made to the version from the time it and the chosen target version were identical. The number of changes is subdivided by class, and then further subdivided into Insert, Delete, and Update categories. Clicking an ObjectID number shows its changes in the right window. All the attribute values for the two versions being compared and for their common ancestor are displayed. Attribute values displayed in bold signify that a change has been made to the version for that attribute.
A conflict on the geometries or the shape attribute of a feature class will arise any time the shape has changed on the same feature in the two different versions being reconciled.
At 9.2 and earlier ArcGIS releases, if there was a conflict on the shape field only one representation could be chosen. We didn’t really think this made sense because there were many cases where the geometry changes occurred in different parts of the shape, why couldn’t these changes be merged together? At 9.3 they now can with new functionality added by the geodatabase team for merging conflicting geometries during a reconcile operation.
This conflict occurs at the field level and is associated specifically with the Shape attribute. The option to merge geometries is available when there is a conflict concerning the Shape field. If two editors both edit the geometry of the same feature but do not edit the same area of that feature, they now have the option to resolve the conflict by merging geometries and accepting both edits.
The option to merge geometries is only available on the Shape field shortcut menu.
Once the geometries are merged, the end result is a feature that contains the edits made by both editors:
If the edits made by one editor share a region that was also edited by another editor, their edited areas will overlap. Although the option to merge geometries may be available, trying to do so will fail.