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.
- Decision: Do we keep the client application as is, using ASP.NET Web Forms, or do we take the opportunity to upgrade to a Web 2.0 Map tile-based application using Open Layers with Spectrum Spatial Javascript API controls?
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?
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.
- Decision: How do we access coverage layer data sources for point-in-polygon coverage quality query in Spectrum Spatial? How can we access our base map with coverage layers for map rendering at a specified location and zoom?
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.
Automation
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 Spatial throughout an organization.