MapDotNet UX Help

For Silverlight and WPF there are four approaches to adding a TileLayer consuming content from the MapDotNet UX Web Services. One is to use a bitmap tile requestors (e.g. MDNSMapTileRequestor) and another is a geometry tile requestor (e.g. MDNSGeomTileRequestor.)  A final option is to retrieve maps though the WMS service interface. There is also a REST interface covered elsewhere.

Bitmap Tile Rendering using MapDotNet UX Map Services

Tile layers can be added either declaratively or in code.

Adding a MapDotNet UX Bitmap Tile Layer Declaratively

You must first declare the map itself.  The map declaration should include the address of the MapDotNet UX Web Service instance used.  You must also set the Map.TileProjection property and Map.MapModel properties.  Your tile layers will be nested within the map model.

Namespace declarations for Silverlight:


Namespace declarations for WPF:


Control markup:

<rim:Map MDNSAddress="">

        <Projections:SphericalMercatorTileProjection />


     	<!-- Tile layers go here. -->



See Using the RIM Control for more about the map declaration.

The declaration for any tile layer includes a Descriptor and a Requestor.  The Requestor for a MapDotNet UX bitmap tile layer is an instance of the MDNSMapTileRequestor class.  The Descriptor should be the map ID.  During map initialization a MapRequest will be created from this map ID and will become the descriptor.

The TileLayer can be assigned a Name to reference it in the code-behind.

<rim:TileLayer x:Name="MDNSTileLayer" Descriptor="SampleWithBaseMap">
        <Requestors:MDNSMapTileRequestor />

An attribute that can be provided for an MDNSMapTileRequestor is EndpointAddress.  Use this to access a different MapDotNet UX Web Service from the one specified by the Map's MDNSAddress property.

See the tile layer documentation for a discussion of additional tile layer properties.

The declarative approach is the preferred way to add tile layers.

Adding a MapDotNet UX Bitmap Tile Layer in Code

The first step to adding a bitmap tile layer to your map from a MapDotNet UX Web Service is to create the TileLayer from an MDNSMapTileRequestor instance.

var tileReq = new MDNSMapTileRequestor();
var myMDNSTileLayer = new TileLayer("myTileLayerID", tileReq);

Then add the TileLayer to your map.

myMap.MapController.AddTileLayer(myMDNSTileLayer );

When the RIM control is populating tiles for display in the above example, the TileLayer instance will provide information for requests to the MapDotNet UX Web Service (map service) for specific tiles based on a map ID, location and stylization according to myMDNSTileLayer.Descriptor. The Descriptor for a MDNSMapTileRequestor must be an instance of ISC.MapDotNetServer.Common.Maps.MapRequest. A MapRequest is basically the map definition (ISC.MapDotNetServer.Common.Maps.Map - i.e. what MapDotNet UX Studio creates) plus extents, image type and any changes to symbology you want to impose over your initial design. See the map model overview here.

You have two ways to create a MapRequest - either from scratch by building the object graph or by retrieving a baseline copy from the MapService on the server. A baseline copy is the map you defined in Studio and saved via the MapDotNet UX Web Services (admin service) to the UX repository of maps. If you want to change the visibility of layers or how they are rendered, you can start with a baseline and edit the object-graph. Keep in mind your map images from the server may contain more than one spatial data layer that will be displayed within your TileLayer. Also, when you create the MapRequest, you do not need to set the extents, the MDNSMapTileRequestor will do this automatically depending on the desired tile being displayed.

The diagram below is a high-level depiction of how content is retrieved and displayed.


Geometry Tile Rendering using MapDotNet UX Map ServicesGeometry Tile Rendering using MapDotNet UX Map Services

Geometry tile rendering (GTR) is a new way to visualize spatial data in a distributed environment. The basic idea is to retrieve geometry as vector data and then render that data (on-the-fly) within the RIM client as needed. Geometry data is retrieved as collections of vectors that intersect rectangular tile extents. This means that the same vectors may be stored in multiple tiles in cases where they intersect more than one.


  1. At extents where the cartographic aesthetics are sound (i.e. the rendering at said extents allows for the viewer to discern individual features and the density of those features is not too great) the GTR download times from the server are comparable to retrieving a rendered bitmap. When the map scale is below this threshold, the download times may even be less. This is especially true for point data.
  2. Once vector data is downloaded from the server for a particular quad-tile, it is available for all children quad-tiles at lower zoom levels requiring no further round trips to the server for those regions.
  3. GTR on the RIM client allows for dynamic stylization of data. For example, re-rendering a new set of class breaks based on new criteria entered by the user can be displayed quickly
  4. GTR on the RIM client distributes processing load and greatly reduces the demand on server resources for a given client load.


  1. Under certain circumstances the download times may be greater than a bitmap approach. This is especially the case where layers are rendered at map scales where density is high and features merge visually. It is also more likely with features covering large geographic areas such that they are duplicated across multiple tiles.
  2. A GTR TileLayer always corresponds to a single data layer. For a bitmap TileLayer with lots of data layers it quickly becomes impractical to convert each data layer in the single bitmap TileLayer into multiple geometry TileLayers. The better approach would be to keep your static data as a bitmap TileLayer and add a small number of dynamic geometry TileLayers (typically less than 5)
  3. The GTR approach is more complicated from a developer standpoint.

