mapdotnet.com

Today we released version 8.0.2000 of MapDotNet UX. Even though this is not versioned as a major or minor upgrade, there are some impressive new features in this drop. See the release notes for more information. Three additions worth noting are:

1.       We brought back Oracle support for 32-bit installs using Oracle’s recently released ODP.NET for .Net 4. Oracle has not released a 64 bit connector yet, so it will have to wait until they do.

2.       Dynamic loading of data-source connectors (e.g. if you remove ISC.MapDotnetServer.Core.Data.OracleSpatial.dll, UX Services and Studio continue to function normally – just the data source option is omitted from the list of available options.)

3.       REST map interface (more information here)

In this blog I want to briefly explain what the new REST interface is and why you might use it over our existing WCF (SOAP) and WMS map interfaces. The new REST interface is built on Microsoft’s .Net 4 WCF support – WebHttp Services. In this drop, we have added REST for our map service only. The contract methods are nearly identical to what is provided through our WCF SOAP interface. The REST offering fits nicely between our current SOAP and WMS versions. It is the most performant of the three and takes the middle ground for flexibility. The following chart should help you decide which map interface to use in UX8 for a particular application:

Also included in this release are ITileRequestor REST implementations for WPF and Silverlight RIM (MDNSRestTileRequestor). If you look at Page.xaml for the Silverlight sample, you will see this requestor in use. As far as runtime flexibility is concerned, the WMS service is the least flexible allowing only map size, extent, projection and individual layer visibility changes. The SOAP version is the most flexible but also the slowest. It allows complete control over the map definition at runtime. The REST version provides more flexibility than the WMS and is also the fastest option. It also allows for tile rendering using x,y,z postioning or quad-keys. Neither the SOAP or WMS versions support this.

With the recent release of HeyGov! For San Francisco the MapDotNet product team is excited about how well GIS-in-Azure facilitated some of the more difficult aspects of the solution. One of the key challenges was to provide a seamless interface to San Francisco’s Open311 interface for synchronizing 311 service requests in the customer’s CRM with the spatial store in SQL Azure as well as handling intake from the web. Transformation between view and model, as well as between projections with the customer’s regional data such as “supervisor district” polygons was easily handled. MapDotNet UX’s WPF renderer handles the large feature-sets like property parcels – all within Azure.

You can see this application in action by visiting www.heygov.com.

·         Set the InterlevelQuality property on the RIM MapModel. This controls how quad-tree pyramid tiles are maintained in the model and when to switch them out in the MapView. Values from 0.0 to 1.0 are acceptable and the default is 0.5. As the value approaches zero, tiles at higher levels in the pyramid are used more often between zoom levels (stretching them) and as the value approaches 1.0, tiles lower in the pyramid are used more often between zoom levels (compressing them.) Lower values of InterlevelQuality improve loading and rendering speeds while sacrificing visual quality. Higher values increase the number of tiles loaded and hence lower performance.

·         Set the ExcludeFromBackdrop property on a TileLayer instance. If you are using a tile backdrop (i.e. EnableTileBackdrop is true on the MapView) then tiles remain displayed as you move between zoom levels creating a seamless visual effect as opposed to clearing the screen each time. This is similar to a MultiscaleImage transition effect and you will generally want it turned on. However, you typically only need this on your lowest base TileLayer in your map. For additional TileLayers above the base layer, you should exclude them from the backdrop. So for example, if your base TileLayer is Bing, the ExcludeFromBackdrop property on this layer should be set to false. If you have a MapDotNet UX overlay TileLayer, you will set the ExcludeFromBackdrop property to true. This will greatly reduce the number of tiles requested and cached for the excluded TileLayer.

·         Set the SuspendLoadingDuringZoomAnimations property on a TileLayer instance. Setting this to true will suspend loading any new content while you are changing zoom levels. This can greatly reduce server traffic for tile request. For base maps such as Bing, it is usually preferable to set this false since the tiles are going from MSDN directly to the client and the visual effect is better.

·         Set the ForwardOnlyUnhandledMouseGestures property on the MapController. If true, this will prevent mouse events that are handled internally from propagating up the logical RIM hierarchy thereby reducing event traffic. You must set this false if you need to handle mouse gestures that are also handled internally.

·         Use the MapViewChangeComplete event on the MapView to display changes that might normally be displayed by a mouse move gesture. For example, if you are displaying the current map center in lat/lon, using this event will only update the values once you have stopped panning. If you handle this case with a mouse-move, a lot of extra event handling, processing and UI updating will be incurred.

·         Set the MaxRequestThreads property on a TileLayer instance. This controls the number of simultaneous asynchronous calls to the server for content for that TileLayer (noting you may have multiple TileLayers.) Typical values range from one to eight. For Silverlight, if you have several TileLayers in your map, you may want to limit this number to two or three as you can max out your worker threads. Higher values will put more load on the server but can load maps faster on the client.

·         Use a WMSTileRequestor instead of a MDNSMapTileRequestor to request static map tiles from MapDotNet UX. This is especially helpful if your map definition file is large. However, if you need to customize the returned content on-the-fly (beyond simply turning map layers on or off), then you must use the more versatile MDNSMapTileRequestor.

·         Set the AutoRemoveUnreferencedPyramids property on the MapModel. This is set to false by default. Setting it to true will automatically clear quad-tree cache content as soon as it is no longer referenced by any TileLayer. This will allow the RIM memory manager to clean up resources quicker and more efficiently. However, if in your application a map can be dynamically altered by the user (such as turning map layers on or off) then you may want this to be set to false. If set to true and a user changes appearance of the map on the client and then returns back to a previous state, RIM will have to reload content from the server instead of retrieving it from cache.

