Status Update
Comments
an...@google.com <an...@google.com> #2
Please read
It looks like suites/apartments are not taken into account for address formatting.
mi...@google.com <mi...@google.com> #3
Geocoding API will find these places, and return subpremise elements in address_components:
9500 Bryn Mawr Avenue #650:
1403/648 Bourke Street:
130 Bowdoin st., apt. 1010:
Geocoding can be used as a fallback behind Autocomplete for these queries, the Geocoder Tool at
If you need to support suite/apt beyond that, there is a somewhat more complex fallback option:
- use the placeIdOnly option of Autocomplete class to capture the suggestion's description (e.g. "1403/648 Bourke Street Melbrourne, Victoria, Australia")
- match this description against a set of regular expressions to detect suite/apt in them, e.g. "\d+/\d+.*Australia" to detect 123/45 ... Australia)
- if there is a match, send the description to the Geocoding service, otherwise, request details for by Place ID
This can still be accomplished without coding your own Autocomplete widget.
mi...@google.com <mi...@google.com> #4
The resolution for the much greater problem in
[Deleted User] <[Deleted User]> #6
ad...@lawmaster.com.au <ad...@lawmaster.com.au> #7
I don't suppose a timeframe could be offered for when this is likely to be resolved?
pe...@gmail.com <pe...@gmail.com> #8
it...@entitysolutions.com.au <it...@entitysolutions.com.au> #9
or...@gmail.com <or...@gmail.com> #10
cu...@gmail.com <cu...@gmail.com> #11
st...@mandrill.emotedigital.com.au <st...@mandrill.emotedigital.com.au> #12
The unit number seems to replace the address.
[Deleted User] <[Deleted User]> #13
ju...@bubsngrubs.com.au <ju...@bubsngrubs.com.au> #14
cy...@gmail.com <cy...@gmail.com> #15
sh...@gmail.com <sh...@gmail.com> #16
ro...@captovate.com.au <ro...@captovate.com.au> #17
sh...@gmail.com <sh...@gmail.com> #18
co...@googlemail.com <co...@googlemail.com> #19
si...@gmail.com <si...@gmail.com> #20
How am I supposed to get an accurate mailing address for somebody without this?
The current UI actually encourages people to NOT enter an apartment/unit number, then the postal carrier has to figure it out - or the mail gets returned, or the customer gets confused.
So sticking with just a traditional form now :-(
am...@gmail.com <am...@gmail.com> #21
[Deleted User] <[Deleted User]> #22
mo...@gmail.com <mo...@gmail.com> #23
ez...@gmail.com <ez...@gmail.com> #24
ti...@digistorm.com <ti...@digistorm.com> #25
pr...@gmail.com <pr...@gmail.com> #26
ro...@gobigriver.com <ro...@gobigriver.com> #27
ch...@gmail.com <ch...@gmail.com> #28
li...@gmail.com <li...@gmail.com> #29
ry...@gmail.com <ry...@gmail.com> #30
da...@gmail.com <da...@gmail.com> #31
mi...@gmail.com <mi...@gmail.com> #32
This way you will vote for the issue and get notified for its status... And not spam everyone else.
ik...@gmail.com <ik...@gmail.com> #33
af...@gmail.com <af...@gmail.com> #34
mj...@gmail.com <mj...@gmail.com> #35
[Deleted User] <[Deleted User]> #36
jo...@jch254.com <jo...@jch254.com> #37
mb...@gmail.com <mb...@gmail.com> #38
[Deleted User] <[Deleted User]> #39
st...@gmail.com <st...@gmail.com> #40
[Deleted User] <[Deleted User]> #41
With the absence of this feature, we will have to build our own Autocomplete API that uses the Google Places Autocomplete and is backed by the Geocode API. Of course our API will not be as good as Google APIs.
mi...@google.com <mi...@google.com>
mi...@google.com <mi...@google.com> #42
Since July 28th, Place Autocomplete supports subpremise predictions in 3 countries:
Australia, New Zealand and Canada.
We acknowledge support for US address is on demand and will look into this.
Unfortunately there is a new issue where a few subpremise predictions return a Place ID that cannot be retrieved from Place Details:
We are actively working on a fix for this.
There is no ETA we can provide at this time for any of the above. We will keep you posted.
bs...@gmail.com <bs...@gmail.com> #43
[Deleted User] <[Deleted User]> #44
ac...@salesforce.com <ac...@salesforce.com> #45
Based on the behavior in the following API demo:
1) When subpremise is included in the search, it can be recognized and predictions returned contain addresses which match the subpremise
2) However, when the prediction is selected, the subpremise part is taken as street number, and the street number gets eliminated from the auto-populated address field.
Appreciate your clarification on this behavior.
Thank you
mi...@google.com <mi...@google.com> #46
Yes, that is the case.
Place Autocomplete preserves user input as closely as possible. In the case of subpremise tokens, these will typically be returned in the prediction from Place Autocomplete (1) even if there is no guarantee that Place Details will return the same (2). This Feature Request is directed at returning these subpremise tokens also in the Place Details response. This is currently available only in Australia, New Zealand and Canada. We are working on expanding this to other countries, including US.
ac...@salesforce.com <ac...@salesforce.com> #47
Hello there,
Thank you for the quick response!
Regarding the statement "This is currently available only in Australia, New Zealand and Canada", are you refer to the support for subpremise in the Place Automcomplete(1) only, or that it is currently supported (guaranteed to be returned) in the Place Details response for these 3 countries too?
Thanks again for your clarification! :)
mi...@google.com <mi...@google.com> #48
In these 3 countries, for the specific subpremise formats that are supported, Place Autocomplete returns a different Place ID that guarantees Place Details will return the subpremise token.
For instance, the Place ID for the address in
mi...@google.com <mi...@google.com> #49
We greatly appreciate your patience and have good news: subpremise predictions are now returned in all countries.
When Place Autocomplete recognizes the input as representing a subpremise location (e.g. apartment, suite, etc.) one or more predictions are returned with types: ["subpremise","geocode"]
and a Place ID that will enable Place Details to do the same.
Example address: tome cano 9 piso 11 puerta 13
description: "Calle Tome Cano, 9, piso 11 puerta 13, Santa Cruz de Tenerife, Spain",
place_id: "EkRDYWxsZSBUb21lIENhbm8sIDksIHBpc28gMTEgcHVlcnRhIDEzLCBTYW50YSBDcnV6IGRlIFRlbmVyaWZlLCBTcGFpbiItGisKFgoUChIJDzhGUJrMQQwRK8l9IT0vJVwSEXBpc28gMTEgcHVlcnRhIDEz",
types: ["subpremise","geocode"]
formatted_address: "C. Tome Cano, 9, piso 11 puerta 13, 38005 Santa Cruz de Tenerife, Spain",
name: "C. Tome Cano, 9, piso 11 puerta 13",
types: ["subpremise"],
Additional example addresses, as previously reported here:
9500 Bryn Mawr Avenue #650
description: "9500 West Bryn Mawr Avenue #650, Rosemont, IL, USA",
place_id: "EjI5NTAwIFdlc3QgQnJ5biBNYXdyIEF2ZW51ZSAjNjUwLCBSb3NlbW9udCwgSUwsIFVTQSIfGh0KFgoUChIJE0vqdAi2D4gR9ySp6a8lEmkSAzY1MA",
types: ["subpremise","geocode"]
formatted_address: "9500 W Bryn Mawr Ave #650, Rosemont, IL 60018, USA",
name: "9500 W Bryn Mawr Ave #650",
types: ["subpremise"],
130 Bowdoin st., apt. 1010
description: "130 Bowdoin St apt 1010, Dorchester, MA, USA",
place_id: "EiwxMzAgQm93ZG9pbiBTdCBhcHQgMTAxMCwgRG9yY2hlc3RlciwgTUEsIFVTQSIkGiIKFgoUChIJ-wFl5bh744kR-oIrrKrdqwcSCGFwdCAxMDEw",
types: ["subpremise","geocode"]
formatted_address: "130 Bowdoin St apt 1010, Dorchester, MA 02122, USA",
name: "130 Bowdoin St apt 1010",
types: ["subpremise"],
gaston geenslaan 11/b4
description: "Gaston Geenslaan 11/b4, Leuven, Belgium",
place_id: "EidHYXN0b24gR2VlbnNsYWFuIDExL2I0LCBMZXV2ZW4sIEJlbGdpdW0iHhocChYKFAoSCUcVDMwIYcFHEfSCQ0O8JMyFEgJiNA",
types: ["subpremise","geocode"]
formatted_address: "Gaston Geenslaan 11/b4, 3001 Leuven, Belgium",
name: "Gaston Geenslaan 11/b4",
types: ["subpremise"],
515 W 42nd St #10, New York, NY 10036, USA
description: "515 W 42nd St #10, New York, NY 10036, USA",
place_id: "Eio1MTUgVyA0Mm5kIFN0ICMxMCwgTmV3IFlvcmssIE5ZIDEwMDM2LCBVU0EiHhocChYKFAoSCUWVl5ZNWMKJEbXGp_jlkxplEgIxMA",
types: ["subpremise","geocode"]
formatted_address: "515 W 42nd St #10, New York, NY 10036, USA",
name: "515 W 42nd St #10",
types: ["subpremise"],
We believe this issue is now fixed, hence marking it as such.
Thanks for working with us!
ma...@gmail.com <ma...@gmail.com> #50
ra...@remato.com <ra...@remato.com> #51
For example:
"Pikk 74, Tartu, Eesti" returns type "premise" prediction with placeId "ChIJv5XKc9s260YRdo9JMHN3oE8"
But input with apartment number "Pikk 74-3, Tartu, Eesti" returns only type "street_address" with inaccurate placeId "EhdQaWtrIDc0LTMsIFRhcnR1LCBFZXN0aSIwEi4KFAoSCcNrdp7bNutGEYzpBfD8K5N7EEoqFAoSCY9eIILcNutGEeF6uOx2JXki"
mi...@google.com <mi...@google.com> #52
Please
Description
* 9500 Bryn Mawr Avenue #650:
* 1403/648 Bourke Street:
"130 Bowdoin st., apt. 1010" also gives 0 results, looks like suite/apartment isn't recognized at all.
Related issue: