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.
Tile layers can be added either declaratively or in code.
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:
<!-- 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">
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.
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.
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 (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.
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.
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="http://apps.mapdotnet.com/MDNUXiSDKService/"
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.
<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.
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.