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 <[EMAIL PROTECTED]> >Subject: [postgis-users] PostgreSQL/PostGIS and ArcGIS Server 9.3 >To: PostGIS Users Discussion <[email protected]> > > 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 _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
