georeference.org
Subscribe to this thread
Home - General / All posts - Interop with ESRI SDE, OGC, GDB
gsmith4 post(s)
#02-Mar-06 15:05

We're an ESRI site looking for alternatives/integration choices.

Does Manifold have the capability to directly connect to ESRI GeoDatabase layers from either MS Access or from ArcSDE sources?

Can Manifold read OGC WMS and WFS web-GIS services.

Thanks

Dimitri


3,145 post(s)
#02-Mar-06 15:38

Yes to geodatabase from .mdb files (ie, Access), no from ArcSDE. Manifold doesn't believe in ArcSDE middleware and thinks that geometry data should be directly stored and accessed in the DBMS of choice by the GIS, for example, in OGC WKT/WKB, "shapefile" geometry format as used in geodatabases, or Manifold geometry. Pretty much any DBMS that can handle binary blobs can be used in this way, which is all of the big-time ones. But that's changing very rapidly.

As of the April SP1 you'll also be able to use Manifold to create/read/write/edit geometry in native Oracle Spatial (SDO_GEOMETRY) form in addition to all the above. I can't think of any reason why anyone would want to use ArcSDE instead of connecting directly to Oracle. Oracle direct is faster, much more flexible and directly interactive with very many GIS applications without requiring an ESRI leash around one's neck. It's also a fraction of the price since you don't need to pay for unnecessary middleware.

Experts such as Simon Greener can no doubt comment in much greater detail as to the disadvantages of using ArcSDE as opposed to a direct connection to, say, Oracle.

In the unsolicited opinions department, it doesn't make much sense to use ESRI geodatabases if you can at all avoid them: they combine the worst features of shapefiles with the risks of .mdb. We're all Microsoft fanatics here, but if you read up in Microsoft's knowledge base what it takes to keep an .mdb file alive and uncorrupted, especially in a multiuser environment, it will make your hair stand on end and you will immediately begin looking for an alternative.

If your data matters and it would be a hassle to have it lost or corrupted it makes a lot more sense to use a modern DBMS such as SQL Server or Oracle and not Access .mdb files. Manifold will work with all of them, including Access .mdb, but it's just safer to use more reliable DBMS technology. For now, people are using Manifold with whatever DBMS they prefer, ranging from SQL Server to Oracle to MySQL to DB2 and many more. But I think that will change once access to Oracle spatial technology becomes ubiquitous and inexpensive as there will be a lot of appeal to using Oracle's Spatial technology.

I predict that once we issue SP1 folks will jump into Oracle Spatial and not look back, probably using Oracle XE, the freely downloadable, up-to-4GB Oracle answer to SQL Server Express, which will incorporate Locator (ie, SDO_GEOMETRY) capability. It's unbelievably fast and completely reliable. Having worked with the betas, I can report the Manifold + Oracle combination blows anything else out of the water. And, of course, you're keeping your data inside Oracle using standard Oracle technology supported by all the major GIS vendors so even if someone in the IT department feels an overwhelming need to spend buckets of money on legacy GIS technology, they can still do so! :-)

Manifold can be a client to an OGC WMS server and can also function as an OGC WMS server. Manifold does not as yet support WFS, although I suppose that too will come some day unless interest in OGC continues to wane.

Hope this helps!

petzlux

982 post(s)
#03-Mar-06 01:16

Does that mean that SP1 will also support Oracle's Spatial extension , eg allow for spatial sql queries and functionality ? I dont know if the free Oracle edition includes Spatial, but would be interesting to allow Manifold to use Oracle Spatial Engine to do advanced queries on big fat servers.


Check out the Manifold Wiki with SQL and scripting examples at http://www.manipedia.eu/

Spatial Knowledge, my personal blog.

Dimitri


3,145 post(s)
#03-Mar-06 09:48

Yes, SP1 will do all that. The free Oracle XE (express edition) beta right now does not include Locator capability (which is all you need for such things given Manifold) but I suspect the released version of XE will.

Note that the Oracle Spatial product, as opposed to say Oracle XE or Oracle 10g, has three things that distinquish it: a) the ability to work with SDO_GEOMETRY, that is, the native Oracle spatial vector geometry type, b) the ability to work with GeoRasters, that is, Oracle's native spatial raster type and c) a variety of useful utilities and GUI things such as Oracle's mapviewer.

