Skip to main content

map-525349_1280.png

There have been many occasions where I have mentioned how one could take geolocation (GPS) metadata, usually collected from a Nintex Form, and use that to find a physical address.  So, hot on the heels of a great blog post (Latitude and Longitude UDA from a clever fellow named Vadim Tabakman), I decided to put some of my thoughts down in a more concrete way by conjuring up this post and sharing with you all some pre-built workflow logic that will allow you to perform this kind of reverse geolocation lookup with Nintex Workflow without having to build it yourself!

 

But first, let's go over some use cases for this kind of data. Then, a brief explanation of how to build this and, lastly, links to download the workflow, form and UDA samples.

 

Geolocation Metadata Adds Context to your Data

 

Here are just some of the possible use cases for this type of functionality:

 

Collection (the form)

  • Incidents (safety, remediation, compliance, etc.)
  • Customer service improvement (Know where and when your field team has been at a specific place)
  • Competitive edge (price comparisons, site scouting, etc.)
  • Increase operational efficiency (is your team actually visiting a location, are they making the best use of their time, etc.)
  • Offline via Nintex Mobile (from remote locales where Internet connectivity is not available)

 

Uses (the workflow)

  • Dispatching (Send your field team to a location to perform a task such as repairs, safety inspections, remediation, etc.)
  • Customer service (Understand where your customers are or where your problems are and take action)
  • Further analysis (feed GIS or data mining systems to extract even more value and gain insights into this data)

 

Prerequisites

In order to resolve the geolocation coordinates to a physical address you will need to query the Google Geolocation API.  Therefore, you need to visit the Google API site, sign in with your Google ID and apply for an app API key. Once you have that, make sure you enable the Geocoding API access in the API Console. Then, create a Nintex Workflow Constant and store that API key, so that you can use in your workflows without having to type it in each time.

 

Please keep in mind that there may be costs involved with using this API in a commercial / production environment so please consult the API terms and conditions. Also, this solution could be replicated with another geolocation API, such as the Bing Maps API so feel free to experiment!

 

 

Collecting Data from a Form

 

2015-01-13_11-31-12.jpg

 

I built this workflow on top of a simple OHS (Occupational Health and Safety) Incident Report form that I already had. The metadata is saved against a SharePoint list with several text columns.  For testing I submitted the form via the Nintex Mobile App (pictured above) running on an iPad (You could also use a browser based version of the form as the geolocation control is vailable on those layouts as well) and included a picture from the corresponding location.

 

The User Defined Action (UDA)

 

2015-01-13_11-03-56.jpg

 

UDA Parameters:

Input:  Geolocation Point Data (Text)

Output:  Physical Address Data (Text)

 

How the sausage is made:

Inside of the UDA, we will take the coordinate data captured on the form and format it correctly for API submission by using the Regular Expression action (read more about the RegEx action!). This invovles reversing the latitude and longitude (as the Google geolocation API requires the longitude first), splitting the latitude and longitude into two discreet entities, then storing them into seperate variables. After that, we reassemble the coordiantes and format them. Lastly, we query the Google geolocation API using a Web Request action and then parse the response with a Query XML action to isolate the "formatted_address" entity.

 

The List Workflow

 

2015-01-13_11-06-52.jpg

 

This is the easiest part... well after filling out the form of course! Simply create a new list workflow and add the UDA (Resolve Geo Point to Physical Address) and an Update Item action, which will allow the physical address to be added to the Physical Address column of the current item.

 

The Final Product and Conclusions

 

The List View:

 

2015-01-13_11-34-52.jpg

 

A Submitted Form:

2015-01-13_11-35-40.jpg

The practical applications of this functionality are almost limitless. I encourage you to download the sample items (Browser and Nintex Mobile Ready Form, the UDA and the list workflow). Oh and I spent maybe an hour or so on building this. It took longer to write this blog post! happy.png

 

The Goods

 

Attached below!

Great post Brad!!!


Nice!


This is awesome stuff.  Keep the fresh scenarios coming!


This is excellent!


I love this kind of stuff. I've been writing and talking about mapping in SharePoint for years. Always great to see new ways to do it. Customers love it.


Will this work in Nintex 2010?


Hi Donald,

I built it in 2013 but there aren't any features that would preclude it from working in 2010. Since my "go to" test environment is 2013 it may be easier for you to go ahead and give it a shot and let us know if you run into any issues.

Best,

Brad


For some reason the final txtPhysicalAdd is not writing to the physical address field. The workflow runs and completes. 


Reply