Comments on: A look at PostgreSQL and ArcSDE

By: Gary

Gary — Tue, 20 May 2008 01:45:10 +0000

@Stefan
QGIS doesn’t have the ability to use ArcSDE layers. This would require compiling the underlying GDAL/OGR with ArcSDE support and a custom plugin to allow QGIS to load the data.

By: ChrisW

ChrisW — Mon, 19 May 2008 19:11:56 +0000

Tyler: “My background was first in database design and later in GIS, so I have found the simplistic ArcGIS joins to be limiting…”

Glad it’s not just me!

Chris (20 years Oracle, 9 months GIS – so far!)

By: Stefan Holzmann

Stefan Holzmann — Mon, 19 May 2008 08:38:33 +0000

I have a question.

Is it correct that at the moment I cannot access ArcSDE with QGIS?

We have an ArcSDE server at work and I would like to use QGIS. Are there any workarounds so I can do it?

By: Tyler

Tyler — Sat, 17 May 2008 19:09:24 +0000

Longtime SQL Server user and recent PostGIS convert…
A year ago I was using ArcSDE w/ SQL Server and now I am using PostGIS exclusively, although we still have an ArcSDE Server running to support old projects. The primary reasons for the switch were (1) the need to escape the license server and (2) my frustration with ArcSDE’s limited spatial views (i.e. sdetable â€“o create_view constructs) which severely limit what can be done with rich normalized data models, a point also mentioned by Luis, Bill, and AEMPhil. (My background was first in database design and later in GIS, so I have found the simplistic ArcGIS joins to be limiting.) Since the initial switch I have found PostGIS to be superior in pretty much every everything I use it for… although it’s probable that ArcSDE provides some additional functionality that I haven’t found a use for.

@AEMPhil: I agree with your point on the DB vs. GIS functionality, but I would add that I think it is appropriate for the DB to provide the basic geospatial functions (i.e. intersection, buffer, etc) that are commonly considered ‘GIS’. Another way to think of the division of functionality would be to have the DB handle the data (storage, filtering, and and standard spatial analysis) and the GIS handle the presentation (i.e. UI) and any spatial functionality that the DB doesn’t do.

And in regards to the original point of this thread, I have found PostgreSQL to be as easy to administer as SQL Server. And once you understand how the schemas work, you have another powerful tool for organizing your db objects and for setting up authorization.

Overall, PostGIS is an amazingly useful and beautifully designed thing…

By: Doug

Doug — Thu, 15 May 2008 13:11:39 +0000

@Volkmar: There are problems with using ArcSDE feature classes like tables in a normal database. I’m sure you know that you can’t have unique indexes on anything but the objectid if your feature class is versioned. You might think that’s no problem if you don’t need to edit this feature class using versioning, but ArcSDE forces you to version the feature class if you want to set up topology and other advanced features on the feature class. It can be very frustrating for someone trying to use it like a real RDBMS. There are work arounds, but none of them are ideal.

By: Volkmar

Volkmar — Thu, 15 May 2008 11:09:22 +0000

Well, I’m looking for alternatives to the proprietairy ESRI databases for a long time. Our problem is the imlementation of a data model including many non spatial objects which are related to spatial tables. The ESRI Geodatabase (Access or SDE) does not support the database constraints as it should. It just uses the database as a storage space- or am I wrong? I would love to have full integration with the database capabilities. I try to use PostgreSQL/PostGIS to implement my data model and use ArcMap for editing spatial tables (using ZigGIS). Trigger / Procedures in PostGIS will then insure consistency/topology etc.. However an extension for editing related alphanumerical data in ArcMap has to be programmed in any case. Has anybody an alternative?

By: Paul Ramsey

Paul Ramsey — Tue, 13 May 2008 17:20:26 +0000

@Doug, @AEMPhil, the elephant in the room is ArcMap. 95% of the value ArcSDE provides is the integration with ArcMap, and of course that value is artificially created by ESRI’s determination to force all spatial database interaction through the ArcSDE API, either locally through the cynically mis-named “direct connect” or remotely through a more conventional ArcSDE middleware server. ArcMap provides the GUI tools for data management and presentation, and there is value in that tool set, so much value that ESRI can use them to force their client base to pay for a whole extra layer of unnecessary software.

By: BigB

BigB — Tue, 13 May 2008 16:59:12 +0000

Support for PostGIS as the RDBMS for SDE is just another tool in the toolbox. I think you would be hard pressed to find commonly used analytical functionalities that ESRI will provide that PostGIS does not. However for data creation and data editing tasks on the PostGIS via SDE connectivity will be a good option for some.

By: Doug

Doug — Tue, 13 May 2008 14:28:06 +0000

@AEMPhil: Versioning and archiving in ArcSDE are different concepts than similar sounding RDBMS concepts. Check out ESRI’s website for more info. Back to the main point, I’m not saying that ArcSDE can do a lot of stuff PostGIS can’t. I don’t really know what PostGIS can do, so I can’t make an adequate comparison. I’m saying that there are things ArcSDE can do that simply spatially enabling an RDBMS can’t account for. GIS users often need more than a spatial data type and some functions that allow you to query based on geography. I’m not an expert on these things, so take my comments for what they’re worth.

By: AEMPhil

AEMPhil — Mon, 12 May 2008 19:40:20 +0000

@Doug: thanks for the reply. Your point on routing, geometric networks, etc. is well taken. These are core GIS functionalities that eluded me. I do believe that there exists a project called pgRouting for that, but I will simply admit ignorance on the issue and gratefully accept your point.
Topology rules are more easily implemented in PostGIS that SDE though IMO (PostGIS at home, SDE on top of Oracle at work, as a user, not maintainer); setting triggers to make sure that two geometries relate in the proper manner is rather easy on PostGIS.
As for your other points -versioning, backup, etc.- do you not think that these would be better left to the RDBMS administrator to handle? These issues have to be managed regardless of whether the data is spatial or not; shouldn’t we be looking for measures that are independent of the spatial character of the data as well? Another way of putting it is: shouldn’t we perform DB maintenance tasks with DB tools and GIS tasks with GIS tools? SDE feels to me as though it muddled that demarcation line.