I am far from being an expert in Oracle's product line, but I understand that 10g has a) and b) and that XE will have a). If you have Manifold, I suppose you could live without c), although I can see that someone seriously going into Oracle spatial technology will no doubt license Oracle Spatial as a superset of 10g.

The essential thing to understand is that the core technology within Oracle Spatial is now within *all* mainstream Oracle DBMS products. It's a big commitment by Oracle which I think does a great job of encouraging people to have the confidence to standardize on Oracle for their spatial needs. It also provides a natural ladder upwards with low risk at each rung to the next step up.

If you are just getting into it, you can do spatial things with drawings just fine with Manifold and Oracle XE. That's a huge range of applications and the Oracle part of it is free. This is a no-brainer.

When you want to work with more than 4GB of data or do similar things with images, well, you step up to 10g Enterprise, which has georaster capability as well as Locator. 10g costs more, but Oracle is out there in a seriously competitive mode so 10g ends up being surprisingly affordable for the organizations that need such things.

Or, perhaps you immediately step right up to Oracle Spatial so that in addition to all the above you have all the Oracle accessories for the complete, well-equipped Oracle Spatial IT shop. Spatial is just a bit more than 10g and if you have the resources to be in this game no doubt you want to be in it all the way.

From a technology point of view, yes, you could do advanced queries on big fat servers. It's amazing stuff as Oracle 10g and Spatial scale really well so you could have a whole server farm (hundreds of them) working on your behalf. :-)

If I seem to be gushing on about this, well, I don't get paid anything for selling Oracle products but I have to say that once you get some experience with the Manifold + Oracle combination it is just really, really impressive stuff. I guess maybe someday I'll get jaded and be used to it, but for now I'm still in the "Wow!" phase at how fast and powerful the combination is.

gsmith4 post(s)
#03-Mar-06 09:21

Hi Dimitri,

Thank you for your quick response and useful insight. I agree with your references to ESRI and ArcSDE. Our reality is that we have an enterprise ESRI implementation that satisfies core aspects of our information management regime, albeit at a large price tag. However, we plan to take a close look at Manifold as a client platform to support applications with interoperability to the ESRI world. If Manifold can close that gap, that would be a big incentive for us to implement it. I think OGC WMS/WFS is one the way to build that interop.

I've been following Manifold's penetration into the market, and I admire the strategy to take a run at ESRI's enterprise solutions. An alternative to the ESRI 'monster' has been long overdue. We plan to look at its enterprise side also, and if Manifold lives up to the hype and we implement it in our agency, it will make a large splash in the small pond here in Ontario where ESRI dominates.

We want to get Manifold for evaluation, is there a sales rep in Ontario or for Canada?

Thanks,

Graham Smith Grand River Conservation Authority

Dimitri


3,145 post(s)
#03-Mar-06 10:24

Hi Graham,

Manifold doesn't use sales reps but simply sells direct via Internet worldwide. If you get, say, Professional or Enterprise edition you get a 30 day money back guarantee (see the terms and conditions of sale on the Online Store entry page for details). We have many customers in Ontario and in Canada overall, and quite a few are active in this forum.

I personally don't have to interop with ESRI except in trivial ways, so my experience of that is, well, shapefiles, or reading in .e00 files. There are many people on this forum who do interop with ESRI on a daily basis so perhaps they could offer a more sophisticated view on effective tactics.

From a strategic perspective, as much as I understand the appeal of "open" formats, I don't recommend buying into OGC. It's basically a bureaucracy of legacy guys unaquainted with modern technology who end up writing low-performance, inept standards that exclude modern ideas.

A further problem with OGC is that they favor political correctness over common sense, so at times they try to be so inclusive they end up including nobody. The best example of this is OGC's GML, which attempts to be so inclusive that it allowed everyone to have pretty much their own version of GML so it ended up spawning a host of different GMLs that are incompatible with each other. And, even the best of them is so appallingly inefficient that GML may well go down in history as the least efficient GIS format ever invented (well, short of attempting to code geometry and attributes in braille..).

Far better to pick a dominent, but neutral, commercial vendor and use them. You'll get speed, power, flexibility and assured interoperability because everyone doing interop has to do it one way, their way.

For that reason, I'd advise waiting until (late) April when SP1 comes out and then using Oracle's spatial technology as the central data warehouse about which all of your interoperability revolves. ESRI says they can talk to Oracle spatial and we will talk to Oracle spatial as of SP1. It will never be a finger-pointing exercise between ESRI and Manifold because if you can get the data into Oracle it's up to the GIS vendor to work with it, no excuses allowed.

