Geolocation Field Types in Salesforce1 Platform
The Force.com geolocation field type is a native field type that customers can use to encode locations with geolocation coordinates. The Spring ‘15 release makes geolocation fields generally available.
In the Spring ‘15 release, the Salesforce1 Platform makes geolocation fields generally available.
Why do geolocation field types matter?
Connectivity, form factor, and location-awareness are the defining characteristics of positive mobile experiences. Connectivity is provided by your local telco and form factor by the Salesforce1 Mobile App and S1 Mobile Services. Geolocation adds the final piece in your company’s mobile-first product strategy.
The Force.com geolocation field type is a native field type that you can use to encode locations with geolocation coordinates.
Geolocation fields are available as two different field types: Standard address fields now come with embedded latitude and longitude fields. In addition, customers can create custom geolocation fields in the same way you would create any other custom field, such as custom number fields.
Why are geolocation field types awesome?
For years, Force.com customers and partners have used two number fields to store latitude and longitude pairs. This technique of course works, but it requires a lot of do-it-yourself building to have a complete geolocation offering.
Now, rather than using number fields to store latitude and longitude, customers and partners can use Force.com geolocation fields. These geolocation fields provide many capabilities that are not available with simple number fields.
Integration with address fields
Standard address fields in Salesforce now include latitude and longitude fields as part of the address itself. Embedding location in address fields means address fields can be used directly in distance formulae and calculations.
Geolocation fields only accept valid location pairs. Latitudes must be between -90 and +90 degrees and longitudes must be between -180 and +180 degrees. Data validation also prevents only one field being filled in; either both fields must have valid numbers or both must be null.
Native distance calculations
Salesforce provides a distance function in custom formula fields and in Apex static and instance methods. Developers and Salesforce Administrators can use this function to easily calculate locations’ distances from address fields and/or custom geolocation fields. You can also filter and sort by distance in SOQL and SOSL.
The new System.Address and System.Location classes in Apex contain many new methods, including getDistance to perform distance calculations natively in Apex. Here are examples of the Apex distance methods:
Location.getDistance(sanfranciscoLocation, tokyoLocation, 'km')
The distance calculation is based on the haversine formula, which is used in mapping and navigation applications and is illustrated below.
In the Summer ‘15 release we are adding SOQL bindings to Apex (Safe Harbor applies). This gives you the ability to bind your Apex variables to SOQL queries . Here is an example of such a query:
[SELECT ID, Name, BillingLatitude,BillingLongitude FROM Account where DISTANCE (BillingAddress, GEOLOCATION(:latitude,:longitude),'mi') < :distance];
Salesforce has optimized the performance of distance calculations in a way Force.com developers never could when building geolocation from two number fields. In addition, we have created the ability to add custom indexes to further improve performance for specific organizations.
Structured data types
One additional enhancement we made in the process of delivering Geolocation was creating a structured data type. Developers can work with addresses and geolocation fields as structured data types in SOQL and Apex, passing these compound fields directly into queries rather than using their components. (Structured data types are read-only; writes must still be made to individual field components.)
Here is an Apex query that selects individual Address fields:
Account acct = [SELECT BillingStreet, BillingCity, BillingState, BillingZip, BillingLatitude, BillingLongitude FROM Account WHERE name='Acme' limit 1];
String acctCity = acct.BillingCity;
String acctZipCode = acct.BillingZip;
String acctState = acct.BillingState;
Here is the same query selecting Address as a structured data type:
Account acct = [SELECT BillingAddress FROM Account WHERE name='Acme' LIMIT 1];
Address addr = acct.BillingAddress;
String acctCity = addr.city;
String acctZipCode = addr.postalCode;
String acctState = addr.state;
(Note that the compound field type introduces a new suffix to custom fields: “__s” (for “subfield”). A compound custom geolocation field called “myLocation__c” will have the subfields “myLocation__latitude__s” and “myLocation__longitude__s”.)
Using built-in geolocation fields in addresses will enable customers to take advantage of location-based features that Salesforce may deliver in the future.
Where are the data?
The geolocation feature described here is a schema-level feature. Geolocation fields are useful only once they are geocoded (populated with latitude and longitude data). Address fields can be geocoded using services from Google, Nokia, ESRI, and other sources. However, Salesforce will be rolling out a geocoding service to our customers in the future. (Naturally, Safe Harbor applies.)
What can I do with geolocation field types?
Once standard address fields have been geocoded, you can use them to view Leads, Accounts, Opportunities, and other records on maps, to find accounts near an upcoming sales call, or to assign Opportunities and Leads based on their locations.
Custom geolocation fields let you use geolocation for a wide range of applications outside the context of addresses. They can be used for tracking inventory or vehicles, route planning and optimization, and visualizing demographic, economic, and other data on maps.
Where you at?
So where are you in your development of location-based features? Do you store coordinates in number fields? Consider moving them to standard or custom geolocation fields to take advantage of all the built-in capabilities. Do you not have location-based features in your apps? Now is a great time to start adding them. As the adoption of mobile continues to grow, these features and apps will become more and more valuable to your business.