- Getting Started with Core Location and Map Kit
- The Core Location Manager
- Forward and Reverse Geocoding
- Working with Map Kit
- Wrapping Up
Forward and Reverse Geocoding
Geocoding is the process of going from a set of latitude and longitude coordinates to a human readable address and vice versa. Forward geocoding means you start with an address or location (such as Boston, MA) and end up with latitude and longitude coordinates. Reverse geocoding is the process of going from latitude and longitude coordinates back to a human-readable address.
Before iOS 5, developers only had access to reverse geocoding APIs available in Map Kit. With the introduction of iOS 5, however, the Map Kit APIs have been deprecated and Apple engineers added both forward and reverse geocoding to the Core Location framework. Not only does iOS 5 provide unique access to forward geocoding APIs, but there is no longer a dependency on Map Kit for these processes.
Geocoding Benefits
One of the major advantages of using the iOS 5 geocoding APIs is the fact that they are inherently locale based. For example, if my phone is set to Japanese as my native language and I’m visiting a friend in the United States, when I perform a geocoding operation to convert coordinates to a physical address, the result is returned in the native language of my phone (Japanese). This involves not only translating the language but also reformatting the order in which addresses are communicated.
Additionally, the forward geocoding APIs are form agnostic, meaning they really don’t care what language or format an address is entered in. The geocoding APIs will automatically handle any known format based on the language settings of the device and handle the conversion as necessary.
As a developer working with the geocoding APIs, you don’t have to do anything special to make your app work with different geocoding languages.
Geocoding Drawbacks
One of the biggest drawbacks to the geocoding API stems from one of its great advantages. All of the geocoding operations are handled in the cloud, meaning the conversions do not happen on the device. Now, this is undeniably an advantage because your device is not wasting precious power and resources to handle the conversion. Additionally, as new conversion information and techniques become more accurate, Apple can simply update their APIs in the cloud giving your app even better performance down the road. The drawback is your app must have an Internet connection to use the geocoding APIs. That means if your app is running in airplane mode or on a Wi-Fi-only device that’s not connected to a Wi-Fi hotspot, you won’t have access to geocoding services and should plan accordingly.
Forward Geocoding
Forward geocoding means you’re starting with an address and are seeking coordinates. This can be used to create the coordinates of a region, as needed by the previous example on region monitoring, or to derive the coordinates of nearby locations based on address information (such as a check service or nearby restaurants). There are three ways to forward geocode. Two of these methods involve simple string conversion while the third supports an address dictionary.
Working with Strings
The first, and most simple, geocoding operation converts a single string to an array of possible CLPlacemark objects.
1 // Geocode a simple string using a completion handler 2 [fgeo geocodeAddressString:@"Boston, MA" completionHandler:^(NSArray *placemarks, NSError *error){ 3 4 // Make sure the geocoder did not produce an error 5 // before continuing 6 if(!error){ 7 8 // Iterate through all of the placemarks returned 9 // and output them to the console 10 for(CLPlacemark *placemark in placemarks){ 11 NSLog(@"%@",[placemark description]); 12 } 13 } 14 else{ 15 // Our geocoder had an error, output a message 16 // to the console 17 NSLog(@"There was a forward geocoding error\n%@", [error localizedDescription]); 18 } 19 } 20 ];
In this code block we convert the simple string, “Boston, MA”, to a CLPlacemark using forward geocoding. The returned array of CLPlacemarks contains all of the possible placemarks for the given address. Obviously, the more information you provide in the address string, the more reliable the returned placemarks will be. As mentioned before, one of the advantages of the geocoding APIs is they’re form independent. It’s not necessary that you add delimiters like commas or tabs between your address values.
The second geocoding operation is similar, but allows for further optimization by limiting the conversion to a specified CLRegion. If you want to help iOS with the conversion process, you can define a CLRegion (if known) to limit the scope of search and improve result speed and accuracy. This method is handled just as before, except we define a CLRegion as an additional parameter, as seen in the following code block:
1 [fgeo geocodeAddressString:@"Boston, MA" inRegion:myRegion completionHandler:^(NSArray *placemarks, NSError *error){ 2 //handle results 3 } 4 ];
Working with Address Dictionaries
The third method used to forward geocode address information operates within the context of an address dictionary. Using the Address Book framework, you have full access to the contact cards and their relevant address information. When pulled from the address book, this information is returned as an NSDictionary object with various keys and values based on the information available.
Using the geocodeAddressDictionary method on a geocoder object, you can easily convert this address book dictionary into a CLPlacemark. This is exactly the process Siri uses to convert address book information for labels like home or the office into region monitoring services using the location manager. The following code block demonstrates how to convert an address book dictionary using the GLGeocoder class. For a complete example on how to pull these address dictionaries from the Address Book using the ABPeoplePicker, visit iOSCoreFrameworks.com/download#chapter-4.
1 [fgeo geocodeAddressDictionary:myAddressDictionary completionHandler:^(NSArray *placemarks, NSError *error){ 2 //handle results 3 } 4 ];
Reverse Geocoding
Reverse geocoding is the process of converting a CLLocation into a CLPlacemark. Remember that the CLPlacemark contains the CLLocation, CLRegion, and an NSDictionary for the address. So while both geocoding techniques create a CLPlacemark, the geocoding process CLGeocoder simply fills in the blanks.
The following example demonstrates how to convert a CLLocation into a CLPlacemark using reverse geocoding. Remember, because the monitoring services return CLLocation objects when a new update is performed, you can easily obtain an address for a user’s location by starting the standard location service, obtaining their current location, and then reverse geocoding that location with the CLGeocoder.
1 // Reverse Geocode a CLLocation to a CLPlacemark 2 [fgeo reverseGeocodeLocation:myLocationObject completionHandler:^(NSArray *placemarks, NSError *error){ 3 4 // Make sure the geocoder did not produce an error 5 // before continuing 6 if(!error){ 7 8 // Iterate through all of the placemarks returned 9 // and output them to the console 10 for(CLPlacemark *placemark in placemarks){ 11 NSLog(@"%@",[placemark description]); 12 } 13 } 14 else{ 15 // Our geocoder had an error, output a message 16 // to the console 17 NSLog(@"There was a reverse geocoding error\n%@", [error localizedDescription]); 18 } 19 } 20 ];