SharePoint Location columns have some issues which are pervasive and repeatable. One of the purportedly biggest benefits of using one of these columns is we can type in an address, and it’s looked up in Bing Maps. What’s supposed to happen is the details of that location are then parsed out and made available for use as separate “pseudo-columns”. For example, we might type in ‘111 Coleman Blvd, Savan’ and then select the corresponding location.

Then in the list where we have the column, we can choose to display the City, State, Postal Code, etc. without ever entering them.

All well and good. Many addresses, though, come back with missing parts of their data. In this case, there is no latitude/longitude, which we’d like to have for mapping. This is one if the big benefits of using a Location column! There’s no way to discern in the UI whether the variants one might see for an address is “better” than another. In this case, choosing ‘111 Coleman Blvd, Pooler, GA 31408’, which is the exact same building, yields the latitude/longitude.

But there’s no way in the UI to discern this as we are making the selection. I can only figure it out if I go to the Bing Maps UI and look for the latitude/longitude at the bottom of the left panel.

Alas, my excitement at realizing this variant on the address has a lat/long was short-lived, as the values are not pulled into the list on selection.

As you can see below, even though I have selected an address which has all the values in Bing Maps, only a few of the pseudo-columns are populated. The lat/long are missing as well as the Postal Code.

It’s also very easy to “select” a value which isn’t even coming from Bing Maps. In other words, I can type ‘111 Coleman Blvd’ and hit enter, and that value is stored in the column with no warning that it isn’t “connected” to Bing Maps. Or, even worse, one of the values from the dropdown is selected, and may well be wrong. Here, I’ve mistakenly typed ‘1111 Coleman Blvd’ and I just get that untethered value and there’s nothing in the UI to make that clear. (Yes, the second line is blank, but you only see that if you edit the column.)

Another small annoyance is once an address is selected, we can’t copy it from the field in edit mode. We can’t highlight the address anywhere in the UI I can find. So, if we want to grab that address, there’s no way to do so.

And so forth…

What’s your luck been with Location columns? Do you find you consistently get valid – and useful – data back from Bing Maps?

Have I ever mentioned how important Content Types are in SharePoint? Almost everything you work with in SharePoint has a Content Type. If you’re just using Document and Item, you’re really not using the platforms.

In this post, I want to talk about Site Content Types and the Location column type.

Location Columns

Sometime in the last few years, we got a cool new type of column we can use in SharePoint. In Microsoft’s infinite wisdom, it’s called either a GeoLocation column or a Location column, depending on where you interact with it. It’s got a lot of magical qualities, but I can’t easily find an end user article about those qualities. Buried in the support article List and library column types and options, you’ll read this:

Add rich location data from Bing Maps or your organization directory. The location column provides additional columns to filter, sort, and search by related information including street address, city, state, country or region, postal code, coordinates, or name.

Site Content Types

Site Content Types are the best kind of Content Types in my book because we can instantiate them across modern sites with Site Templates (nee Site Designs).

Until recently, we couldn’t create a Location column as a Site Column (to add to a Site Content Type) unless we ran the Add-PnPField PnP.PowerShell cmdlet. (See: Add a Geolocation column to a list programmatically in SharePoint) Not exactly the purview of your average information architect.

Today I wondered if this had changed – and it has!

Add a Location Column to a Site Content Type

The big thing that changed recently is that Microsoft is slooowwwlyyy moving us away from the Content Type Hub and into the Content Type Gallery. When the new Content Type Gallery was initially delivered, it was really just lipstick on a pig; it was still the Content Type Hub underneath.

Now when we go into Site Settings on a modern site and click the Site content types link, we land in the Content Type Gallery. This is pretty new, and it’s possible you don’t see it in your tenant yet, though it seems to be in all the tenants where I’m working. In the Content Type Gallery , we can add Site Columns in this new UI with the Location column type.

Let’s say I want to create a Site Content Type called Property. A very normal thing I’d want to know about a Property is its address, and I’d sure like to use a magical Location column type to capture it. Here’s the sequence.

From the home page of your modern site:

Click on the gear

Choose Site information, then View all site settings

On the ugly old Site Settings page, we still see the same old two options in the Web Designer Galleries section:

The difference is now when we click on the Site content types link, we land in the Content Type Gallery.

Once we’re here, we can build the Content Type pretty much like we would in the old UI. It’s basically the same.

The big difference for this post is we can now choose a Location column when we create a new Site Column.

See that Location in the Type column below?

---

I did run into one issue. I had already enabled the Property Content Type in a list, and the new Location column wasn’t showing up. Unfortunately, the Update sites and lists option, which we’re used to having checked by default is now NOT checked by default. So you need to be sure to click it EVERY TIME YOU MAKE A CHANGE TO THE CONTENT TYPE if you want that change to cascade down into your list or libraries. I have never unchecked that box in the past, and I consider it a “bug” that the default is unchecked now. At least it’s something we can work around. I hope Microsoft changes this back to the old behavior.