Adding Geolocation Columns to SharePoint Lists
One of the cool things that came along in SharePoint 2013 was Geolocation fields in lists. Using Geolocation fields, we can display Map Views in SharePoint lists. This capability is an awesome way to add visualization to your UI and can really add value in many business processes.
Think about it. You could show:
- A map of your customers in a region
- A map of your office’s location on its Intranet page
- Deliveries you’ve made in the last 30 days
- etc.
Unfortunately, at the present time in SharePoint 2013 on premises and SharePoint Online (Office365), “The Geolocation column is not available by default in SharePoint lists. To add the column to a SharePoint list, you have to write code.” (See How to: Add a Geolocation column to a list programmatically in SharePoint 2013)
For whatever reason, there’s no way to add a new Geolocation field via the UI. Instead you have to go through some hoops with PowerShell or script. See the following articles for great tutelage on how to do this:
- SP 2013: Getting started with the new Geolocation field in SharePoint 2013 by the awesome Tobias Zimmergren (@zimmergren)
- Adding geolocation field to SharePoint Online by Borislav Grgić (@BorislavGrgi)
As I understand it, there’s an MSI package (SQLSysClrTypes.msi)that must be installed manually on the Web Front Ends (WFEs) in an on premises installation to enable Geolocation fields, but this is already in place in SharePoint Online. Given this, we should be able to add Geolocation columns to lists via the UI without PowerShell or admin intervention.
This doesn’t sit well with me. At some of my clients, getting an admin to add something to the WFEs or run PowerShell requires an act of Congress. These Geolocation capabilities are too powerful a SharePoint feature to keep them under wraps.
To wit, I’ve created a suggestion called Adding Geolocation Fields to SharePoint Lists on the Office Development UserVoice site. If you’d like to be able to use Geolocation fields in your SharePoint solutions – at least on Office365 – head on over and cast your vote(s). Remember, Microsoft is listening!
It’s a cool feature. I was surprised this wasn’t available without script or code, too. I’ve put 3 votes on your uservoice suggestion.
Thanks, Tom! While I don’t have any particular need for the feature myself right now, it’s too good to keep under a bushel. I’d love to make it a part of a couple of implementations I have coming up.
M.
Great post. What I find most disconcerting (aside from the concerns already mentioned) is that Geolocation columns cannot be indexed. I think there is tremendous potential value in search-driven apps that expose geo-tagged content via proximity or bounding box search (i.e., show me all documents tagged within a 10 mile radius of this location or anything within this area I draw on a map). As best I can tell, Geolocation column data is stored in VARBINARY columns in the content database rather than using the SQL Server GEOGRAPHY type. I’m not sure the search problem gets any easier to solve until the underlying representation in the database changes.
Marc, thanks for the reminder about this feature. i followed your lead and submitted the same suggestion to the Feature Request group in the IT Pro Yammer Network, i will go vote also
https://gallery.technet.microsoft.com/scriptcenter/Add-Geolocation-field-to-f7dbf90c
I knew about that tool, but it doesn’t help end users much.
M.
How about adding geolocation in sharepoint 2010?
Geolocation in SharePoint 2010 would be grand, but the capability isn’t available.
That said, you can do basically the some things yourself with script, calling Bing or Google services.
M.
Does anyone know how to add the location column as a custom site column, so that I wouldn’t have to do this every time I wanted it in a library.
Marc… Hope you are doing well and that ankle has healed up… (you borrowed my Lenovo X1 Carbon at SPTechCon 2015 Dev Days this past June).
Anyway, I was just fiddling with the GeoLocation feature and got it working without issue using a “Customers List”..
Then, I figured I would try to plot my customers on a map view for a “Service Calls” list connected to my customers list (with the geolocation id).
Unfortunately, it didn’t work because I cannot seem to create a lookup site column that includes the GeoLocation field as one of the included columns (at least in the web gui).
My customer is looking to be able plan service calls on a map to allow efficient scheduling of upcoming job.
Any ideas?
Rich:
I owe you big time for your help at that session! I really appreciate you loaning me your laptop. It’s a nice one.
The geolocation columns are as quirky as managed metadata columns and IMO, not very well baked. The fact that you have to jump through the hoops you do even to enable them is crazy.
The fact that you can’t use them in a lookup column is par for the course, I guess. What about adding some script to the Services Call’s NewForm to grab the geolocation values from the Customers list and save them into the Service Call? It might make sense to maintain that way historically, anyway, as you’d want to know where you *went*, not where they *are*.
M.
p.s. I’m walking on my own two feet at this point. Not totally normally, but on my own two feet!