Plus, as puffed up as we GIS people might get from time to time, let's face it: for most enterprises it makes far more sense to centralize data storage about a DBMS than it does around a GIS.

(begin rant)

One more thing: despite my often repeated negative views on OGC, why does Manifold support so much OGC stuff, from GML to OGC WMS? That's mainly because we think the best way to reveal the core dumbness of OGC is to do a really brilliant, indisputably superior job of implementing OGC stuff and to put it out for many more people to use than ever before at an absurdly low price.

My experience is that most people who gush on about OGC (some GIS analysts, for example) don't have any actual experience with it. I find that once people actually try to *do* anything with OGC, unless it is their job to tinker with never-ending things that don't have to produce actual results, well, then they very rapidly lose enthusiasm for it. There is a cadre of professional OGC "interop demonstrators" who get paid to cobble up one-of-a-kind interop rallies, and those people are quite understandably happy no matter what practical effect OGC has. But in the real world, once someone actually gets hands-on experience with OGC the enthusiasm usually wanes very rapidly as it gets compared to effective alternatives.

Manifold.net had many customers asking for OGC, almost none of whom had actual experience with it. We found that it was cheaper for us to simply implement OGC stuff than it was to argue with people about it. So, fine, we did it and even threw in a bunch of extras, like OGC WMS server capability, and having done it we'll let the chips lie where they fall. If demand appears for things like WFS, well, we'll do that too, no problem.

As it turns out, Manifold's support for various OGC standards has exposed perhaps a thousandfold more people to OGC than ever had access to it before and the chips are not exactly falling heads up for OGC. I think that is why there is much less demand for OGC in inquiries, because as more and more people get practical experience of it, there are fewer and fewer who think it is a great idea. I suppose soon that circle will dwindle down to those who still think Ada will take over all other computer languages and that Microsoft's 94% share of computing markets is proof positive that the world prefers Linux. :-)

(end rant)

Cheers,

Dimitri

mapattack24 post(s)
#03-Mar-06 11:46

Great info (and perspective ;))

I know this isn't an Orcale bbs, but does anybody have a sense of what pricing is once the 4GB max is reached?

jburn

533 post(s)
#03-Mar-06 19:55

Manbe not a sales rep., but there's quite a following down in the niagara areasouth east of you;-)


--------- JBurn

sgreener
87 post(s)
#07-Mar-06 01:58

Graham, You don't mention on what database your ArcSDE geodatabases are built other and a mention of Access. Do you have Enterprise ArcSDE or are you running a personal geodatabase on Access? If an enterprise ArcSDE are you running this on SQLServer or Oracle? To be brutally honest the first place to start wrt GIS and non-GIS client interop is "data level interop" based on an ORDBMS that implements a spatial data type as a standard part of the database product itself. IMHO everything else really doesn't give a bang for the buck and requires API-based interop which programmers and vendors (esp ESRI) love, but which really won't help when trying to integrate geospatial data and services inside non-spatial business applications. To spatially enable a Crystal Reports report - eg find all land parcels affected by a burst water main; all with a certain distance of a facility (whether by drive time or buffer etc) is a snack when the database is Oracle Spatial, PostGIS or Informix IDS + Spatial Data Blade but hell using any other approach. If you are running ArcSDE over an Oracle database then simply grab a shapefile and convert it to your ArcSDE/Oracle database making sure that you tell the shapefile loader to create the oracle table using oracle spatial rather than SDEBINARY format. ArcSDE on Oracle Spatial has been supported since around ArcSDE 8.1.x (though has always been poorly done for all revs up until the last one I tried which was 8.3 - though the documentation for the 9.0 release that I read when I decided at my last employers not to bother upgrading + experience at other sites confirm that not much changed at 9.0 or 9.1.) ArcSDE + Oracle Spatial works but I would recommend not trying to do versioning with ArcSDE when Oracle Spatial is the storage format. It is not Oracle's fault but, let's just say that, the SQL ESRI uses is pretty ugly! S.


SpatialDB Advice and Design, Solutions Architecture and Programming Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, Radius Topology and Studio Specialist. 39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia.

gsmith4 post(s)
#07-Mar-06 06:55

We use SQL Server 2000 as the DBMS for our ArcSDE 'back-end'. My DBA would develop tremors if I asked him to make the switch to Oracle, so that is not an option. However, I have looked in the ArcSDE documentation and it does store geometry in the WKB, which I believe Manifold can read. It would take some SQL to assemble the appropriate table on the client side.

