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

Paul Ramsey pramsey at cleverelephant.ca
Fri May 23 17:46:33 PDT 2008


Down...

On Fri, May 23, 2008 at 4:38 PM, Paolo Corti <pcorti at gmail.com> wrote:
>
> 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).

This is why I say using ArcSDE (and really, by extension the whole
ESRI stack that comes along for the ride) castrates your spatial
database. It takes a highly functional and powerful data management
environment, and turns it into a bit bucket.

That's not to say that the ESRI environment you've now laid on top of
your database (now, bitbucket) is not powerful as well, but it is one
big glomph of code, and you are now committed to it, whole hog. Once
you've built your workflow and enterprise around the glomph, you'll
likely never escape it's clutches.

My experience has been that generalist IT folk have nervous breakdowns
around the ESRI stack, and that GIS people are more accepting of its
limitations (probably because its strengths cater to them, while its
weaknesses screw the IT folk).

P.

> 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.
>
> Paolo
>
>
> Paul Ramsey-3 wrote:
>>
>> SDE allows you to use ArcMap as a client. That's the main value
>> proposition.
>>
>> Secondarily, there's some stuff, most particularly versioning, that
>> they implement by managing extra metadata in side tables.  This is
>> where your concern regarding 3rd party edits to PostGIS data come to
>> reality. If you start mucking with the data, particularly versioned
>> data, outside the SDE environment, you can put it into an inconsistent
>> state.
>>
>> Also, you need some knowledge of the SDE scheme in order to properly
>> *read* the information out of a versioned system with a 3rd party
>> tool, since the data in the tables will include shapes from multiple
>> versions.
>>
>> In general, if you restrict yourself ot reading with 3rd party tools
>> and writing with ESRI tools, or non-ESRI tools working through the SDE
>> API, you should be safe.
>>
>> Yes, using SDE effectively castrates the spatial database. It still
>> walks and talks, but it's a shell of the man it was before.
>>
>> P.
>>
>>
>
> --
> View this message in context: http://www.nabble.com/PostgreSQL-PostGIS-and-ArcGIS-Server-9.3-tp17419730p17442724.html
> Sent from the PostGIS - User mailing list archive at Nabble.com.
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>



More information about the postgis-users mailing list