I'm using the HERE traffic API such as:
http://traffic.cit.api.here.com/traffic/6.0/incidents.xml?bbox=43.8,-79.5;43.6,-79.4&app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg&status=active&maxresults=50
The XML returns:
...
<RDS-TMC>
<ORIGIN>
<EBU_COUNTRY_CODE>C</EBU_COUNTRY_CODE>
<TABLE_ID>9</TABLE_ID>
<LOCATION_ID>04184</LOCATION_ID>
<LOCATION_DESC>DUFFERIN ST/EXIT 364</LOCATION_DESC>
<RDS_DIRECTION>-</RDS_DIRECTION>
</ORIGIN>
<TO>
<EBU_COUNTRY_CODE>C</EBU_COUNTRY_CODE>
<TABLE_ID>9</TABLE_ID>
<LOCATION_ID>04187</LOCATION_ID>
<LOCATION_DESC>HWY-11A/AVENUE RD/EXIT 367</LOCATION_DESC>
<RDS_DIRECTION>-</RDS_DIRECTION>
</TO>
<DIRECTION>+</DIRECTION>
<ALERTC>
<TRAFFIC_CODE>701</TRAFFIC_CODE>
<QUANTIFIERS>0</QUANTIFIERS>
<DESCRIPTION>(Q) (--//set of//sets of) roadwork</DESCRIPTION>
<ALERTC_DURATION>L</ALERTC_DURATION>
<ALERTC_DIRECTION>1</ALERTC_DIRECTION>
<UPDATE_CLASS>11</UPDATE_CLASS>
<PHRASE_CODE>E1</PHRASE_CODE>
<EXTENT>3</EXTENT>
<DURATION>0</DURATION>
</ALERTC>
</RDS-TMC>
...
Is there any API to turn the RDS-TMC section information to geometries (points):
Maybe something like this for example:
<Path><Point lat,long /><Point lat,long />[snip]<Point lat,long /><Point lat,long /></Path>
Anything that returns the road geometry (lat, long) will do. Thanks for your assistance.
Could you use the latitude and longitude elements within the geoloc/origin ? Maybe store these in a look up table? I know not all elements are always present, so you may need to use Street Intersection Gecoding in the Geocoding API as well. Street geometry is available from the Enterprise Routing API
I’m not aware of an API that does exactly what you want (then again, I’m not too familiar with HERE services, so there may be something I’ve missed).
The XML you are posting looks like a decoded TMC message, with the <origin> and <to> elements describing the start and end of the affected route. To work even over low-bandwidth connections such as RDS, TMC just transmits 16-bit location codes and relies on lookup tables in the receiver for all the rest; HERE seems to be doing some of that work for you by resolving the description for eqach location.
Three elements in each of these uniquely identify the location: <ebu_country_code> and <table_id> identify the location table, and <location_id> identyfies a unique location within that table. You could decode this into coordinates by obtaining the location table (rather, one location table for each area you want to cover). These will give you one point each for <origin> and <to>. For longer stretches of road, where there are additional TMC locations between these two points, you could walk through the table and obtain these as well (on highways, there is usually al location for each junction and each rest area). However, it would still not give you a complete road geometry—you would need to use map data for that.
A list of sources for TMC location datasets (not exhaustive, though) is here.
Related
When sending a request to https://autocomplete.geocode.ls.hereapi.com/6.2/suggest.json?query=Вильнюс with an indication of cyrillic nothing comes and with a latin https: //autocomplete.geocode.ls.heraapi.com/6.2/suggest.json?query=Viln all is well. Tell me what the problem is or what I'm doing wrong?
You're not doing anything wrong. Autocomplete is designed to give you addresses that contain (perfectly match) your input string, and the results are sorted by relevance.
When you make your query in russian and provide only "Вильнюс" as input, the service is finding a lot of results (street names) that it considers are more relevant than the city. The city name is also found, but since the service doesn't think that this is what you're searching for, it puts the city much lower in the results list. You don't see it because you're limiting your query to give you only the first 10 matches (with the maxresults=10 parameter), but if you change the maxresults parameter to 20, for example, you will see that Vilnius appears in the 16th place of the API response.
If you want the service to better understand what is the thing you're querying for, you'll need to provide additional information. For example, if you continue typing and your input string is now "Вильнюс " (with a space at the end) or "Вильнюс Л" (a space and another letter), the service will understand what you mean and will return the result you want.
Another way of providing more information to change the way the service ranks the results is by adding a spatial filter, like the country, mapview, or prox parameters mentioned in the API Reference section of the documentation. Alternatively, the resultType parameter can help you filter out all the results with street names and return only city names, if that's what you want. These are just some options available, the one that is right for you will depend on your use case.
Assuming a graph like this:
(Thanks to https://neo4j.com/blog/neo4j-2-0-ga-graphs-for-everyone/ )
(Not shown but assume all countries, all artists, and all recording contracts are in the graph)
What would the CYPHER be for:
Starting with United Kingdom, return one path for each country where there is at least one recording contract
It doesn't matter which path is returned, just that it's a single path
Should return (United Kingdom)<-[]-(Iron Maiden)-[]->(Epic)-[]->(United States), but not (United Kingdom)<-[]-(Hybrid Theory)-[]->(Mad Decent)-[]->(United States) or (United Kingdom)<-[]-(Iron Maiden)-[]->(Columbia)-[]->(United States), for example
Return a single path for each of any two countries that are connected
Should return one path for (United Kingdom)-[]-(United States), one for (Japan)-[]-(Canada), etc. Bonus points for LIMIT 20 limiting it to either 20 paths or 20 country nodes
Also does not matter which path is returned, just that it's a single path
Edit: I've tried various combinations of MATCH (c1:Country)-[]-(c2:Country), MATCH p=((c1:Country)-[]-(c2:Country)), WITH, and UNWIND. I've also tried to use FOREACH to return only one path, but can't quite get the formula right.
This is easier if you are using subqueries (Neo4j 4.1.x or higher). That's because the subquery can help scope the operations you need to perform (collect(), in this case) to expansions and work from a single country, per country, instead of having to perform it across all rows for the entirety of the query, which could stress the heap.
In reality, since the number of countries are low, it won't be a problem, but it's a good approach to use when dealing with larger sets of nodes.
MATCH (country:Country)
CALL {
WITH country
MATCH path = (country)<-[:FROM_AREA]-(:Artist)-[:RECORDING_CONTRACT]->(:Label)-[:FROM_AREA]->(other:Country)
WHERE id(country) < id(other)
RETURN other, collect(path)[0] as path
LIMIT 20
}
RETURN country, path
LIMIT 20
Let's look at what this is doing.
We MATCH to :Country nodes.
Per country we will MATCH to the pattern you're looking for. If these are the only such paths and labels in the graph, then you can omit the labels in the pattern, as the relationship types should be enough to find the correct nodes.
The WHERE id(country) < id(other) is here to prevent mirrored results. For example, in the course of the query if we find a path from (United Kingdom)-[*]-(United States), and we also find a path the other direction, for (United States)-[*]-(United Kingdom), you probably don't want to return both. So we place a restriction on the graph ids so that only one of these will meet the restriction, and the mirrored result gets filtered out.
We use RETURN other, collect(path)[0] as path to get a single path per the country and other nodes. Remember that this is happening inside a subquery being called per country node, so even though country is not present here, this operation is being performed for a specific country node.
When we aggregate (such as with this collect(path), the grouping key (usually the non-aggregation variables) become distinct, so for the country and the other country, this will collect all the paths between them and then take the first of that list of paths, so we get our single path between two distinct countries.
We LIMIT the subquery results to 20, since we know in total we don't want more than 20 paths, so per country we don't want more than 20 paths either. This might be a bit redundant for this case, but when the query is more complex it is the right approach to make sure you're not doing more work than is needed.
We also have another LIMIT outside the subquery, so that if there are only a few countries processed, with a few paths per country, the total paths won't exceed 20.
Hello i am using simple google map places api to get near by atms for users. My client lives around new york and for some strange reason api shows zero results for that place, but works fine near me (pakistan) . I searched for it a little and found out it was google's issue and some other places were also experiencing the same problem. But i never quite found any solution for this.
This is the get call i use
https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=40.7128,74.1059&radius=10000000&keyword=atm&key=MY_KEY
I would really appreciate the help. Thank you :)
Google place nearby search maximum 50,000 meters (31 miles) . if you try enter more than 50,000 it not work proper.
There is another way for find all ATM in a city. google provide Text Search Requests
https://maps.googleapis.com/maps/api/place/textsearch/json?query=atm+in+Reno,NV,89501,USA&key={API_KEY}
query = keyword + in + city Name
for get city name using latitude longitude
http://maps.googleapis.com/maps/api/geocode/json?latlng=39.52963,-119.81380&sensor=true
For more information how to get city name using latitude longitude
https://developers.google.com/maps/documentation/geocoding/start?csw=1#ReverseGeocoding
for more information about how to use Text Search Requests
https://developers.google.com/places/web-service/search
OR (second way)
There is another way for find all ATM in a city.
Open Google Maps .
create 10-12 or more points latitude , longitude value to trigger
request.
Then use a loop to find all places within these points.
If you want more appropriate results, increase first trigger points
for your requests.
- It is just a logic i created in php.
$triggerPoints = array("lat1,long1", "lat2,long2", "lat3,long3",....);
foreeach(triggerPoints as $tP){
$requestUrl = "https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=$tP&radius=[YOUR_RADIUS_VALUE]&type=[YOUR_TYPE]&name=panera&key=[YOUR_KEY_HERE";
$results = file_get_contents($requestUrl);
//Do what you want with response JSON data
}
SHORT ANSWER: Use logical types with your needs.
In my case i used food types instead of supermarket. In some cases, my local market named A101 wasnt found under supermarkets. To find which keywords is best for you, you can search below url with your location and map_key and find most common keywords under types for each query and use it.
https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=40.986527896166244,%2029.24326049097467&rankby=distance&keyword=a101&key=YOUR_MAP_KEY
We have a program which calls the Google Geocoding API passing an address. we would like to understand for which of the address, the latitude and longitude values are very correct and for which of them it is approximated.
in the response, there are some tags like address_component which can have multiple "type" tag. there is also location_type under 'geometry'-->'location'
There is also 'type' directly 'result'
we are going which the following logic to understand if the lat and long are accurate.
Check for the multiple "type" under "address_components" and if we find either value "route" or "street_number" in any of the type tags, then it is very accurate.. should we use anyother tags from geocoder response like "location_type" under "location" or "type" under "result" tags.
There is some information on Google Geocoding info, but did not figure out if there is a kind of logic we could apply.
Regards
Siva
The location_type tells you the accuracy of that result, partial match tells you the geocoder did not return an exact match for the request.
See the documentation: Results: location_type/partial match
geometry contains the following information:
location contains the geocoded latitude,longitude value. For normal address lookups, this field is typically the most important.
location_type stores additional data about the specified location. The following values are currently supported:
"ROOFTOP" indicates that the returned result is a precise geocode for which we have location information accurate down to street address precision.
"RANGE_INTERPOLATED" indicates that the returned result reflects an approximation (usually on a road) interpolated between two precise points (such as intersections). Interpolated results are generally returned when rooftop geocodes are unavailable for a street address.
"GEOMETRIC_CENTER" indicates that the returned result is the geometric center of a result such as a polyline (for example, a street) or polygon (region).
"APPROXIMATE" indicates that the returned result is approximate.
partial_match indicates that the geocoder did not return an exact match for the original request, though it was able to match part of the requested address. You may wish to examine the original request for misspellings and/or an incomplete address.
Partial matches most often occur for street addresses that do not exist within the locality you pass in the request. Partial matches may also be returned when a request matches two or more locations in the same locality. For example, "21 Henr St, Bristol, UK" will return a partial match for both Henry Street and Henrietta Street. Note that if a request includes a misspelled address component, the geocoding service may suggest an alternative address. Suggestions triggered in this way will also be marked as a partial match.
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.