Graham

sgreener
87 post(s)
#08-Mar-06 01:50

Graham,

The old ArcSDE + SQLServer combination!

Can you tell me, via quotes from the documentation, how ArcSDE uses WKB as its internal data storage format? This must be a new development since last I used ArcSDE on SQLServer (it certainly wasn't an option on Oracle at ArcSDE 8.3).

I believe that MapInfo's Spatialware on SQLServer uses an "enhanced" WKB (includes SRID) in the same manner as PostGIS does on Postgres. The nice thing about the Spatialware UDT implementation on SQLServer is that all the spatial capabilities are available to Transact SQL programmers (and hence triggers etc). I hadn't heard that ESRI had gone down this track on SQLServer but perhaps it has since 9.x. Can ArcSDE's WKB in SQLServer be accessed via triggers, native SQL and Transact-SQL such that non-ESRI clients (eg Crystal Report) can use the spatial data and services directly?

regards S.


SpatialDB Advice and Design, Solutions Architecture and Programming Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, Radius Topology and Studio Specialist. 39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia.

jkelly

746 post(s)
#08-Mar-06 17:46

I use spatialware, so all the mapinfo dinosaurs are happy here, but I also use a Manifold IMS off the data, so WKB was the way I went around this. One thing to look out for is that Manifold does not read some elements of WKB. Spatialware can create WKB from its own database format, but Manifold cannot directly read this WKB. The problem is that when you convert the WKB to text, Spatialware puts a GEOMETRYCOLLECTION(polygon(...),polygon(...)) style of the string (for polygons). Manifold uses multipolygon((...),(...)) instead. The stupid thing is that both do the same thing and both are correct under the OGC standards. Manifold does not read the GEOMETRYCOLLETION format, so I have written a trigger that converts the MapInfo WKB into Manifold WKB whenever something is added or altered.

Anyhow, I suppose this is off topic, but just a note to be careful when vendors say they deal in WKB, sometimes it may not be readable by all other vendors.


James K.

http://kelsos.wordpress.com/

gsmith4 post(s)
#17-Mar-06 12:44

In response to your question about WKB and ArcSDE, we use version 9.1 ArcSDE and it has a setting that allows the geometry to be written in the "back-end" feature table in WKB. The WKB switch is not on by default. I turned it on, loaded some data and tested it from Manifold. I was quite pleased when Manifold was able to link directly to the SDE feature table. This is our starting point, now we have a foot in the door to building an interop solution between Manifold and ArcSDE. We have to figure out the "goofy" SQL that ESRI uses to assemble a layer from SDE tables. It is not nearly as elegant as Manifold's approach. But then SDE has versioning, and spatial index, but I doubt it needed to be as complicated as ESRI built it to be!

Graham

sgreener
87 post(s)
#19-Mar-06 15:55

Graham,

This (WKB storage format) is an interesting, and sensible, move by ESRI. I can see why they might be doing this.

Is the WKB the "extended" format with the projection information embedded in it?

Just some questions. Does ESRI still store the EMINX, EMINY, EMAXX, EMAXY (MBR) of the feature in the Fnnn table? If it does, you can build your own attribute indexes on these fields and execute more efficient SQL against these fields using the "BETWEEN n AND m" operator.

With the move to WKB, has ESRI made geo-processing functionality available to Transact-SQL such that one could, for example, Union two WKB features in a trigger? (While off-topic, it is important in trying to work out how to efficiently integrate Manifold with your main enterprise data store.)

As JKelly noted the WKT/WKB mapping from SFS is not straightforward. The handling of multi-part features is problematic. Also, the handling of "curves" is another problem area. There is also cross-standard issues wrt OGC and SQL3 standard. For example the WKT representations of ST_Curve, ST_CompoundCurve, ST_CurvePolygon, ST_MultiCurve etc. These are imported and exported via the SQL3 standard ST_WKTToSQL() and ST_AsText() methods. Some of these, as far as I am aware, are not covered by the OGC standard.

Oracle Spatial is no different here with different WKT being generated depending on the ordering of the elements in the SDO_ELEM_INFO_ARRAY of a SDO_GEOMETRY.

regards S


SpatialDB Advice and Design, Solutions Architecture and Programming Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, Radius Topology and Studio Specialist. 39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia.

1 msec Copyright (C) 2007-2008 Manifold.net. All rights reserved.