Noticed a problem with geocoder api.
https://autocomplete.geocoder.ls.hereapi.com/6.2/suggest.json?apiKey={apiKey}&in=countryCode%3ALTU&query=kreves%20pr.%2067
top 2 results seem good but why 2 of them?
Addresson both of them seem identical but postalCodes are difirent and the one with 50355 doesn't even exists when I check in other places.
Maybe I need to do some filtering?
results:
Couldn't figure out why autocomplete api gave such results (same problem form most addresses) started using their lookup api instead (https://developer.here.com/documentation/geocoding-search-api/dev_guide/topics/endpoint-lookup-brief.html) seems to be working corectly.
In Lithuania country many postal codes have very small areas therefore between those areas exist many borders as well. This address kreves pr. 67 LTU is on such border between pc 50355 and pc 50357. Of course perhaps pc 50355 doesn't exist in reality as well.
This is not Geocoder API issue but map core data issue.
For such issues please report on https://mapcreator.here.com/ . There you can edit map data as well.
Related
Im using the places v1 autosuggest entry point, with the following request
https://places.api.here.com/places/v1/autosuggest?app_id=APP_ID&app_code=APP_CODE&q=550+5e+avenue&at=45.44569010000001%2C-73.66412120000001&size=5&result_types=address%2Cplace&addressFilter=countryCode%3Dca
So basically Im searching within Canada for places and address. The address Im looking for is in Montreal however there are two districts with that address, Verdun, and Lachine, however in the response there is no way to differentiate them without visiting the href to go to the full places details. Is there a way to display the district so its possible to differentiate the results?
Notice that the endpoint of 'autosuggest' does not support this district field.
However the 'search' endpoint shows the district. YOu an use this one instead.
See: https://developer.here.com/documentation/places/topics_api/media-type-search.html
Im trying our different flight api's from sabre, I understand from reading the data Im getting back is limited in development but Im not sure if it really can be THAT limited or its me doing something wrong.
1: InstaFlights Search
First I use the citypairs lookup to show city pairs, then use them for the instasearch,
The problem is unlike I use NY or London (there were 2 other cities working fine), for almost ALL other cities, Im getting no response.
I know data is limited but since the citypairs api already returns VERY limited data, but is it really THAT limited? Feeling like I must be doing something wrong because I cannot image, that api to work (in dev) only for 3 cities on 3 different dates :-/
destination api
here I use first the supported cities api, then use results to use the multi airports api, then use that for destination api.
Again, same here, only 2/3 cities actually work. Since in the destination api, UNLIKE the instaflights api, the changes of 'matches' are higher as any destination could be shown for the picked origin. HERE AGAIN almost no results, BUT for about 3 cities.
If anyone who has some experience with sabre, could help out it would be great- just trying to figure out if its me whos using it wrong or no. Thanks!
Can you please provide the city pairs that seem to be failing for you? I just did a test of both APIs (InstaFlights and DestinationFinder) and was able to obtain results with the city pairs provided there. I changed the point of sale to FR and obtained PAR-ATH, and that worked. Also worked with ABE-MCO which is the first city pair I obtain when using POS US.
The testing environment for this API but you should be not limited to just three cities.
google has an API for downloading search suggestions:
https://www.google.com/support/enterprise/static/gsa/docs/admin/70/gsa_doc_set/xml_reference/query_suggestion.html
unfortunately, as far as i can tell, these results are specific to your location. for an analysis, i would like to be able to define the city/location that google thinks it is making the suggestion to. here's what happens when i scrape from dar es salaam, tanzania:
http://suggestqueries.google.com/complete/search?client=firefox&q=insurance
["insurance",["insurance","insurance companies in tanzania","insurance group of tanzania","insurance principles","insurance act","insurance policy","insurance act tanzania","insurance act 2009","insurance definition","insurance industry in tanzania"]]
i understand that a vpn would partially solve this issue, but only by giving me a different location and not lots of locations. is there a reasonable way to replicate this sort of thing quickly and easily from, say, the 100 largest cities in the united states?
confirmation that results differ within the usa-
thanks!
Google will use your IP and your location history (if turned on) to determine your location.
To be able to go around it, you can spoof your IP while logged off your google account (but I don't know if google will consider it a trial of hacking no matter what your intentions are).
Another way is to use Tor browser (even though it is not it's original purpose). You can configure tor to exit from a certain country using the Exitnode parameter in the torrc config file
As found in the docs:
ExitNodes node,node,…
A list of identity fingerprints, country codes, and address patterns of nodes to use as exit node
But if you want a fast way to do it, I don't think that's possible since google wants to know the real location of the users and have put a lot of effort into making such tricks fail.
The hl param for interface language changes the search results, but I can't tell if it's actually changing the location. For example:
http://suggestqueries.google.com/complete/search?client=chrome&q=why&hl=FR
Here's an example with 5 different values of hl:
http://jsbin.com/tusacufaza/edit?js,output
I modified one of Geocodezip's examples to use my fusion table. The table is 40+ rows but only the first 11 are displaying on the map. Everything geocodes OK from within the fusion table but not here. Can someone please explain why.
http://6tango.com/Map_Examples/fusion_with_geocode.html
[EDIT] I just noticed that Geocodezip's example only has 11 points. Guess I'd better look at his javascript closer.
On another note, is there an easy way to show a block of code here without manually adding spaces to each line? (please excuse my ignorance)
PS - Thank you Geocodezip for all your examples. For a newbie like me they are a God-send!
You are geocoding the entries in the table on the fly, check for the case when status != google.maps.GeocoderStatus.OK, you will find you are getting OVER_QUERY_LIMIT responses.
I would suggest geocoding the addresses offline (or capturing the coordinates from the points that are displayed) and adding the resulting coordinates in additional columns of the table to avoid the problem.
I am trying to get the distance traveled on a transit route -- particularly San Francisco MUNI, but the standards NextBus, GTFS, and Google Maps API appear to be universal. I'm comfortable using any of these APIs, I'm just not sure how to go about this problem.
The easy way - ask Google Maps (this using webservices, but there is also the javascript API):
http://maps.googleapis.com/maps/api/directions/json?origin=37.7954199,-122.397&destination=37.7873299,-122.44691&sensor=false&mode=transit&departure_time=1348109609&alternatives=true
this JSON includes distance traveled, but there are two issues:
Google does not allow you to use this data unless you're displaying a map, which I don't want to do
I would need to ensure that the distance returned is for the correct route/line, since it can/will give multiple routing options. This is probably doable but would require more logic.
EDIT: using alternatives=true (or provideRouteAlternatives: true using the javascript API) only returns a maximum of 3 routes, which here in SF often doesn't include the route I'm looking for (other transit agencies, multiple lines on the same route, etc). So this isn't such a great option.
NextBus:
example route config:
http://webservices.nextbus.com/service/publicXMLFeed?command=routeConfig&a=sf-muni&r=1
The coordinates for each stop are given, but connecting the dots on those is not the same as the route taken -- it will cut corners, etc, and I need this to be accurate. The actual route taken is given under <path>/<point>, but I don't see any obvious correlation between stop and path coordinates. Plus, NextBus says in their documentation (p.10 near the bottom) that you should NOT connect points between <path> segments, they're only meant for drawing on a map and can overlap.
GTFS:
The GTFS data also separates stop and "shape" coordinates (like NextBus paths). Unfortunately, the coordinates are slightly different for the same stops between NextBus and GTFS (rounding), though the stop ID/tags are the same. Also, the data files are in the megabytes, and I need to use this for a mobile app. I suppose I could put all the data in a database and query that, but that still leaves figuring out how to correlate the stops with the shape. The "shapes_distance_traveled" column in the shapes.txt file is especially promising. MUNI chooses to leave the optional "shapes_distance_traveled" field out of stop_times.txt, though.
Any advice would be appreciated, I understand this seems like an epic task to get a simple value. Maybe I'll just throw a map in to legitimately use the distance :)
Instead of using Google Maps, I would look into the un-encumbered licensing of OpenStreetMap. There are multiple
routing engines that can use OSM data. Personally, I would use routing in PostGIS or SQLite, but depending on your skillset you might choose another.
You've clearly done your research, (+1), and as you said, the easy way is to ask Google. If it is worth for you then you might want to look into purchasing a business licence to use the Google Maps API, and negotiate with them about the requirement of displaying a map. That's the only legal way I can think of with the Google API. Alternatively, you can try building you own routing engine with data from the TIGER data set, which is freely available from the US Census Bureau, but again, as you said, it may seem like an epic task. :-)