·         Store your spatial data in Spherical Mercator (EPSG 3857.) Since the standard visualization projection is 3857, storing your data in this projection will reduce the amount of transforming for map rendering and spatial queries.

·         Limit the number of ISC.MapDotNetServer.Common.Maps.Layers in your map and make sure if you need to dynamically alter them (setting LayerState to Modified) that you restore LayerState to Baseline when no longer needed. When a LayerState is set to modified, the entire Layer object-graph is sent to the server of each tile request. If set to Baseline, only the ID of the Layer is sent.

·         Fine-tune the XAML in your map files for point features. Very complex XAML for point features will balloon the size of your map file and increase the amount of traffic between client and server (especially if you flag the Layer as Modified.)

·         Use an MDNSGeomTileRequestor. If you are overlaying a single spatial layer on a static base map then this may be a great option especially if:

o   The maximum number of features on the client is not large

o   You will often filter the number of records displayed on the client

o   You will often change the symbology or render heat-maps

·         Properly set up your spatial indexes and create multiple spatial indexes for separate regions

·         Use the MapDotNet Line Optimizer (provided in the UX SDK folder) for optimizing line segments for tile-based mapping solutions. This tool supports removing duplicates, splicing, splitting on tile boundaries and line simplification and can greatly improve rendering times for your data

·         Use tile caching for static map tiles – see this article

Author: Brian Hearn, MapDotNet Lead Architect

With the release of MapDotNet UX 8, cloud-based-GIS has become the dominate conversation amongst our customers. Part of the conversation is coming to grips with a new economic model where you no longer have to drop tens-of-thousands of dollars on hardware and GIS server licensing in lieu of much lower pay-as-you go pricing structures. The other part of the conversation revolves around what GIS in the cloud looks like. Essentially it doesn’t look much different than your typical internet-hosted GIS. But with Windows Azure, there are caveats to keep in mind:

1. Applications are encapsulated within the Azure compute units (VMs) requiring new methods of inter-role communication; systems configuration and data storage

2. Components developed for Azure need to take into account the retry paradigm

3. New cost considerations impact application architecture

In this post I want to briefly touch on #3 - architecture and cost. From the diagram below, you see MapDotNet UX Services are a WCF (Windows Communication Foundation) endpoint running as a 64-bit web role in Windows Azure. The services wrap our UX Engine core built on .net 4.0. Using UX Studio to connect to this endpoint, you can extract, transform and load your spatial and attribute data from various sources (shapefiles, KML, local SQL Server instance, etc.) up into SQL Azure. Once there, you design your maps which are rendered in the cloud using our WPF map rendering engine.

 Up until the recent release of SQL Azure with support for spatial data types, MapDotNet UX had to rely on shapefiles and KML stored in Azure blob storage as a means to perform tile-based rendering in the cloud. This worked well, but required larger VM sizes with higher computing costs. The reason: large memory footprints were required in the VMs to cache and spatially index data necessary for high-performance tile rendering.

Now that spatial data types are available in SQL Azure, you can use small VMs for MapDotNet UX and save on compute costs. Typically, the cost savings in compute-units for enterprise or public-facing applications more than offsets the additional cost for SQL Azure. The following performance graph shows the memory footprint of UX running in a small Azure VM. The VM typically starts with about 1.3+ GB. If your data is stored as shapefiles in blob storage, memory resources are quickly consumed for anything but very simple cartography. However, with spatial data stored in SQL Azure, the memory footprint is small. The performance is also typically better using SQL Azure. In many rendering tests we’ve done the query and render times are roughly equivalent. By moving the query processing out to SQL Azure (instead of parsing and reading a shapefile cached in memory on the renderer), you are basically getting another compute unit in SQL Azure.

A single large VM is almost twice as expensive as a small VM with a 10GB SQL Azure database. In conclusion, SQL Azure with support for spatial data types in most cases will be the more performant and cost-effective approach, over shapefiles in blob storage, for high-performance map tile rendering in the cloud.

We released today an update to MapDotNet UX 8. The new release continues to build on our support for Microsoft Windows Azure with support for transactional retries against both blob storage (for shapefiles and KML) and the upcoming SQL Azure Spatial which this version has already been tested against. In the coming days we hope to release a new spatial editing component for WPF and Silverlight similar to the PathElement class in RIM but with far more capabilities including support for very large vertex counts; shape part editing (editing paths in polylines and holes/rings in polygons).

Version 8.0.1000.0

• Services
  • Added retry support for all Azure connectors (blob storage and SQL Azure)
  • Added support for Azure data logging
• Studio
  • Fixed issue with map tile overlapping on edges
• SDK
  • Exposed WCF binding on map and feature service proxies in respective ITileRequestors (so bindings can be changed at runtime)
  • Exposed connection strings in Silverlight map layers for ad hoc layer creation
  • Added HandleWMSStretchLocally flag to WMSTileRequestor to support non-OGC-compliant WMS
  • Added right-mouse support (click and dbl-click) to Silverlight RIM (MapView)
  • Added ContentElementOverlay property to RIM MapView to access and lazy-load IMapViewChild ContentArea
  • Fixed bug in Polygon.Clone
  • Added Envelope.Contains(Envelope)
  • Fixed Engine Sample