IssueTracker

Fixed in version 1.10.0. Thanks for the report!

We do get a structured address back from the API from the `getPlaceById` (looking at the network traffic).  But it is not exposed though the SDK.

```
{
        "id": "gtl_3",
        "result": {
                "header": {
                        "key": "2:jHynw9bM1yhJz_1U:nZNIo3AEVMSV2hFr"
                },
                "places": [{
                        "id": "ChIJF8RjQ80EdkgRwa4ehjU6Rog",
                        "types": ["street_address"],
                        "locale": "en",
                        "name": "125 Shaftesbury Ave",
                        "address": "125 Shaftesbury Ave, London WC2H 8HR, UK",
                        "addressComponents": [{
                                "type": "street_number",
                                "longName": "125"
                        }, {
                                "type": "route",
                                "placeId": "ChIJqWgRltIEdkgRgoGzrQCLGmc",
                                "longName": "Shaftesbury Ave"
                        }, {
                                "type": "locality",
                                "placeId": "ChIJdd4hrwug2EcRmSrV3Vo6llI",
                                "longName": "London"
                        }, {
                                "type": "postal_town",
                                "placeId": "ChIJ8_MXt1sbdkgRCrIAOXkukUk",
                                "longName": "London"
                        }, {
                                "type": "administrative_area_level_2",
                                "placeId": "ChIJb-IaoQug2EcRi-m4hONz8S8",
                                "longName": "Greater London"
                        }, {
                                "type": "country",
                                "placeId": "ChIJqZHHQhE7WgIReiWIMkOg-MQ",
                                "longName": "United Kingdom"
                        }, {
                                "type": "postal_code",
                                "placeId": "ChIJ0zxlQc0EdkgR5G4dRIHNRaY",
                                "longName": "WC2H 8HR"
                        }],
                        "geometry": {
                                "location": {
                                        "latitude": 51.5139748,
                                        "longitude": -0.1284614
                                }
                        }
                }]
        }
}
```

any news on this? or as always?

I have also confirmed that the Address field is not there in 1.10.1. Please help!

