Using the SqlGeography type when working with SQL Server 2008 spatial features

SQL Server 2008 comes packaged with some .NET types like SqlGeography to help development for the new built-in spatial features. It contains real useful functions to convert the geography to GML or WKT and back. This type can be found in the “Microsoft.SqlServer.Types.dll” assembly that will be installed only with SQL Server 2008 and not with the .NET 3.5 framework itself. So, if you are writing a client application that will run on machines that do not have SQL Server 2008 installed, this DLL needs to be copied to client machine manually. On the server machine, the assembly is installed into the GAC but the “Add reference” dialog in Visual Studio 2008 does not pick it up.

So, right now, references should be added to the assembly manually. This assembly can be found in the Binn directory (on CTP6) or 100\SDK\Assemblies (in RTM).

There is a new MSI coming that will install these new system CLR types. This will be part of a “Feature Pack” and will be redistributable outside the server.

Advertisement

Customizing the response serialization in WCF REST services

I am in the process of creating WCF REST services for one of the projects I am currently working on. I love the REST programming model introduced in .NET 3.5 and how simple it makes things. But I also think that the REST programming model in .NET 3.5 is not as good as it can be and there will be more “RESTful goodness” coming in the later service packs and releases. The DataContract serialization has already been improved upon in SP1. DataContract has made the serialization in .NET better in a lot of ways but I like the opt-in mechanism in DataContract serialization instead of the opt-out mechanism like in the XmlSerializer.

The extensibility of WCF is amazing and sometimes overwhelming. There are multiple ways by which you can customize the request and response serialization in WCF. The XmlSerializer helps you take complete control over the XML format in which the response is serialized. And there are a lot of documentation on the web that show you how it can be done. But I was looking to return GeoJSON generated by the GeoJSON.NET library from the WCF REST service. The GeoJSON.NET library uses the NetTopologySuite(NTS) library to create GeoJSON from. Even though, the DataContract serialization is highly customizable, I had two problems, I did not have control over the NTS geometry and feature types(to decorate them with the DataContract attributes) and also the flexibility of the DataContract serializer might still not be good enough to generate the GeoJSON format required from the NTS types. Generating GeoJSON string from the GeoJSON.NET library and returning the string from the WCF REST service still had a problem. The GeoJSON output was getting wrapped in quotes and that is not a good thing. After, spending some time evaluating the options available to customize the JSON response from the WCF REST, I found that there are a lot of options for customizing the XML serialization and not as much for JSON serialization. Finally, I settled on returning a Stream from the WCF REST service which will give me complete control over the response from the WCF REST service. When returning a Stream, WCF stays clear of the response and doesn’t mess with the response by applying any default serialization. This way I can return exactly what I want to from the REST service.

Here is how to return the string response in a “raw” stream format.

public Stream GetJSON()

        {

            Byte[] data = Encoding.UTF8.GetBytes(“{hey: ‘there’, hello: ‘world’}”);

            MemoryStream ms = new MemoryStream(data);

            return ms;

        }

or

public Stream GetJSON()

        {

            WebOperationContext.Current.OutgoingResponse.ContentType = “text/json”;

            MemoryStream ms = new MemoryStream();

            StreamWriter sw = new StreamWriter(ms);

            sw.Write(“{hey: ‘there’, hello: ‘world’}”);

            sw.Flush();

            ms.Position = 0;

            return ms;

        }

Make sure to set to position on the stream to ZERO before returning. If you don’t, the response is always going to be empty. That finally dawned on me after numerous hours of my banging my head against the wall.

Also, setting the ‘ContentType” on the outgoing response is not a requirement but it is a good RESTful practice. Here is a good look-up for setting the content type in case you are returning other kinds of data.

ESRI’s Generalize function / MS SQL Server 2008’s Reduce function

We were trying to load some watershed polygon data into VirtualEarth but the number of vertices on those polygons was large enough to affect the performance of the map. Since, the data was being used to pull up documents for each watershed and not for getting accurate map data, we decided to generalize or reduce the vertices on the watershed polygons by an acceptable distance factor and limit the scale on the map to not let the user view the data at low scales. We knew that ESRI’s Generalize(…) function on IPath did exactly that and takes a tolerance. It does so using the “Douglas-Peucker algorithm“, although ESRI’s documentation calls it “Douglas-Poiker algorithm”. But when I was tooling around MS SQL Server 2008, I found the Reduce(…) function in it does the same. This made me curious to see if Microsoft and ESRI’s versions of the algorithm performed the same. And they do… Both of the functions reduced the number of vertices on one of watersheds polygon from 14245 to 450 when using a tolerance of 30 meters.

Thinking about JSON… Schema definition for JSON? RESTful presentation & transformation services for JSON?

Since I have been working with JSON, I have had a lot of ideas and questions regarding its use, validation and presentation. JSON is overwhelmingly being preferred over XML these days for most applications since most of them are web-based. Given its quick acceptance for various applications, do we need other supporting standards and technologies for JSON like XML’s XSD and XSLT technologies. When I was pouring over the GeoJSON standard when working on the GeoJSON.NET library, I couldn’t help but wonder if the GeoJSON standard should be expressed in a schema definition language for JSON like the XSD for XML. I don’t believe validating JSON data against such a schema definition would be practical right now, given that the validation will be processor and memory intensive and may not be a great idea on the client-side browsers. I did find Kwalify and Cerny which seem to take a stab at it. It will be interesting to see whether such technologies will develop further.

Another interesting area that is slowly progressing with JSON is technologies to convert JSON data into a user presentable format i.e. a XSLT like technology to convert JSON data to HTML. Some of my thoughts and performance metrics on some examples can be found here. Given that transforming large JSON data into HTML using JavaScript may not be as fast as required on the client-side, I believe this and other reasons will open up server-side RESTful services that do the job of transforming JSON into a user presentable format. To perform the transformation on the server-side, the amount of data being transformed should be substantially big. These RESTful JSON presentation services could look like the following

http://www.XXX.com/Presentation/?outputFormat=[HTML]&jsonDATA=[jsonURL]

In the above URL, the ‘[jsonURL]’ represents the URL that GETs the JSON data and ‘[HTML]’ tells the service the format to which the JSON data needs to be transformed to. I don’t think this kind of RESTful presentation services for data is anything new. There are similar services available right now even for GIS but not exactly JSON data. The service I am referring to is one of VirtualEarth’s services to view KML data(not GeoJSON, but hopefully that is coming soon). It should be a breeze to build a similar service for GeoJSON using OpenLayers since it can consume GeoJSON data directly as a layer. One example of an OpenLayers app consuming GeoJSON data can be found here. The GeoJSON data is obtained from here, which is a FeatureCollection of the boundary data for all countries.

Anyway, both these services take data in one format (KML and GeoJSON) and present it on a map.

URL FORMAT http://maps.live.com/?mapurl=[insert url here]

http://maps.live.com/?mapurl=http://dsc.discovery.com/utilities/googleearth/nationalparks/nationalparks.kml

GeoJSON.NET – A .NET library to produce GeoJSON output

I have been working on a .NET library to produce GeoJSON output from GIS data. To have the GeoJSON serialization and rehydration be independent of any paid software, I decided to build the framework to produce the GeoJSON output from the geometry types in the NetTopologySuite open source library. Also, for the JSON serialization in .NET, I am using the JayRock open source library. Although, I had to make a little change to the JayRock build script to have the assemblies be strongly named.

The library for the GeoJSON serialization is also open source and can be found here (at Assembla, which I love by the way). The library has also been unit tested using the MbUnit framework.