Page 1 of 1
arup.dasgupta@GISdevelopment.net  The spatial context is now central to any information system. For example, a telephone user has a number which is also uniquely associated with an address. If the line develops a fault it has to be localised within a route of cables, junction boxes and distribution boxes. All these have a spatial context. The fault could be due to a repair crew, trying to locate a leaking water pipe, snapping a cable unknowingly. We see in this example a need to have a spatial database of the telephone cabling system and the water supply system and a need for the two independent authorities to be able to share their data. With a conventional GIS using graphic elements and a relational database the maintenance crew would have to locate the address from the relational database to its location on the road layer, identify the cable routing, call up the water authority database to see where repair works are scheduled, locate these on the pipeline layer and then do an overlaying, buffering and proximity analysis. We would not see thing happening so easily and then too it would need the services of the GIS division to understand how to set up the analysis. SQL databases provide a much more elegant solution to such problems. Solutions can be found easily by the field operators themselves without having to call upon the services of experts. However, SQL databases were not meant to be used with graphical data. How do you define a road? You may say that it is an array of x and y values but then so is a polygon representing a park. How does the database differentiate a park from a road? Clearly there is a need to define data types for such entities. The Open Geospatial Consortium, OGC has defined a standard for Simple Feature Specification for SQL and there are implementations of graphics representation in SQL databases like Oracle. Katmai is the code name for Microsoft SQL Server 2008. Katmai Spatial offers several new data types specific to spatial data. SQL Server 2008 provides the geography data type for geodetic spatial data, and the geometry data type for planar spatial data. Both are implemented as Microsoft .NET Framework Common Language Runtime (CLR) types, and can be used to store different kinds of geographical elements such as points, lines, and polygons. Both data types provide properties and methods that can be used to perform spatial operations such as calculating distances between locations and finding geographical features that intersect one another. The geography data type operates on a geodetic model like WGS84 and is useful when dealing with geographic coordinates. The geometry data type conforms to the OGS simple feature model and is used for data which is referenced to a map projection with locally assigned coordinates. There does seem to be a bit of confusion here because this geometry is nothing but projected geography. There is some discussion on the need for two separate data types. Operations like the proximity analysis in our example above can be easily done through a few SQL statements. The size of the CLR types has been enhanced to be able to handle large polygons. An adaptive multilevel grid indexing system is included which helps in faster retrieval of data. A question which will arise in a developers mind is how to integrate existing data. Katmai supports GML and Well Known Text and Well Known Binary types as specified by OGC. More than 70 functions and methods will be available for manipulating the data. These mainly conform to the OGC specifications but there are additional features. However, Microsoft feels that channel partners could add more functionalities as the demand arises. Existing users of ESRI products will be pleased to know that they are working closely with Microsoft and plans to support the new spatial type as a standard part of ArcGIS clients via direct connect and ArcGIS Server via the ArcSDE gateway. It is not clear if ultimately the system will provide a complete standalone topologically ordered spatial model or will still depend on a GIS to provide this functionality. The most obvious question that arises in our minds is why it took so many years for Microsoft to come out with such a product. Microsoft has experience with spatial data through TerraServer, MapPoint and Virtual Earth. However, it is only now that they have decided that the technology is more than just 'interesting' and needs to be transformed to a product. The other big question is price. The market will look for a product with a good price/performance ratio, given the fact that there are priced and open source products already available in the market for the last five years or so. All in all Katmai has raised a lot of hopes as well as a lot of questions. Whatever it may be the geospatial world is looking forward to seeing the product in its final form. A lot of interest has been generated and developers will soon have a new tool to examine and incorporate in their resource kit. Page 1 of 1
|