REL [postgis-users] PostgreSQL/PostGIS and ArcGIS Server 9.3

[Ragi Y. Burhum]

Hello Paolo,

Excellent explanation. It definitely shows a great understanding of
the ESRI technologies. I do have a slight comment though.

>Fri May 23 16:38:22 PDT 2008
>From: Paolo Corti <pcorti at gmail.com>
>Subject: [postgis-users] PostgreSQL/PostGIS and ArcGIS Server 9.3
>To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
>
> Hello Paul
>
> it is not only a question of versioning, ArcSde - together with ArcObjects -
> make possible to use the Geodatabase model in any RDBMS supported by ArcSde.
>
> The pro of this is having a lot of out of the box functionalities, like
> domains, referential integrity, relationship class, networks, topology,
> constraint on data, etc...
> Customizations will be consistent whatever RDBMS you choose, so won't be
> hard to switch from SQL Server to Oracle for example, or vice versa. You
> will need just to transfer the data from one platform to the other (from
> ArcCatalog or by the command line) without the need to rewrite triggers,
> constraints, functions....
> But if you are using the Geodatabase model, you are then - as you are saying
> - highly tied to ArcObjects (and so to ArcMap), that meaning that you will
> need to exclusively rely on Esri clients for editing and even viewing data
> if you want to enjoy some of the out of the box stuff (like relationship
> classes).

Agreed.

>If you just need an OGC simple feature viewer then you can read
> the data without problems.
> And is not only a question of making it very difficult to read and write
> arcsde data from other applications, is even almost impossible to use the
> RDBMS features (trigger, functions, procedures, constraints, etc...) without
> compromising the database. The only way to put some intelligence in the data
> is then demanded only to COM ArcObjects, from the application or by
> deploying dlls that will interact with the data streamed from the database.
> For example if in a PostGis table you write a trigger that after any insert
> will copy in the table a value from another table under some spatial
> operator criteria (for example copy a value from a polygon in which a point
> is contained), and this is relatively simple - and powerful, no need for
> cursors here - to make with Spatial SQL, with Geodatabase (and ArcSde) you
> would need to write an ArcObjects dll and deploy that at any client. This is
> even a problematic solutions, because you will have a deployment issue.


This is one of the ways to do it (the recommended one). But it does
highly depend on your data  as well as what features from the
GeoDatabase you are using. For example, with ArcGIS versions >= 9.2,
if you are using nonversioned editing or even versioned editing with
the move-edits-to-base option, you can have database triggers that can
modify your data after you have inserted it or deleted it, database
contraints, etc; provided that those are not complex types. That is
exactly why these modes where introduced.

Another option, is to edit through ArcGIS Server where only the server
would have the ArcObjects DLL custom behavior.

In either case; no need to deploy any ArcObjects dlls to all the clients.

Anyway, what I am getting at is that it is very possible to integrate
PostGIS with ArcGIS Server. However you have to weight the level of
functionality that you need... you can't get all the ArcObjects
features (which are mostly client-side logic) without sacrificing the
server side RDBMS functionality and vice-versa. The trick is to find
your sweet spot.

- Ragi Burhum