Jackie,
This query is good to help to explain two real-world issues here:
1) The current implementation is for Oracle only and the SGID DB referenced in the article is SQL Server - so that's a quick "no"!
Haris and I discussed the various options of providing a generic provider at length and with the performance required, KingOracle platform in existence, test data/systems available and the requirements for funding this the project became an extension to KingOra. The decoding of the metadata and the SDE binary geometry *should* be available in the OpenSource submission to be utilised in other direct providers such as the OSGeo SQLServer provider.
2) To enable direct access, the actual underlying host RDBMS credentials (not ArcSDE server) will be required for an ArcSDE connection. This database may sit at a different security level to public services or may be exposed with different port/username/password. The SGID DB service exposed in your sample is only the ArcGIS server details not the database connection.
Hope this helps - I'll add some more detail to the RFC as this thread develops.
Crispin
Jackie Ng wrote:
Would this direct ArcSDE provider support connecting to remote instances like this example here?
http://gis.utah.gov/sgid_connect- Jackie
Crispin_at_1Spatial wrote:
All,
I found the previous version of this message was still pending so am resending.
I got confused between nabble and OSGeo subscriptions!
Please see the draft RFC available at:
http://trac.osgeo.org/fdo/wiki/FDORfc42I hope it will be of interest - especially as a platform for involvement and as a potential vehicle to support ArcSDE in 64-bit.
The instructions for
http://trac.osgeo.org/fdo/wiki/FDORfcs do not indicate how to get a PSC guide assigned (required I presume) ... how does this element work?
Regards,
Crispin
1Spatial.com
