Assigned
Status Update
Comments
fr...@gmail.com <fr...@gmail.com> #2
I need that too
no...@gmail.com <no...@gmail.com> #3
It would be great to have this feature. It would save me at least three web service requests.
ma...@gmail.com <ma...@gmail.com> #4
I'd love to see that! At this time I'm using multiple calls to accomplish the same result and I'm probably risking get wrong results.
dm...@gmail.com <dm...@gmail.com> #5
Seems like easy to accomplish from the google team. Please solve this issue, really helpful to gather correct results.
mi...@google.com <mi...@google.com> #6
Could you (all) please explain what would you use this for?
[Deleted User] <[Deleted User]> #7
The use case I'm working on is:
1- user types in a city name
2- user gets an autocomplete list of possible cities
3- user selects one result and next screen displays a breadcrumb of the destiny. Like this one: country > state > neighborhood > city. Each component of this breadcrumb has a link to proper destination.
By having place_id in each component we can better get information about the higher destination components.
1- user types in a city name
2- user gets an autocomplete list of possible cities
3- user selects one result and next screen displays a breadcrumb of the destiny. Like this one: country > state > neighborhood > city. Each component of this breadcrumb has a link to proper destination.
By having place_id in each component we can better get information about the higher destination components.
mi...@google.com <mi...@google.com> #8
Thanks for your prompt response. Could you please explain in more detail what do you do then with each component's details?
[Deleted User] <[Deleted User]> #9
Sure, no problem ;)
I'm building a marketplace of services for travellers and I'm willing to use Google Maps in order to provide more details about the locations.
Visitors will face a list of featured destinations (suggested by my service) and they can also reach another locations by textual search (autocomplete).
I'm studying multiple Google Maps API's (autocomplete, photos, place details..) in order to create an interface rich in content that helps the visitor to decide which place to travel to.
By having this feature request implemented I can reduce drastically the number of requests to Maps API therefore leading to reduce response time.
Feel free to request more details. I'm glad to help to get this feature deployed :)
I'm building a marketplace of services for travellers and I'm willing to use Google Maps in order to provide more details about the locations.
Visitors will face a list of featured destinations (suggested by my service) and they can also reach another locations by textual search (autocomplete).
I'm studying multiple Google Maps API's (autocomplete, photos, place details..) in order to create an interface rich in content that helps the visitor to decide which place to travel to.
By having this feature request implemented I can reduce drastically the number of requests to Maps API therefore leading to reduce response time.
Feel free to request more details. I'm glad to help to get this feature deployed :)
mi...@google.com <mi...@google.com> #10
Thanks, but I was looking for more details on what do you do with each address component's details in particular. You've described the high-level use case, but I'm looking for the low-level details of which fields in each address component's details (as they come from Geocoding API when querying by Place ID).
[Deleted User] <[Deleted User]> #11
Got it. Let try again:
I start by using the visitors input in the following request:
https://maps.googleapis.com/maps/api/place/autocomplete/json?components=country%3ABR&input=INPUT&language=pt-BR&type=%28cities%29&key=KEY
(I'm looking only for cities in Brazil, written in pt-BR) Sample result:
Then I display this results to the user. Once he picks one, I send the proper place_id back to my server in order to display the next view.
The next view will display info for the city, its state and its country.
Since I don't have the place_id for each component, I need to query GoogleMaps again in order to get the list of components of the city (considering autocomplete response doesn't includes it) and then create multiple queries for each component, to get the right place_id's.
- Get components list
https://maps.googleapis.com/maps/api/place/details/json?language=pt-BR&placeid=ChIJ1Z3UnpMmk5QRqw733UypFJc&key=KEY
- Then uses Geocode for each component
https://maps.googleapis.com/maps/api/geocode/json?language=pt-BR&COMPONENT_DATA
Note that this process is to expensive, slow and error prone, since there are multiple places with the same name all over the world.
I start by using the visitors input in the following request:
(I'm looking only for cities in Brazil, written in pt-BR) Sample result:
Then I display this results to the user. Once he picks one, I send the proper place_id back to my server in order to display the next view.
The next view will display info for the city, its state and its country.
Since I don't have the place_id for each component, I need to query GoogleMaps again in order to get the list of components of the city (considering autocomplete response doesn't includes it) and then create multiple queries for each component, to get the right place_id's.
- Get components list
- Then uses Geocode for each component
Note that this process is to expensive, slow and error prone, since there are multiple places with the same name all over the world.
mi...@google.com <mi...@google.com> #12
Nearly there :)
What I'm looking for here, is what do you do with the details you get after querying for each of the components above the city. That is, what do you do with the country and state? Do you use their location, viewport, or other fields, and for what?
What I'm looking for here, is what do you do with the details you get after querying for each of the components above the city. That is, what do you do with the country and state? Do you use their location, viewport, or other fields, and for what?
pa...@gmail.com <pa...@gmail.com> #14
I would like to add my voice that this would be a great addition to the Place Detail response.
My specific use case is such:
Indexing a place for future queries in my database- which may include queries by city, region or country. Using a place ID instead of the returned strings, such as "Cape Town", "Western Cape" and "South Africa"- feels much safer in the long term- since names may change (and language can be fickle) but Place ID has been created to remain consistent.
So for example, if I wanted to get all the soccer Team entities listed within the region "Western Cape", I could just do a simple query like:
GET Teams WHERE REGION_PLACE_ID="ChIJ841peohdzB0Ri6I2IY95juk" && SPORT_TYPE="SOCCER"
I feel it provides a relatively simple method of achieving consistent geographical granularity.
My specific use case is such:
Indexing a place for future queries in my database- which may include queries by city, region or country. Using a place ID instead of the returned strings, such as "Cape Town", "Western Cape" and "South Africa"- feels much safer in the long term- since names may change (and language can be fickle) but Place ID has been created to remain consistent.
So for example, if I wanted to get all the soccer Team entities listed within the region "Western Cape", I could just do a simple query like:
GET Teams WHERE REGION_PLACE_ID="ChIJ841peohdzB0Ri6I2IY95juk" && SPORT_TYPE="SOCCER"
I feel it provides a relatively simple method of achieving consistent geographical granularity.
an...@google.com <an...@google.com>
ru...@gmail.com <ru...@gmail.com> #15
We have an almost identical use case as #14.
We reportedhttps://issuetracker.google.com/issues/37886842 but this proposition would allow for a significantly more elegant solution.
The problem we're trying to solve is to determine if a specific location is a part of a greater location.
For example, an entity is tagged with a specific location like "19 Victoria Street, Auckland, New Zealand". Entities can be tagged with less specific components as well, so another one might be tagged with "Victoria Street", or just "Auckland". We need to find all entities that exist under any location component. So if I do a query for "Auckland", that entity at "19 Victoria Street" should qualify and be included in the result set.
At the moment the only way to achieve this is to take the street address (19 Victoria Street) and geocode each component below that, ie:
1. Autocomplete provides the place_id
2. Look up the place_id details
3. Geocode each component
If the API provided the place_id for each of those components in the details it would remove the need to geocode them. It would also be less fragile because we wouldn't have to search on the names of each component assuming the first result is the one we want. There's risk involved here that we might link to the wrong component.
In our database we would then set a place_id for each component on the entity, allowing for a query such as "all entities in Auckland (City)", exactly like the example in #14.
We reported
The problem we're trying to solve is to determine if a specific location is a part of a greater location.
For example, an entity is tagged with a specific location like "19 Victoria Street, Auckland, New Zealand". Entities can be tagged with less specific components as well, so another one might be tagged with "Victoria Street", or just "Auckland". We need to find all entities that exist under any location component. So if I do a query for "Auckland", that entity at "19 Victoria Street" should qualify and be included in the result set.
At the moment the only way to achieve this is to take the street address (19 Victoria Street) and geocode each component below that, ie:
1. Autocomplete provides the place_id
2. Look up the place_id details
3. Geocode each component
If the API provided the place_id for each of those components in the details it would remove the need to geocode them. It would also be less fragile because we wouldn't have to search on the names of each component assuming the first result is the one we want. There's risk involved here that we might link to the wrong component.
In our database we would then set a place_id for each component on the entity, allowing for a query such as "all entities in Auckland (City)", exactly like the example in #14.
fe...@gmail.com <fe...@gmail.com> #16
Same thing here. Having this feature would be awesome.
ma...@gmail.com <ma...@gmail.com> #17
Any chance to see this request implemented anytime soon?
Until now, I rely on reverse geocoding to circumvent the issue, which is a kind of hack:
Step 1: get place details
Step 2: reverse-geocode lat/lng returned by step 1. Hopefully, you'll find your place components, with their place_id.
But reverse geocoding returns fewer results now (seehttps://issuetracker.google.com/issues/35829979 ). Therefore, I see more and more failures in my logs.
Thanks
Until now, I rely on reverse geocoding to circumvent the issue, which is a kind of hack:
Step 1: get place details
Step 2: reverse-geocode lat/lng returned by step 1. Hopefully, you'll find your place components, with their place_id.
But reverse geocoding returns fewer results now (see
Thanks
de...@gmail.com <de...@gmail.com> #18
+1 Trying to get detailed information about a larger area would be significantly simplified if the place_id for each component were provided...
fo...@google.com <fo...@google.com> #19
Moving PlacesAPI bugs to new PM
se...@gmail.com <se...@gmail.com> #20
Another star for this issue, I also need that
br...@gmail.com <br...@gmail.com> #22
+1
kr...@gmail.com <kr...@gmail.com> #23
Hello google ? Have the same issue as #14.
ai...@gmail.com <ai...@gmail.com> #26
+1 Same (#14 and #15) situation here.
I'd say anyone working with Places API in a hierarchical fashion will hit the same problem. For any further exploration of the Places info, especially when mixed with local/business/app-specific data, the place_id is the only reliable element that can be used to identify each region, since any name/text provided for address components could/will change for each different language supported by the API. Even if the app is restricted to one language, the official name of any component could/will change at any time.
I will add my specific use case to those already provided. In my crowdfunding platform, each project is "based" on a city/locality that is selected by the author. When users visit the page of a crowdfunding project we give them the ability to discover other projects in the *same administrative area*, eg. a Project based on Dallas will have a link to see other projects in Texas, a project in Frankfurt a link to the state of Hesse, inside Germany, etc. It must be noted that this can't be geographically computed by doing calculations with areas and the lat/lon of the city. Many business cases require working at an administrative level because of social, financial, tax, historical reasons…
This is easy and fast to accomplish by looking up local data, eg. projects, that have same place_id on their eg. `administrative_area_level_1` attribute (or area_level_2, or country…) and in return this kind of exploration is only possible in a performant way by pre-storing the IDs of the administrative chain at different levels for a given location:
locality country admin_1 admin_2 admin_3 Other app-speficic-data
---------- ---------- ---------- ---------- ---------- ------------------------
ChIJ...IgQ ChIJ...99m ChIJ...3EI ChIJ...vtk ChIJ...x8K PROJECT_ID, TEAM_ID
Right now the only safe-ish workaround to implement the retrieval of each hierarchical level is the workaround described herehttps://stackoverflow.com/questions/49590171/hierarchical-translated-results-of-a-placeid-using-google-places#answer-49600674 .
It's a non-optimal solution for us, the consumers or for Google as data provider since it -at least- duplicates the number of requests to be made to retrieve the info of a city/locality. Including the place_id for each component in the API responses, will simplify this use case and in general improve the discoverability of the data. From the outside, it looks like an easy thing to do without breaking any backward compatibility and the place_id is already ubiquitous in the responses provided for the geocoding results, but of course, we don't know the internals required to implement this.
Google, the issue has been open now for +3 years. It would be fantastic to get the place_id added to the components but if this is not going to be added, please close the ticket to make it clear, so we can all move forward.
I'd say anyone working with Places API in a hierarchical fashion will hit the same problem. For any further exploration of the Places info, especially when mixed with local/business/app-specific data, the place_id is the only reliable element that can be used to identify each region, since any name/text provided for address components could/will change for each different language supported by the API. Even if the app is restricted to one language, the official name of any component could/will change at any time.
I will add my specific use case to those already provided. In my crowdfunding platform, each project is "based" on a city/locality that is selected by the author. When users visit the page of a crowdfunding project we give them the ability to discover other projects in the *same administrative area*, eg. a Project based on Dallas will have a link to see other projects in Texas, a project in Frankfurt a link to the state of Hesse, inside Germany, etc. It must be noted that this can't be geographically computed by doing calculations with areas and the lat/lon of the city. Many business cases require working at an administrative level because of social, financial, tax, historical reasons…
This is easy and fast to accomplish by looking up local data, eg. projects, that have same place_id on their eg. `administrative_area_level_1` attribute (or area_level_2, or country…) and in return this kind of exploration is only possible in a performant way by pre-storing the IDs of the administrative chain at different levels for a given location:
locality country admin_1 admin_2 admin_3 Other app-speficic-data
---------- ---------- ---------- ---------- ---------- ------------------------
ChIJ...IgQ ChIJ...99m ChIJ...3EI ChIJ...vtk ChIJ...x8K PROJECT_ID, TEAM_ID
Right now the only safe-ish workaround to implement the retrieval of each hierarchical level is the workaround described here
It's a non-optimal solution for us, the consumers or for Google as data provider since it -at least- duplicates the number of requests to be made to retrieve the info of a city/locality. Including the place_id for each component in the API responses, will simplify this use case and in general improve the discoverability of the data. From the outside, it looks like an easy thing to do without breaking any backward compatibility and the place_id is already ubiquitous in the responses provided for the geocoding results, but of course, we don't know the internals required to implement this.
Google, the issue has been open now for +3 years. It would be fantastic to get the place_id added to the components but if this is not going to be added, please close the ticket to make it clear, so we can all move forward.
de...@gmail.com <de...@gmail.com> #27
+1 It's been over a year since I last visited this issue and I'm still awaiting some sort of news or update on when or if this will ever be implemented. It's triaged as a "NeatIdea", I'm not sure what that actually means... I see it more as a fundamental concept that should have been in place since the beginning; there's nothing really neat or profound about it, just something that should be expected.
sm...@gmail.com <sm...@gmail.com> #28
Please I need this feature. Can we expect it in this year?
eu...@gmail.com <eu...@gmail.com> #31
+1
Are you going to implement it? Are there any alternatives?
Are you going to implement it? Are there any alternatives?
iv...@google.com <iv...@google.com>
ka...@kaime.info <ka...@kaime.info> #32
+1
st...@google.com <st...@google.com>
ar...@google.com <ar...@google.com>
ga...@gmail.com <ga...@gmail.com> #33
+1
eu...@codeart.us <eu...@codeart.us> #34
+1
kr...@gmail.com <kr...@gmail.com> #35
Where is this
mj...@mattjanssen.com <mj...@mattjanssen.com> #36
+1
lu...@gmail.com <lu...@gmail.com> #37
I would prefer a higher cost of the API call with all the info, rather than calling Geocoding several times. Waiting for it.
+1
+1
td...@gmail.com <td...@gmail.com> #38
Same problem, but it seems any solution is in standstill for more than 5 years. I guess its a better business to force more calls from the consumers...
ap...@gmail.com <ap...@gmail.com> #39
This feature is very helpful specially for my use-case... I'm building an Ecommerce platoform. Hope this feature gets attention from Google
e....@gmail.com <e....@gmail.com> #40
+1
st...@emitto.io <st...@emitto.io> #41
+1
ch...@gmail.com <ch...@gmail.com> #42
+1
al...@gmail.com <al...@gmail.com> #43
+1
[Deleted User] <[Deleted User]> #44
+1
de...@gmail.com <de...@gmail.com> #45
+1
tr...@gmail.com <tr...@gmail.com> #46
+1
xa...@gmail.com <xa...@gmail.com> #47
+1
po...@gmail.com <po...@gmail.com> #48
I want get city name only from this respponse because the city name shown from diff diff indexing so how can I get from all indexing at same time
JSON
0
long_name : "Ratina"
short_name : "Ratina"
types
0 : "neighborhood"
1 : "political"
1
long_name : "Tampere"
short_name : "Tampere"
types
2
long_name : "Finland"
short_name : "FI"
types
3
long_name : "33100"
short_name : "33100"
types
0 : "postal_code"
JSON
0
long_name : "Ratina"
short_name : "Ratina"
types
0 : "neighborhood"
1 : "political"
1
long_name : "Tampere"
short_name : "Tampere"
types
2
long_name : "Finland"
short_name : "FI"
types
3
long_name : "33100"
short_name : "33100"
types
0 : "postal_code"
bl...@novadevs.com <bl...@novadevs.com> #49
+1
ki...@hvr.world <ki...@hvr.world> #50
+1
an...@noveogroup.com <an...@noveogroup.com> #51
Comment has been deleted.
ja...@gmail.com <ja...@gmail.com> #52
Any progress on this one?
ma...@gmail.com <ma...@gmail.com> #53
Any news?
ke...@gmail.com <ke...@gmail.com> #54
+1
th...@gmail.com <th...@gmail.com> #55
+1
dt...@gmail.com <dt...@gmail.com> #56
+1
Description
However, we don't have place_id of each of these components. To fetch them, another query is required.
For instance, with Paris, France:
or:
Today, components look like this:
"address_components": [
{
"long_name": "Paris",
"short_name": "Paris",
"types": [
"administrative_area_level_2",
"political"
]
},
{
"long_name": "Île-de-France",
"short_name": "IDF",
"types":
[
"administrative_area_level_1",
"political"
]
},
{
"long_name": "France",
"short_name": "FR",
"types": [
"country",
"political"
]
}
]
It would be great to have place_id for each component:
"address_components": [
{
"long_name": "Paris",
"short_name": "Paris",
"types": [
"administrative_area_level_2",
"political"
],
"place_id": "ChIJD7fiBh9u5kcRMCqLaMOCCwM"
},
{
"long_name": "Île-de-France",
"short_name": "IDF",
"types":
[
"administrative_area_level_1",
"political"
],
"place_id": "ChIJF4ymA8Th5UcRcCWLaMOCCwE"
},
{
"long_name": "France",
"short_name": "FR",
"types": [
"country",
"political"
],
"place_id": "ChIJMVd4MymgVA0R99lHx5Y__Ws"
}
]
Thanks
*********************************************************
For developers viewing this issue: please click the 'star' icon to be
notified of future changes, and to let us know how many of you are
interested in seeing it resolved.
*********************************************************