I thought I was done with the series a while back but I’ve been getting a steady stream of questions through other channels so I thought I’d wrap up a lot of the common stuff in another post. Most of the inquiries come from people trying to integrate ArcSDE for PostgreSQL with open-source tools in one way or another. Here are a few notes:
arcsde
Using ArcSDE 9.3 with PostgreSQL, Part 2
In my previous post, I discussed some approaches to configuring PostgreSQL databases and accessing the data in them with ArcSDE 9.3. For this post, I will describe some of my ongoing experiences with getting data into ArcSDE 9.3.
There are two main ways that I am investigating of loading/making available your spatial data in ArcSDE 9.3 for PostgreSQL. The first is the traditional method of importing a feature class via ArcCatalog. (You can also create data in this manner but I haven’t played with that yet.) The second is to register an existing PostGIS table as a layer using the “sdelayer -o register” command-line tool. I will discuss this latter option first.
Using ArcSDE 9.3 with PostgreSQL, Part 1
This post may cover some similar ground to that which Dave has been treading but I’m just trying to document my experiences as they occur.
By virtue of my association with zigGIS, I’ve been involved with using PostgreSQL and PostGIS in the ArcGIS envrionment for some time now. One of the primary sources of excitement about 9.3 for me was that ArcSDE would finally support PostgreSQL as an RDBMS platform. ArcSDE has always been positioned as an enterprise platform and has, therefore, been rather expensive. This expense has been compounded by the need to also separately license an RDBMS platform such as Oracle, SQL Server or DB2 in addition to ArcSDE. PostgreSQL helps alleviate some of that cost while also providing very advanced capability.
ArcSDE: Time For a Change
I view ArcSDE (and its predecessor, SDE) as something of a seminal technology. In my quest for true enterprise integration of GIS, ArcSDE fills filled a crucial gap by providing the ability to store, manage and analyze spatial data in the same RDBMS used for everything else. Long gone are the days when I had to manage relates between INFO tables or shapefiles and that’s a good thing. I have since accomplished similar tasks with PostGIS and Oracle Spatial but SDE was the first product I ever used that offered the capability to bring my GIS in from the cold.
At version 9.3, ArcSDE will support PostgreSQL as a back-end, meaning you don’t also need to license an expensive RDBMS in addition to ArcGIS to take advantage of everything ArcGIS Server has to offer. This gives us another option and options are good.
I have blogged before about my involvment with zigGIS, which has given me a lot of exposure to PostGIS. I’ve also done a good bit of work with Oracle Spatial. Both experiences have given me experience with, and a love of, spatial SQL (as each has implemented it). Having all of the data types and methods necessary to store, manage and analyze spatial data completely encapsulated in the RDBMS is a huge advantage. Building an n-tier or services-oriented system is so much easier because all I really need to interact with my spatial data is an OLEDB provider (we’re a .NET shop). This encapsulation serves to further expose the disadvantages of the current middleware approach of ArcSDE.