[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgis-users
Subject:    Re: RE[postgis-users] L PostgreSQL/PostGIS and ArcGIS Server 9.3
From:       Paolo Corti <pcorti () gmail ! com>
Date:       2008-05-24 1:01:38
Message-ID: 17443292.post () talk ! nabble ! com
[Download RAW message or body]


Hello Ragi

thanks for pointing out this, interesting to know that they have understood
that the dll problem needed a solution.
Btw: forgot to mention in my previous post that at my office I am still at
9.0 with desktop, and that i migrated the server side to PostGis and
MapServer ;-)

Paolo


Ragi Y. Burhum wrote:
> 
> 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@gmail.com>
> > Subject: [postgis-users] PostgreSQL/PostGIS and ArcGIS Server 9.3
> > To: PostGIS Users Discussion <postgis-users@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
> _______________________________________________
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 
> 

-- 
View this message in context: \
http://www.nabble.com/REL-PostgreSQL-PostGIS-and-ArcGIS-Server-9.3-tp17443108p17443292.html
 Sent from the PostGIS - User mailing list archive at Nabble.com.

_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users


[prev in list] [next in list] [prev in thread] [next in thread]