Some of Paul’s comments has been contradicted by the ESRI SDE developers at the ESRI UC this summer… though, I still think many his concerns are still warranted. They stated they would support the built-in PostGIS implementation and also provide ESRI implementation–not sure if it will be ST_GEOMETRY or SDEBINARY. In either case, it’ll be your choice to use the PostGIS or ESRI implementation.

One point that Paul fails to consider is with Oracle Spatial is that it is broken. Why should ESRI or anyone else embrace a failing technology? Oracle Spatial queries require the use of optimizer hints because of a half-finished implementation… The query planner/cost estimator produces results that are not only wrong–but will also flat out lie to you. They have multiple versions of the same query–some optimized to use the spatial index, others not (why?!). Spatial joins often force you to materialize intermediate tables or force you to use non-optimized spatial functions. Simple spatial queries cause multiple table hits… It can perform well, but only under very contrived circumstances or with the time/expense of an Oracle guru.

Sounds like a smart move to offer an alternative.

I have not tried PostGIS myself so I don’t know how well implemented it is. The comments I’ve heard from a few coworkers who use it have painted an ugly picture–particuarly with how you are forced to use the spatial indices. But that may be because they come from an Oracle background–their motto? If it’s not Oracle, it’s evil.

Yes, it would be great to have PostGIS support in ArcSDE 9.3. But to be honest, I doubt it. ESRI could do the same thing as with Oracle and create their own spatial datatype in PostgreSQL, ignoring PostGIS.

And if they would offer a direct connect to PostGIS (skipping some ESRI functionality) is also doubtful. See also http://geotips.blogspot.com/2006/12/postgis-for-sde.html

Fortunately there are some third party vendors out there who recognized a similar shortfall with ArcIMS and have developed applications to configure, deploy, and manage robust web based GIS applications with minimal effort and are applying the same business model to ArcServer. These products remove the prohibitive costs associated with leveraging ArcServer’s capabilities via software development with a suite of tools that allow the shop to configure and publish a client application out of the box, tailored to the specific business requirements of the client. It could be argued that ESRI’s business partners will be the saving grace of ArcServer.

In the interest of full disclosure our shop is a consumer of Latitude Geographic’s product line. While we believe their products and services are best of breed it was the strategic business angle that their and other third party vendors provided that got our attention. We now have the capability to provide a wide area of GIS services that leverage our investment in the existing enterprise infrastructure for a fraction of the costs associated with internal or contracted custom software production. That said we’re very interested to see where they take ArcServer with this business model.

You can’t actually get an ArcIMS application up and running here, it just requires more resources than are available. We ended up developing our own system using MapServer as an engine and it works even on dialup. I understand why all the big companies are going for enterprise solutions, makes sense, that’s where the big money is. But we reckon there’s a lot of people it isn’t appropriate for so are looking for them as a market. Different strokes for different folks.

Check out our Cambodia Atlas site built using our software (Mango Map, http://www.mangomap.com), http://www.cambodiaatlas.com/mapIndex.html – would appreciate feedback.

Cheers from Cambodia and Lao PDR

Since we all know that AGS is a huge resource hog, and you have to license each and every machine that has _any_ portion of their software stack on it, it would be cost prohibitive to get into AGS as an ASP.
There would be very few ways to streamline the backend so the pricing model would be really complex. While tile caches help, I don’t think you can connect to the tile cache unless you go through the ADF backend, so there is still a pricy license in the mix there. Maybe we’ll see some movement on direct HTTP GET access to the tile cache with the Javascript client, or maybe someone else will write a TileCache Rest service that can read an ESRI tile cache directly (getting rid of the pesky and costly ADF.
What we may see are ASP’s which will host a replica of your data (synchronized via SDE replication) in PostGIS, and then have GeoServer + Cache + OpenLayers in front of that. This could be a viable business model because the expensive licensing point is on ArcSDE, and that actually scales quite well. You could then have a specific “menu” of AGS services that you could apply to one of these sites – which would allow you (as the vendor) to constrain the load, thus making the AGS licensing manageable.

Cheers,

Dave

ESRI began as, and always has been, a software services company. Further, looking after the bottom line and looking out for users is not, and cannot be, mutually exclusive for a successful company in the long run.

But I have to agree with Dave (comment 21): When there is PostGIS support for ArcSDE, you can manage your data with ArcGIS desktop on a free DBMS. And on the same dataset, it is very easy to implement an “identify service” by wrapping a simple SQL query in a web request. No need for any licensed product AND you have lots of external hosting services which support PostgreSQL.

Is there anyone providing AGS hosting – will there ever be external AGS hosting?

Cheers,

Dave
(posted from Vancouver BC)