GIS Location Services in Dynamics CRM

A design paper about implementing GIS-based services for a local Council in Dynamics CRM, structuring address data, and delivering location services in the form of WebAPI endpoints via an Enterprise Service Bus.

 

What is GIS

A Geographic Information System (GIS) is a computer system for capturing, storing, checking, and displaying data related to positions on Earth’s surface. GIS can show many different kinds of data on a map, such as streets, buildings, and vegetation. This enables people to more easily see, analyse, and understand patterns and relationships.

GIS can use any information that includes location. The location can be expressed in many different ways, such as latitude and longitude or address. Many different types of information can be compared and contrasted using GIS. The system can include data about people, such as population, income, or education level. It can include information about the land, such as the location of buildings and assets.

 

Location Information in CRM

This experience is about providing location services in the context of a local Council in Melbourne, Australia. The vision of Council is to have a single view of their customers (landlords, tenants and businesses), and have identified the Dynamics CRM platform as the master data source for case management. Information about location of properties and assets is made available in CRM from the GIS system in order to provide location-based services, also via the Council’s web portal.

Location information is structured as follows:

·         Geo-coordinates

Utilised for identifying an exact point on a map, and for GPS applications.

o   Latitude: Specifies the north-south position of a point on the Earth's surface. It is an angle which ranges from 0° at the Equator to 90° at the poles.

o   Longitude: Specifies the east-west position of a point on the Earth's surface. It is an angle which ranges from 0° at the Prime Meridian to +180° eastward and −180° westward.

 

·         Address in Australia

Utilised for identifying a residential or business place, and for postal correspondence.

o   Unit or Apartment number: Optional number of a unit or apartment in a town house or similar.

o   Street name and type: Required.

o   Suburb: Required.

o   Postcode: Required, but it can be resolved by the Suburb name.

o   State: Required, but defaulted to “Victoria” for this purpose.

 

 

Principles of Integration of GIS Data

The following principles apply when dealing with geographical data (not an exhaustive list).

Type	Name	Description
Compliance	Open Geospatial Consortium	The GIS system is OGS-compliant and adheres to the Open Geospatial standards http://www.opengeospatial.org/standards
Compliance	Geo-coordinate format	The CRM system is able to store geo-coordinates in either of the following standard formats: ·         NMEA 0183 (used by most commercial GPS applications) ·         WGS84 (World Geodetic System)
Integration	Geography Markup Language	The CRM system is able to export location information for a specific entity using the GML format http://www.opengeospatial.org/standards/gml
Integration	GeoAPI	The CRM system, or its integration layer, exposes services that provide endpoints for GeoAPI http://www.opengeospatial.org/standards/geoapi

 

For additional information about geo-coordinates, and how to convert from one format to another one, please read my article Converting GIS spatial coordinates.

 

Data Structure

In light of the minimum information to capture for locations, and the compliance and integration requirements, the following data structure is implemented in the CRM and/or the integration layer.

·         Geo-coordinates

Name	Type	Format
Latitude	Decimal	-90.0 to 90.0
Longitude	Decimal	-180.0 to 180.0

 

·         Address

Name	Type	Format
Unit Number	Text(10)	Alphanumeric
Street Address	Text(100)	Alphanumeric
Suburb	Text(100)	Alphanumeric
Post Code	Number(4)	Four digits
State	Text(3)	Fixed to Victoria
Country	Text(30)	Fixed to Australia

 

Dynamics CRM 2015 already contains a standard Address entity that fits the purpose. Latitude and Longitude are available fields, although not assigned to the Address form out of the box. This can be simply done by adding the two fields to a proper section in the form. An address can be associated to a parent entity (owner), and an address type can be specified (e.g. residential, correspondence, etc.). Multiple addresses can be assigned to an owner, with different address types.

Address form in Dynamics CRM with Geo-coordinates

 

Message Flow in the Enterprise Service Bus

The Council has a robust infrastructure with an Enterprise Service Bus based on BizTalk. Besides providing the means for service orchestration, the ESB implements a Publish and Subscribe architecture pattern, by which a message is processed by the adapter and associated pipeline, and is routed to an interested party. A BizTalk orchestration or send port can register its interest in a specific message via subscriptions. The Publish and Subscribe model is an asynchronous programming technique that makes it easier to share information between entities that send information (publishers) and entities that receive information (subscribers).

The Publish-Subscribe pattern in the ESB

 

Location data flows from and to the CRM system via an Enterprise Service Bus. The GIS system represents the application for resolution of location data and geographical representation, whereas CRM is the master data repository of location information for each relevant entity (property, individual, asset).

