I have noticed that Location IDs coming from the Geocoding Autocomplete API have been changing recently. I rely on location id to identify cities uniquely, so such changes cause us a lot of problems.
For instance city Lodz, Poland has currently location id NT_wTVzyarLKGygLvsTPZ4VYD while it used to be NT_ROlJ6fdWSgsrVm8xPoZ1qD.
As I understand (based on Mismatch of location id between Geocoding Autocomplete and Geocoding), location ID value is based on the attributes identifying the value. In my scenario, I am searching for cities, so there was no change in the hierarchy of data, base names, etc. It is still the same city, in the same country and geographical area.
Shall I expect more changes of location ids for cities? Was the change intentional and what caused it?
Related
My organization has acquired the HERE Navstreets data set. It wishes to update the content while still adhering to the HERE Navstreets data model and relationships.
In this context, it is deemed of value to:
Retain the LINK_ID column as the unique identifier for each street segment.
Make a distinction between the original HERE LINK_ID values and the one added by my organization.
Retain the ability to ingest streets updates from HERE should my organization decide to do so.
In this context, we would like to use a different range of LINK_ID values from the one used by HERE. As an example, if HERE uses values between 10,000,000 and 100,000,000, we would assign only LINK_ID values that are within the range 1,000-9,999,999 (this is only for illustration purposes).
Is this approach already accounted for by HERE for the street data they may get from Map Creator? Is there a specific HERE (for Review or Work in Progress) range of LINK_ID values we should consider?
Based on the HERE KB0015682: Permanent ID concept in HERE Data
Entities with Permanent IDs
Generally, the following feature do have permanent IDs in the HERE Map products:
Lane
Face
Point Features
Administrative Areas (for , Built-up Areas, Districts, and Administrative Areas)
Complex Features (this includes Complex Administrative Area Features as well as Complex Intersections and Complex Roads)
Permanent IDs are globally unique within a specific Object, e.g., a Link ID occurs once globally. However the same Permanent ID can be used among different Object types (e.g., Node, Link, condition, etc.). Note: When a map is upgraded to Intermediate or HERE map, or when a country undergoes administrative restructuring, there may be a change in Permanent IDs.
The following are examples of permanent IDs in the RDF:
Address Point ID
Admin Place ID
Association ID
Building ID
Carto ID
Complex Feature ID
Condition ID
Country ID (which is one of the Admin Place IDs)
Face ID
Feature Point ID
Lane ID
Lane Nav Strand ID
Link ID
Name ID (with some exceptions)
Nav Strand ID
Node ID
POI ID
Road Link ID
Sign ID
Zone ID
Numeric Range of Permanent IDs
Map object IDs (PVIDs) in the extracts use 32-bit integer values to fit in a N(10) scheme. Note: Exception to N(10) scheme can exist. For example, Lane ID is N(12) in length.
The entire range is divided as follows:
Range----------------------------Designation
0000000001 to 0016777215 -> Non-permanent IDs
0016777215 to 2147483647 -> Permanent IDs
The range dedicated to permanent IDs are used for any entity.
The range dedicated to non permanent IDs are used in rare situations where an update is made in a copy of the database instead of in the live database itself and this update results in a new ID. This new ID in the database copy would be in the non-permanent range. The update would also be applied into the live database and this update would receive a permanent ID available in the next scheduled release. A cross-reference is not provided between non-permanent IDs and the eventual permanent ID from the live database.
is it possible to get a geoID for the Geographical Override parameter in the Google Analytics Measurement Protocol from a zipcode or coordinates?
Geographical Override The geographical location of the user. The geographical ID should be a two letter country code or a criteria ID representing a city or region (see Geographical IDs). This parameter takes precedent over any location derived from IP address, including the IP Override parameter. An invalid code will result in geographical dimensions to be set to '(not set)'.
You will need to download the file found at Geographical IDs and then parse it against some kind of world wide zip code list in order to parse your zipcodes into Geoiids.
Sending a zip code to Google analytics isnt going to work it must be a valid GeoId
format of Googles CSV File
The file from google is a CSV with the following columns Criteria ID,Name,Canonical Name,Parent ID,Country Code,Target Type,Status
"1014315","Sunnyvale","Sunnyvale,California,United States","21137","US","City",Active
Geoid 1014315
city Sunnyvale
Cononical name Sunnyvale,California,United States
parent id 21137 (i beleave this is state id in the case of the usa)
country code US
Active
Note: small towns and villages will probably not be listed. You will have to try to find something as close as you can get
For one of my applications, I will let the users choose a City and then an Area. What I want to achieve is that based on the user's city selection, the Area field(which is using the autocomplete from Google Places) to display areas from that City. Eg: If user chooses the city as New York, the Area field should autocomplete only the areas from New York. Is this something which can be achieved?
1] In autocomplete API, pass the "Lat,Long" in "location" parameter and "100000" in "radius" parameter. It will bias search result within 100Km in that city.
Eg: Pass "40.7128,74.0059" for NewYork and it will give you result within 100Km in NewYork city.
OR
2] There is a trick you can use.If a user chooses a city, just add the city name as a prefix in the search string. It will only give the search suggestions in which the user is searching. eg, pass "NewYork" as a prefix in your search string, now type any word, it will only give you results for NewYork city restaurant, cafes, places, etc
You can do it by restricting the results of your autocomplete by a specified area.
Here are the ways that you can use:
Location Biasing - you may bias the results to a specified circle by passing a location and a radius parameter. This instructs the Place Autocomplete service to prefer showing results within that circle. Results outside of the defined area may still be displayed. You can use the components parameter to filter results to show only those places within a specified country.
Location Restrict - it can restrict the results to the region defined by location and a radius parameter, by adding the strictbounds parameter. This instructs the Place Autocomplete service to return only results within that region.
Places Types - you can restrict results from a Place Autocomplete request to be of a certain type by passing a types parameter. The parameter specifies a type or a type collection, as listed in the supported types below. If nothing is specified, all types are returned.
Hope this information helps you.
We are currently using the google trip planning feature on our transit website. The issue we are running into is the fact that when a customer types in a starting point (for example "Queensway" in Kelowna, BC Canada) we get auto-fill results from all over North America. Can the auto-fill results be restricted to a specific province or state? Thanks!
Try using Component Filtering
In a geocoding response, the Google Maps Geocoding API can return address results restricted to a specific area. The restriction is specified using the components filter. A filter consists of a list of component:value pairs separated by a pipe (|). Only the results that match all the filters will be returned. Filter values support the same methods of spelling correction and partial matching as other geocoding requests. If a geocoding result is a partial match for a component filter it will contain a partial_match field in the response.
The components that can be filtered include:
route matches long or short name of a route.
locality matches against both locality and sublocality types.
administrative_area matches all the administrative_area levels.
postal_code matches postal_code and postal_code_prefix.
country matches a country name or a two letter ISO 3166-1 country code.
Note: Each address component can only be specified either in the address parameter or as a component filter, but not both. Doing so may result in ZERO_RESULTS.
A geocode for "Santa Cruz" with components=country:ES will return Santa Cruz de Tenerife in Canary Islands, Spain. Request:
https://maps.googleapis.com/maps/api/geocode/json?address=santa+cruz&components=country:ES&key=YOUR_API_KEY
See this sample: Place Autocomplete Hotel Search for code implementation.
Hope it helps!
I am using the Google Maps Places library to do a search for nearby hospitals, but it returns results that aren't necessary hospitals (but have 'hospital' as one of their types). However, I've noticed that actual hospitals have a hospital icon on the map, so Google must somehow know which establishments are actually hospitals. Does anyone know if the public has access to this data?
This is the icon I'm referring to: https://www.dropbox.com/s/1jfqcayxavjhlyi/Screenshot%202015-03-17%2017.20.19.png?dl=0
Example of request I'm making:
var request = {
location: self.location,
radius: 20000,
types: ['hospital'],
keyword: 'hospital'
};
Example result that isn't a hospital:
{"geometry":{"location":{"k":44.815958,"D":-68.808244}},
"icon":"http://maps.gstatic.com/mapfiles/place_api/icons/generic_business-71.png","id":"de6e60bd70b90ba4cb86afe149a60169553607f1",
"name":"Penobscot Community Health Center",
"opening_hours":{"open_now":true,"weekday_text":[]},
"photos":[{"height":320,"html_attributions":[],"width":320}],"place_id":"ChIJj--4INRKrkwRN0z2XkoJtVU",
"rating":3.1,
"reference":"CoQBdAAAADmf3YA0659efzMbCSPOK6SZttkfus7aWBDhrZZyX63Szl256BRcpz81LH6rIuONldYv256tsN7Zv-N6ZkOkJadlD2VS01bs7C4ierKvGUMyJOJu657xL5MvidF3Tgs9iejeJcXsxjDJYOwtN3m3sbfClfWYVnnIL4hMLYV8P9TnEhBurfJv_30CAG2wp1V73POVGhR-7fz1mCdh4OYWSa3Pw0mPupckoQ",
"scope":"GOOGLE",
"types":["hospital","pharmacy","store","health","establishment"],
"vicinity":"1012 Union Street, Bangor",
"html_attributions":[]}
My guess is there are a couple ways to get around this. You might remove the keyword argument from the API, which acts like a search term rather than a specific match on a type of location like the type field does.
You may want to be careful about your radius value choice.
Next, if you do a search on Google Maps in general you'll get a broad assortment of results. Do you need every result to be an actual hospital or can you do your own filtering afterwards?
If you do your own filtering it looks like type information and even icons are embedded in the result JSON. You might see if there's a distinguishing characteristic between the types of results you want and filter by that. Otherwise, any additional graphical data would not be accessible via the API.