Steps to Implement a Geometry TileLayer

Geometry tile layers require a renderer- ITileRenderer implementation- to render vector data on the client  The renderer is assigned to the TileRenderer property of the TileLayer.  Implement a renderer as follows.

  1. Create a custom tile renderer which implements ITileRenderer. For a given quad-tile containing vector geometry, when it is presented via an ITilePresenter, it checks the TileLayer to see if it has a custom ITileRenderer and if so uses it to render the encoded content of the quad-tile into decoded content ready for display.
    1. You must override the ClassificationPreRender method which returns a List<ITileRenderInfo> instances.
    2. You must also override the Render method which returns an object suitable for display (such as a bitmap)
  2. The simple way to go about implementing ITileRenderer is to extend a class provided in the RIM SDK that already implements it and only requires overriding the ClassificationPreRender method. There are classes in the Rendernamespace for WPF and Silverlight to do this such as:
    1. PathToBitmapRenderer - renders vector polylines and polygons to a bitmap
    2. PointToBitmapRenderer - renders points to a bitmap based on a supplied XAML point symbol
    3. MarkerRenderer (WPF only) - renders markers as Visuals
    4. PathRenderer (Silverlight only) - renders polylines and polygons to UIElement vectors.  This is not as performant as the bitmap renderers.
  3. When overriding ClassificationPreRender you add an ITileRenderInfo instance to the List<> returned for each vector record in the quad-tile result-set. There are concrete ITileRenderInfo classes in the RIM SDK associated with each concrete renderer listed above

Adding your geometry tile layer declaratively

See above for the basic structure of the map declaration.  If your map will not also include a bitmap tile layer, set the initial position on your map control.

<rim:Map x:Name="myMap" MDNSAddress="" 

The following shows the markup for a geometry tile layer using a custom renderer defined in your application source code.  As above, the TileLayer Descriptor is the map ID, used to build a MDNSGeomTileRequestDescriptor during map initialization.  The MDNSGeomTileRequestor targets an individual map layer specified by its LayerID property.

<rim:TileLayer x:Name="GeomTileLayer" 
        <Requestors:MDNSGeomTileRequestor LayerID="Parcels" />

    <!-- Geometry requestors require an associated renderer -->
        <!-- CustomPathRenderer extends PathRenderer -->
        <src:CustomPathRenderer MinRange="1000" MaxRange="1000000" Threshold="400000" QueryColumn="APPRVALUE">
                <Renderers:PathRenderInfo Outline="Blue" OutlineThickness="1"  Fill="#300000FF" />
                <Renderers:PathRenderInfo Outline="Red" OutlineThickness="1"  Fill="#30FF0000" />

Note the use of some additional TileLayer attributes.

ExcludeFromBackdrop - all but your base map should generally set this true.

FadeInDuration - provides a pleasing fade-in effect as tiles are loaded.

MinZoomLevel - layer not used at lower zoom levels.

TilePresenterRefreshDelay - useful to avoid blocking the UI thread when refreshes are tied to events on UI elements that themselves must update UI frequently.  This example was taken from the client-side rendering sample in our Interactive SDK, where the tile layer is refreshed as a Slider control is moved.

Adding your geometry tile layer in code

  1. Create a new MDNSGeomTileRequestor and set its EndpointAddress to a MDN UX Web Service (no need to include the .svc page part of the reference)
  2. Create a new TileLayerusing the new MDNSGeomTileRequestor
    1. Set the MinZoomLevel you above which rendering ceases for this TileLayer
    2. Set the Opacity property to your desired opacity
    3. Set the Descriptor property with an instance returned from calling yourMDNSGeomTileRequestor.BuildDescriptor(...) - this takes the map and layer IDs and the output projection which is available on your RIM Map instance. It also takes a max number of features to render per tile limit.
  3. Instantiate your custom ITileRenderer and assign it yourTileLayer.TileRenderer property
  4. On your TileLayer set the ExcludeFromBackdrop to true - generally you should do this as quad-tiles rendered fro GTR are more resource hungry than bitmap tiles and it is better to not keep them around for a backdrop (typically geometry tiles are not base layer tiles anyway and are not good candidates for a backdrop)
  5. Add your TileLayer to your map - e.g. myMap.MapController.AddTileLayer(myGeomTileLayer);

Using a WMS layer

A WMS layer retrieves bitmaps, but it does it through a WMS service rather than through WCF web services.  Typically, a WMS layer is used to retrieve third-party maps, but MapDotNet UX also provides a WMS interface, so MapDotNet maps can be retrieved in this way also.

WMS uses HTTP GET requests, which are faster than the WCF requests used by the above two mechanisms because WCF is based on SOAP and has additional processing overhead.  On the other hand, WMS requests give you a lot less control over how maps are rendered.  The following chart gives some suggestions as to when a WMS layer might be the preferred choice.


Creating WMS layers is discussed here.