External applications, such as the Council’s Web Portal, requesting location services, will access the relevant API exposed by the Service Layer. The API provides location information as stored in the CRM (message queueing mechanism may be in place for optimisation of performance). Specific location services, such as visualisation of points on a map, will be delivered by the GIS system, which is informed of such request by the ESB. By implementing the Publish-Subscribe pattern, the GIS system will subscribe to receive updates (“signals”) from the ESB for anything that is related to location. When such a signal is broadcast by the ESB, as a result of a request from the API, the subscribed application (the GIS in this case), will receive the message and provide its services to the requestor.

 

 

Service Layer and API

The Service Layer, implemented as part of the Enterprise Service Bus, exposes several Application Programming Interfaces for consuming location-based services. Examples of services that can be implemented (not a fully comprehensive list at this stage) are:

·         GeoAPI: The GeoAPI defines a set of services that can be used for the manipulation of geographic information structured following the specifications adopted by the Technical Committee 211 of the International Organization for Standardization (ISO) and by the Open Geospatial Consortium (OGC).

·         GeoCoordinates: Geo-coordinate services define transformation between coordinate sets used by the CRM (WGS84 World Geodetic System – data as stored in the CRM) and GPS-based applications (NMEA 0183). This service implements also address geocoding and reverse geocoding.

·         Post Address Lookup: Implements address lookup services based on the Australia Post postcode database, which contains every known postcode, along with state, territory and suburb (locality) information.

·         Location Services: Implements location-based services available to external applications, such as a web portal or mobile apps. This includes proximity, geo-fencing and directions. Information is returned using GML (Geography Markup Language) for cross-platform compatibility.

 

Internal implementation of the API as accessible by the CRM and the GIS systems via the ESB is done using the ASP.NET WebAPI technology, building relevant “controllers” and “models” for each entity.

WebAPI provides an HTTP-based RESTful platform for CRUD operations (Create Read Update Delete) on entities that abstracts from the specific implementation in the source and target systems (CRM and GIS). The public API exposed by the Service Layer, as listed before, consumes the available WebAPI internally for communicating with the relevant system, via the ESB and without accessing the system directly. Messaging queueing may be put in place for optimisation of reliability and response performance and throughput.

 

API Layer Components

 

Australia Post Address Lookup

Australia Post provides an online service available at the URL:

http://auspost.com.au/postcode

This service looks suburbs, towns, cities or postcode up in its internal postcode database, and resolves to a fully qualified address. The postcode database contains every known postcode, along with state, territory and suburb (locality) information. The database is available for sale for business purposes.

 

Address Geocoding

Geocoding is interpolating spatial locations (Latitude and Longitude coordinates) from street addresses. Individual address locations can be interpolated, or estimated, by examining address ranges along a road segment. GIS software approximates where that address belongs along the segment. For example, an address point of 500 will be at the midpoint of a line segment that starts with address 1 and ends with address 1,000. Geocoding can also be applied against actual parcel data, typically from municipal tax maps. In this case, the result of the geocoding will be an actually positioned space as opposed to an interpolated point. This approach is being increasingly used to provide more precise location information.

 

Reverse Geocoding

Reverse geocoding is the process of returning an estimated street address number as it relates to a given coordinate. For example, a user can click on a road centreline theme (thus providing a coordinate) and have information returned that reflects the estimated house number. This house number is interpolated from a range assigned to that road segment. If the user clicks at the midpoint of a segment that starts with address 1 and ends with 100, the returned value will be somewhere near 50. Note that reverse geocoding does not return actual addresses, only estimates of what should be there based on the predetermined range.

 

Location Services

Several location-based services can be exposed to the public (or external applications) based on the location of the requestor (an individual or an application), and the geographical data provided by the CRM. The GIS system can be leveraged for data calculation and transformation, and for displaying such information on maps.

Services exposed by the GIS application, in connection with location data available in the CRM, may be:

·         Proximity: List of businesses, assets and public services in the proximity of a place or an individual, whose location is identified by means of GPS technology.

 

·         Geo-fencing: Restriction of services based on natural or artificial boundaries.

 

·         Directions: Step-by-step indication on how to go from point A to point B on a map, by using different media of transportation, including public services.

 

·         Tracking: Fleet tracking and reporting on utilisation.

 

·         Route optimisation: Optimisation of routes for delivery of services.

 

·         Network planning and design: Optimisation of networks for building works, such as fibre networks, sewage, gas, etc.

 

·         Real estate: Price history, virtual tour, crime rate and other real estate-specific services on streets and neighbourhood.

 

This initial presentation of services gives an overview of the location-based applications that can be implemented having Dynamics CRM and a GIS system at the core of the operations. In a series of future articles, I will present the implementation of most of these services using a combination of different technologies fit for purpose, including a Kentico 9 web portal, Dynamics CRM 2016, BizTalk Server 2013 and ASP.NET WebAPI 2.