I can also confirm this on iOS, SDK version 1.10.19729.0! Now, there is no address property in documentation as well (https://developers.google.com/places/ios/place-details)!

After making a "lookUpPlaceID:callback:" request, I get GMSPlace back, which does not have address exposed in any way. However it does have instance property called "addressComponents" which is not exposed either but you can access it through "[place valueForKey:@"addressComponents"]"; The "addressComponents" property holds an array of objects of type "GMSAddressComponent" (which is by the way not recognised by SDK so you can't cast it). GMSAddressComponent objects are basically dictionaries with "type" and "name" keys. Types can be "route", "street_number", "locality", etc.

This approach is not safe at all since there is no type checking. Exception will be thrown as soon as any of the keys accessed in "valueForKey:@"KEY"" won't exist anymore. That said, "addressComponents" proves that there is address information contained deep inside GMSPlace objects, it's just not properly exposed.

Google Maps team, what is the status of this?

How can one do Place Autocomplete efficiently if there is no concrete GMSAddress object exposed?

Please advise!

Damir, thanks for your detailed report. I've raised a new issue with engineering so we will have another look at this.

Ok. Please keep us in the loop about progress. Thanks!

Please, let us know when the SDK is updated.
We really need to access to place details from "GMSPlace".
I should be able to do:
place.address
place.locality
place.country
place.zipcode

I mean, any details of the place...  Or maybe add an object Address to GMSPlace please.

Seriously, this is really annoying! I don't really get why this haven't been resolved yet (since May!)

[Comment deleted]

Sometimes it looks for me like Google intentionally ignores quality in iOS part of business :(

Is there any update on this? I see the "address" property is not located in the SDK Documentation anymore, will it be added again and exposed through the SDK?

Any update?  Using reverseGeocodeCoordinate I get back the wrong address ~5% of the time

I guess our other option is to use MKLocalSearchRequest.

Definitely blocked from using Google services as result of this bug. Too bad for you guys, I guess...

3:20 am -

We just spend couple hours setting up autocomplete to with the goal to extract address component, (street name, number, city, etc..) and then ran into this. GRRRRR. One quick way we went around this issue was to use google autocomplete to retrieve coordinates and then feed it into apple CLGeocoder reverseGeocodeLocation and get the required info, but what the **** are we doing. We prefer to use this SDK all the way.  Not sure if MKLocalSearchRequest provides auto-complete but we'll see.

Note to self. research SDKs to the bone and don't assume Google got it all for you from the start. :(

is this safe?

NSArray* dic = [place valueForKey:@"addressComponents"];

for (int i=0;i<[dic count];i++) {
    if ([[[dic objectAtIndex:i] valueForKey:@"type"] isEqualToString:@"street_number"]) {
        NSLog(@"street_number: %@",[[dic objectAtIndex:i] valueForKey:@"name"]);
    }

Bump!  :)

Google devs... This issue is there since I don't remember which version, you are releasing new version every month without the fix of that problem.
Come on...

Can you please just add the property address like it was initially documented before ?!
Once we look up details of a place, we should be able to access to any properties related to the address. Country, city, address, zipcode... any other details related to the address.

place.address
place.locality
place.country
place.zipcode

Please, can you address that problem for the next version 1.10.6 ?

Thanks

This is a BIG blocker for my team, please look into this, guys!

Hi guys,

I was flabbergasted to learn there's no way to get structured address out of the Place and now I have to user reverse-geocoding. Could you please expose it, as you already have it deep inside the object.

This is a shame for all Google developers. I recently talked with a guy from Google and their attitude toward iOS SDK was obvious. They made it just to have it. I had a lot of issues using it and they are suggesting to use Javascript maps and api in webview.

Do you have an address where I can send my resume to the Google Map iOS SDK team please ?
I will be happy to join the team just to make the fix myself in the SDK. Seems like some help it needed.

Tchikovani.sandro,

Please apply through http://www.google.com/about/careers/

Thanks!

Glad the sarcasm of Tchikovani's comment was completely lost on you. Can you please just fix this or mark this as wont-fix if you aren't going to fix it? This thread is becoming extremely painful.

For those who need an actual working solution, here is a sample of the workaround I use. NOTE: Use at your own risk, if they change the API of the SDK, this may crash.
- (void)locationSearch:(CPLocationSearchViewController *)search chooseLocation:(GMSPlace *)location {

     NSString __block *streetNumber, *streetName;
    _.arrayEach([location valueForKey:@"addressComponents"], ^(id obj) {
        NSString *type = [obj valueForKey:@"type"];
        NSString *val = [obj valueForKey:@"name"];
        NSLog(@"addressComponent - %@: %@", type, val);
        if ([type isEqualToString:@"street_number"]) {
            streetNumber = val;
        }
        if ([type isEqualToString:@"route"]) {
            streetName = val;
        }
        ... (repeat for each component important to you)
    });
}

Any word on this. Its definitely a show stopper and I hate using @crashpadlife's hack but so far its the only way without having to make an extra api call to reverse geocode.

re: #28: Here's a rudimentary Swift version. Same caveats apply.

    func getLocationAddressParts (place : GMSPlace)
    {
        var name = ""
        var streetNum = ""
        var street = ""
        var city = ""
        var state = ""
        var country = ""

        if let theName = place.name
        {
            name = theName
        }

        let comp = place.valueForKeyPath("addressComponents") as! NSArray
       
        for obj : AnyObject in comp
        {
            let val = obj.name
            let fieldName = obj.type as String
           
            print("addressComponent = \(fieldName) : \(val)")
           
            switch fieldName
            {
                case "street_number":
                    streetNum = val
                case "route":
                    street = val
                case "locality":
                    city = val
                case "administrative_area_level_1":
                    state = val
                default:
                    break
            }
        }
  }

Hi everyone,
 i integrated now (03/02/16) this library, but have the same problem, the addressComponents object is not visible, but i adopted the classic solution whit foreach all dictionary element, is possible that Google Maps Developer Team after 1 year don't solve this problem? all of this it's very ridiculous.

We've exposed a structured address components to GMSPlace objects in v1.12.2. Please update.

Yay!!!!  Woohoo!  Thanks guys

[Comment deleted]

I've created a Swift extension to make it easier to deal with this awful components API. I think I have the keys right but "street_number" isn't available as a constant from the framework, so it's in there manually.

extension CollectionType where Generator.Element == GMSAddressComponent {
    var streetAddress: String? {
        return "\(valueForKey("street_number")) \(valueForKey(kGMSPlaceTypeRoute))"
    }
   
    var city: String? {
        return valueForKey(kGMSPlaceTypeLocality)
    }
   
    var state: String? {
        return valueForKey(kGMSPlaceTypeAdministrativeAreaLevel1)
    }
   
    var zipCode: String? {
        return valueForKey(kGMSPlaceTypePostalCode)
    }
   
    var country: String? {
        return valueForKey(kGMSPlaceTypeCountry)
    }
   
    func valueForKey(key: String) -> String? {
        return filter { $0.type == key }.first?.name
    }
}

We have added missing Place Type constants in version 1.13. Thanks for the report!

[Comment deleted]

This issue is still not resolved though you've marked it as fixed. The GMPlace object still does not expose a GMSAddress object; neither these missing 'place type' constants nor the address components resolve this. The address components array still requires me to query and loop through the array to find the keys I want versus being able to simple call methods on a GMSAddress object. Please re-open the issue an add an actual GMSAddress object onto GMPlace.

Yep, this is a nightmare. Hours wasted!

How should we proceed to get this issue resolved? Should I open a separate bug report or can you all reopen this ticket? It would be great to talk to someone directly too.

Still looking for an update here on re-opening the issue to fix the actual reported bug.

I've noticed the HTTP API returns the short name as a part of the response.  Is there any reason why the short name is not included as a part of GMSAddressComponent's interface?

Another issue I've noticed is that if the place types is "street_address", then the addressComponents is empty. I would still expect the usual array of components, however inefficient it is.

As this issue has been closed, please open new bug reports with the details of the issue you are experiencing.

The original issue (now over a year old) was to provide a GMSAddress object along with a GMSPlace object. That has still not been resolved and this issue should not have been closed as Fixed. Accessing address information from a GMSPlace is still much too cumbersome and it remains greatly beneficial to have access to the actual GMSAddress object.

Chris, I understand your position. Engineering reviewed the original request and provided the solution they did based on what was possible given the data provided by our back end systems. The bug was marked fixed to communicate that the provided solution was the best that we can accomplish given the data we have access to. My request for new issues was for the observations by Sean and Simon that they are seeing new breakages that should be raised and tracked individually.

Thanks!

I appreciate the follow up; I will take a look at the current state of the SDK and submit a new bug report taking into account that addition of those addressComponents. Would really like to avoid wrapping the places API myself if possible.