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)
Uses (the workflow)
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
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)
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
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:
A Submitted Form:
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.