My understanding is that you *can* do "direct editing" on
SDO_GEOMETRY (if you have the appropriate licensing), but what
happens is that ArcGIS actually runs much of the SDE stack locally,
and maintains all the extra SDE cruft directly. The net effect is
slow and not so reliable as running SDE as a server. I also am not
sure you can do anything subversive like (*gasp*) create a new table
with SDO_GEOMETRY in a 3rd party tool then hit it directly from
ArcGIS without modification or extra steps to "register" it as a
spatial "layer".
P.
Which is to say, I think the answer is (a) yes and (b) no.
On 8-Feb-08, at 8:53 AM, Bart van den Eijnden (OSGIS) wrote:
"So, if you think direct editing of SDO_GEOMETRY from ArcGIS (a)
works and (b) works well then perhaps you have a case to believe
that direct editing of PostGIS is on the way too."
AFAIK: the answer to a) and b) is both no. You'll always need SDE
in between., if you use SDO_GEOMETRY.
I would love to be proven wrong though in this case :-)
Best regards,
Bart
Paul Ramsey schreef:
On 8-Feb-08, at 1:39 AM, dnrg wrote:
ESRI tells me that, at the ArcGIS Desktop release 9.3,
you'll be able to edit PostGIS data as core
functionality. No SDE required. This will open doors
and minds I hope. Paul, any comments on that?
I'll believe it when I see it. Different elements of the ESRI
marketing apparatus are interpreting the "support PostGIS"
announcement differently. The most believable story I have heard
is that ArcServer (nee SDE) will support a PostGIS geometry type,
in much the same way as it support the Oracle SDO_GEOMETRY type.
So, if you think direct editing of SDO_GEOMETRY from ArcGIS (a)
works and (b) works well then perhaps you have a case to believe
that direct editing of PostGIS is on the way too.
Paul, will PostGIS ever have versioning functionality
for editing workflows similar to ArcSDE? Guess that
would pervert the data, and then PostGIS would "own"
the data in a way like ArcSDE does presently. Still,
many shops find versioning valuable for workflows.
Database lock-in is a fact of life, simple because it is hard to
migrate databases, no matter how open they are. The best
versioning solution I have seen is the Oracle implementation,
which does "workspaces" using the basic MVCC versioning
information available per-tuple. I would love to have that, but
frankly it requires a lot of core PostgreSQL back-end work, and
the PgSQL core team doesn't have workspaces as a high (or even
low) priority item.
If we built a versioning system ala ESRI (side tables and
references), we could do a somewhat better job, because it would
be in the database level, not the middle-ware. However, it would
have the same limitations in terms of requiring client software
that knew what the heck to do with the stuff.
"Why not." Explain your use cases that cannot be met any other
way. There are some, but they are dwarfed by other use cases that
have higher priority, in my opinion. I see way more people using
PostGIS for geoprocessing, for example, so a more robust and
faster overlay facility seems like an important thing. Ditto for
more core geodetic support.
P.
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
Bart van den Eijnden
OSGIS, Open Source GIS
[EMAIL PROTECTED]
http://www.osgis.nl
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
