Wednesday, December 12, 2007 12:19 PM
Whether is Microsoft have some solutions which works with Katmai spatial data for:
- loading/editing feature layers like ESRI ArcGIS products (ArcCatalog)
- publishing spatial feature layers on the web like ESRI ArcIMS did
Currently we use ArcSDE/ArcIMS for publishing our data (map) on the web.
Whether is reasonable to move on to Katmai - integrated SQL expressions for working with spatial data types
is very useful feature I believe. But what about other issues? Whether its mean that I will need to develop
all the elements - which already exists in ERSI products line - by myself?
Friday, December 14, 2007 7:32 PMIf you want full GIS capability you can do all that today with Manifold. If all you need is the ability to interchange data from many formats into and out of SQL Server 2008 spatial storage you can use FME, which has (as always) truly expert support for SQL Server 2008.
Manifold has supported SQL Server 2008 spatial capabilities with full GIS capabilities since August (using early pre-releases) and has, of course supported the latest CTP issued in late November that provides spatial capabilities. See
We have a lot of experience with direct support for spatial DBMS using the spatial DBMS vendor's own native standards. Manifold since late 2005 has supported Oracle Spatial directly (OCI and native SDO_GEOMETRY and GEORASTERS) and in 2007 added DB2 with IBM Spatial Extender as well as PostgreSQL/PostGIS. Manifold also provides spatial DBMS capability for just about any DBMS as well as a super-fast Spatial Extender for SQL Server 2005. We've used all that experience to make our direct support for SQL Server 2008 the best ever.
In addition to direct support for SQL Server 2008 GEOMETRY and GEOGRAPHY, Manifold also enables storage of images and surfaces within SQL Server 2008.
Functionality is everything you see in the entire Manifold user manual (http://www.manifold.net/doc/manifold.htm) so there is an immense number of features both on the desktop and in the web server. For example, because the IMS capability built into Manifold provides HTTP, WMS, WFS-T and tiled image servers you get all that for SQL Server 2008 spatial data as well.
There are, however, some specific topics of special relevance to SQL Server 2008 users:
http://www.manifold.net/doc/esri_geodatabases.htm (Manifold reads/writes/edits SDE geodatabases, so this is a way of exchanging data from your current SDE infrastructure into SQL Server 2008)
By the way, I'd respectfully disagree with your statement "all the elements - which already exists in ERSI products line" because ESRI's product line does not include many required elements: they don't have direct connections to spatial DBMS and they don't have 64-bit code to name just two.
As far as I know, ESRI's products such as ArcView or ArcInfo have never supported direct, native spatial DBMS. Instead, they try to convert the spatial DBMS vendor's standards into proprietary ESRI connections that require ESRI's SDE middleware. I realize there was value to proprietary systems like SDE before the DBMS vendors evolved their own spatial DBMS standards, but now it is more important to use the DBMS vendor's own spatial DBMS technology.
The whole point of using mainstream spatial DBMS like SQL Server 2008 or Oracle is to benefit from an ecosystem surrounding your DBMS vendor, so you can choose from hundreds of applications that can all interact directly with that DBMS. Get locked into some GIS vendor's standards instead of using the DBMS vendor's standards and you cut yourself off from that ecosystem while becoming dependent upont a single GIS vendor. So we think it is critically important to work directly with the spatial DBMS's native technology without any GIS vendor proprietarizations (which is what Manifold does).
While ESRI has announced that future versions of its software will have some connectivity to SQL Server 2008, they have also said this will not be a direct connection and will require SDE. It's hard to tell what exactly this will end up being (always the case until an announcement materializes as a real product) but if SDE is required this does not seem like it is going to be a direct connection to SQL Server 2008 using unmodified SQL Server 2008 native types such as GEOMETRY and GEOGRAPHY. We think a lack of a direct connection and failure to use unmodified SQL Server 2008 standards would be a big mistake.
By the way, getting locked into some GIS vendor's middleware instead of having direct, native access to the spatial DBMS loses a lot of other benefits besides impeding interoperability with hundreds of other applications: it also places you at the mercy of your GIS middleware vendor's pricing (you have to pay what they tell you to pay, because you are locked into their products) and it also places you at the mercy of their development plans. If they get lazy and fail to modernize, you suffer.
A good example of this is how ArcGIS, ArcSDE and ArcIMS don't have native 64-bit software, they don't utilize multicore processors and they don't support Vista. This is a particularly big impact upon web applications for DBMS, because by far the simplest, least cost and most effective way to get more bandwidth in your web server is to run 64-bit applications within 64-bit Windows using a multicore processor machine loaded up with lots of dirt-cheap RAM.
So far in GIS in general and for SQL Server 2008 GIS specifically, only Manifold provides native, 64-bit software for 64-bit Windows together with full, guaranteed Windows Vista support and multi-threaded utilization of multicore processors when linking to a spatial DBMS. We think that if you are using a state-of-the-art spatial DBMS like SQL Server 2008 you probably don't want to have to pretend that your fabulous, quad-core 64-bit server running fabulous 64-bit SQL Server is some 32-bit, single core relic of the 1990's. :-)
By the way, depending on what you are doing you might not even need GIS at all. It's extremely easy to hookup SQL Server 2008 with other modern technologies like Microsoft's Virtual Earth or, on the desktop, Microsoft's MapPoint. There are many such tools in play that are quickly and easily connected with SQL Server 2008 to provide a wide variety of visual interfaces to data within SQL Server 2008. Between those and the presence of GIS folks like FME and Manifold moving instantly to support SQL Server 2008 already there is no lack of tools people can use.
Sunday, December 16, 2007 7:44 PMModerator
Some people don't like my line, but I'll say it again: just because we're adding spatial data support in SQL Server doesn't mean that SQL Server is a GIS. While we think that our spatial types will improve the story for applications that utilize spatial data in SQL Server, we do not view this support as supplanting these applications, nor is that our ultimate goal.
For some applications, I can imagine people making use of our spatial support directly without any additional software. That said, unless they have significant resources to spend building it out, I suspect most people with serious GIS applications will continue to find real value in the additional services our partners provide.
This is a typical story for us, and could be reworked for many application domains. E.g., we provide all the storage primitives needed to develop a document management system---especially with the arrival of Filestream---but we don't claim to be a document management system either. This is the nature of a platform.