Architecture Considerations

This section covers migration decisions about the coverage locator solution architecture.

Client Application

The client portion of the coverage locator solution is an ASP .NET Web forms/Ajax client.

With the upgrade to Open Layers and the Javascript controls you will get a fast map display, navigation and a highly responsive user experience. It integrates with Pitney Bowes StreetPro-based base maps or other base maps such as those from Google and Bing maps. It also takes advantage of Spectrum Spatial’s Map Tiling Service and Map Tiling generator.

For more information on Javascript controls, see Working with the JavaScript API.

For more information on map tiling, see Map Tiling.

API: SOAP or REST for Geospatial Functionality

The coverage locator uses geocoding, point-in-polygon querying and map rendering from the Envinsa .NET API.

  • Decision: Do the Spectrum Spatial SOAP and REST APIs provide the same geospatial capabilities?
Spectrum Spatial has built off the foundational interfaces of MapXtreme Java and Envinsa. In Spectrum Spatial, users have the ability to develop applications against one of three APIs: WS-I compliant SOAP interface; REST interface; and Series of OGC (Open Geospatial Consortium) interfaces including WMS, WMTS, and WFS. Spectrum has the Universal Addressing and Enterprise Geocoding modules for address validation and geocoding. These modules are a superset of Envinsa’s Location Utility Service capabilities. Spectrum Spatial's SOAP API provides robust Mapping and Feature services. The REST API provides a smaller set of operations for mapping and feature searching, plus a map tiling service.

The SOAP API is easiest to implement in a ASP .NET Web forms architecture while the REST API is easiest to implement in the Javascript-based Open Layers with Spectrum Spatial Javascript API.

For more information on Spectrum Spatial's SOAP and REST API, see Working With REST Services.

Data, Data Access and Management

The coverage locator solution uses a base map for geographic reference and custom data for the coverages. In Envinsa the data format is MDF, which must be converted to Spectrum Spatial named resources.

Data access in Spectrum Spatial is similar to that in Envinsa, via a data provider model, but a generation ahead in terms of performance. For example, Spectrum Spatial can push spatial processing to a database with spatial capability to retrieve only records that satisfy the query.

Data management in Spectrum Spatial has built upon the Envinsa Content Manager concept to create the Spectrum Spatial repository. The repository contains named resources that point to actual data. By attaching a name to a data resource, it can be referenced from many locations. To change the look or behavior of applications or data, only the resource needs to be changed, not each application or data file. Spatial Manager has capabilities to create named resources and add them to the repository, as well as manage data connections. User access to these resources is handled by the Spectrum™ Technology Platform Management Console.


The processes for address validation, geocoding and point-in-polygon querying in the Envinsa solution required hand-written code specific to the implementation of the coverage locator.

  • Decision: Can we improve on the workflow and performance of the application's business processes for address validation, geocoding and point-in-polygon querying?

The Spectrum Spatial Enterprise Designer is a drag-and-drop workflow design tool for automating business processes. It can tie address validation, geocoding and point-in-polygon stages together without writing any code and with the ability to publish the process as a web service, a gain in performance over Envinsa and MapXtreme Java. This new capability is new to the MapInfo suite and enables a product paradigm shift for users and analysts that wish to formulate customized uses of Location Intelligence throughout an organization.