Using Telerik OpenAccess ORM Spatial Data with RadMap for Silverlight

Spatial data is all the rage, everyone wants a map in their application to quickly visualize data.  In a previous blog I showed how you could query, and display, SQL Spatial data on RadMap for WPF using Telerik OpenAccess ORM.  In this blog, I will show you how to display the data on RadMap for Silverlight.  This adds a slight twist because we need to transport the SQL Spatial data across a service boundary, but thanks to some updates in RadMap this is still an easy process; so lets take a look!

Database Setup

The first thing we need is some spatial data. In my previous blog I discussed ways to load a shape file into SQL server.  Also, in the attached code there is a SQL script that will generate the tables, and data, I use in this example.

Building the Model

The next thing I need to do is reverse map the database to create an OpenAccess Domain Model.  If you are new to OpenAccess you can learn how to use reverse mapping by visiting this documentation article, or checking out this video.

Once you have completed the reverse mapping steps the model design surface should look something like this (if you used my supplied script):

I removed a few columns from the locations object, but feel free to leave them if you would like to visualize population change on RadMap :)

 

Now that the model is created I need to get it ready to expose the SqlGeography data through a service.  The SqlGeography type is not serializable, but we can work around this this with no problem!

For each SqlGeography Property in your model:

1. Select the property.

2. In the property grid change the “Access Modifier” to private.

3. Create a partial class for you object.

4. In the partial class will expose the SqlGeography data as a string, by converting it to WellKnownText, you could also expose it is as WellKnownBinary if preferred.

In this case my SqlGeography property is named “Geography”, I then call STAsText() which gives me SqlChars, then I call ToSqlString() to get a SqlString, finally I call .Value to get a .net string.

Once you follow the above steps for each SqlGeography property, you are ready to create the service layer.

Creating the Service

OpenAccess provides the Data Service Wizard, which makes service layer creation extremely easy.  If you have never used the data service wizard a good guide is available here.  For this example I used DataServices V2, and made all of my entities read-only.

Now if you browse to the service you should be able to access the entity collections:

And if you browse to one of the collections, you should see your SqlSpatial data exposed as WellKnownText:

 

Thanks to the Q2 2011 release of RadMap, that long polygon string can be loaded directly to the map using the new RadGeospatialDataReader. Now we are ready to wire the service and our silverlight application together!

Connecting the Service

At this point you will handle querying the service the same as you would for any other service.  I created a simple view model to handle calling the service.  Your code might look similar to this:

Now that I have the view model set up, I need to wire it to the view. In this example I simply did this in the code behind:

With the View Model wired up, the last step is to set up the view. 

First I created a few resources in my mainview.xaml:

Next I add my rad map, map provider, information layer, and the RadGeospatialDataReader:

At the bottom you can also see that I specify some styling for the MapShapes; so that they are visible on the map :)

With the view wired up, we are done writing code, and there is only one more step!

Run the Application

It works! :) The final result looks similar to the WPF example I showed previously, but now we are running in the browser! 

Considerations

In this blog I show one approach to exposing SQL Spatial data through a service, and loading it to RadMap for Silverlight, however; it is not the only approach.  The approach has the limitation that the spatial properties have been marked private, and as such you can not easily offload spatial queries to SQL Server.  If you need to do spatial queries, the best approach would be to keep your OA entities as is, and project them into DTOs that expose the SQL spatial data as WKT/WKB.  This would allow you to easily offload spatial queries to SQL server, and still expose the spatial data through the service layer.

 

I hope this helps you get started using OpenAccess to expose your SQL Spatial Data in upcoming Silverlight projects. In this post, and the WPF version I showed you how to leverage some of the the new spatial capabilities available in OpenAccess.  These spatial types are powered under the covers by a powerful type conversation system the team implemented in Q1 2011.  In an upcoming post I will dig deeper and show you how you can take advantage of this type conversion system, and use it to expose your own User Defined DataTypes.  

Happy Coding!

 

Download Example