I am building an app for a federal government client using the Bargain Finder Max SOAP API. They need to adhere to the Fly America Act: any flight that leaves the US or arrives in the US must use a US flagged carrier.
I have tried to use the IncludeVendorPref and included all US carriers; however, on flights such as ALGIERS (ALG) to New York (JFK) I cannot find a solution because the route may go from ALG to London via British Airways and then London to JFK via American. Because not all flights are American (because of the IncludeVendorPref filter I have on), it does not find this solution even though it is valid because you are taking an American carrier back from a foreign country (it is okay that you are going from a foreign country to another foreign country - i.e. Algeria to London on a foreign carrier).
Does anyone have any advice on how to handle this? Is there an easy way to adhere to the Fly America Act?
There is no specific request that will meet what you want, at least as far as I know.
There are 2 ways in which I can think you can accomplish this:
1. By requesting 200 flights, in order to have more diversity, including the IncludeVendorPref qualifier for all US carriers with PreferredLevel="Preferred". The bad part is that you would have to end up doing the filtering on your side. I think this would be the best way, as it would give you the most heterogeneity without loosing too many itineraries.
2. By calling the service twice, once for the US connection and once for the trip outside. This has several disadvantages, for example it would make it really difficult to create itineraries based on the 2 responses, and it would require to create separate tickets, as those would be 2 separate itineraries.
If neither option suits your needs, I recommend you to contact the help desk to see if there would be another option that I didn't consider.
Related
The HERE api seems really picky about what is uses for the q parameter in API calls. According to the documentation you can use a street address, partial address, name of place, etc (documentation: https://developer.here.com/documentation/places/topics/free-text-search.html)
Im trying to take an address and return the name of the store, building, business at that location (a few million of these) In some cases I have a human typed name of the place at the address but this can be quite messy and inaccurate in a lot of cases so Im trying not to use this information. Address however Im quite confident in.
in summary Im trying to provide here with an input like "15300 Cedar Ave, Apple Valley, MN 55124" and output "Best Buy"
Here seems to be really finicky on what your q input is..
When I put in the address and geocode info, Best Buy doesn’t appear on the results list
q=15300 Cedar Ave, Apple Valley, MN 55124
in=44.7287,-93.2147;r=800
https://places.demo.api.here.com/places/v1/discover/search?q=15300+Cedar+Ave%2C+Apple+Valley%2C+MN+55124&in=44.7287%2C-93.2147%3Br%3D800&Accept-Language=en-US%2Cen%3Bq%3D0.9&app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg
Based on this Im thinking maybe this info just isnt in here's database, but when I run this query which includes best buy in the search it finds it right away at the correct address!!
q=best buy 15300 Cedar Ave, Apple Valley, MN 55124
in=44.7287,-93.2147;r=800
https://places.demo.api.here.com/places/v1/discover/search?q=best+buy+15300+Cedar+Ave%2C+Apple+Valley%2C+MN+55124&in=44.7287%2C-93.2147%3Br%3D800&Accept-Language=en-US%2Cen%3Bq%3D0.9&app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg
It seems like a no-brainer to me that HERE would use the q value as an address search but that doesnt always appear to be the case. Looking for guidance on how to make this smarter
if the point of interest(POI) needs to be searched by specific address, then q is significant for fetching the records. As the API will fetch only those records which have those keywords in that area.
if POIs need to be searched at specific lat-long and around defined meter range, then q is not significant.
https://places.demo.api.here.com/places/v1/discover/around?in=44.7287%2C-93.2147%3Br%3D800&Accept-Language=en-US%2Cen%3Bq%3D0.9&app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg
Is it mandatory for you to pass address all the time, or lat-long can also work ?
For routes that start and end in the US, HERE fails to suggest a route that goes through Canada even when I choose 'mode=fastest', and via Canada would clearly be the fastest route (traffic disabled).
e.g. Detroit to Buffalo
HERE We Go
HERE Routing API gives the same as HERE We Go. I use traffic disabled, hence a route through Canada is definitely the fastest: https://route.api.here.com/routing/7.2/calculateroute.json?waypoint0=42.33239,-83.04887&waypoint1=42.95594,-78.90584&mode=fastest;car;traffic:disabled&app_id=______&app_code=____
These places are just inside the US border. If I edit one co-ordinate to fall just inside the Canadian border, a route through Canada is recommended.
I can't find any restrictions that seem to be applied that would prevent routes going through Canada. I've tried examples in other countries which seem to be fine (e.g. a route starting and ending in Sweden was chosen to pass through Norway). What is going on here?
Can you please use fleet telematics with advance mapping options. Also if waypoint doesn't work, you can pass link ID or street to get the accurate result. please refer below documentation for more reference.
https://developer.here.com/documentation/fleet-telematics/api-reference.html
Also report the map team if the route is still incorrect using feedback API :
developer.here.com/documentation/map-feedback/dev_guide/topics/quick-start-submit-feedback.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.
I have a CSV list of university names around the world - about 13,000 university names. I'm looking for a way to pull the addresses of these universities. Google Maps API / Google Places API looks promising, but requires lat/long to map the locations.
End game is to mark to each school as a 1 if the school is in the US, and 0 if the school is outside of the US.
Any thoughts on how to search these colleges in maps and pull out the addresses - or at least the country?
Example:
is there nothing else in the csv, only the names? that's going to make it hard, i'd bet the names aren't always unique in the world.
you could write something that had different passes at biting the apple - for instance, if the university has a state name in it, check those off as 1's - then find another logic to use to take "another bit" until the apple is gone.
On top of #WEBjuju's answer, since you only want to mark if the school is in US, or outside of US, you can use the "country" type in Place Types in the Google Places API, by setting the option as country='us'.
https://developers.google.com/places/supported_types?csw=1#table2
You may also want to cross check with this list of schools.
https://www.4icu.org/reviews/index2.htm
https://en.wikipedia.org/wiki/Lists_of_universities_and_colleges_by_country
I am working with the Google Analytics Reporting API. The problem I am running in to is that as far as I can tell the city dimension is not necessarily unique (i.e. multiple cities can have the same name.) So in order to filter to a specific city I need something like ga:country=France;ga:city=Paris which works fine, unless I want everything from Paris OR London. But the OR operator has a higher precedence than the AND operator in the filter expressions, and it doesn't look like there is a way to group expressions together.
So,
Are the strings returned by google analytics for ga:city uniquely identifiy a city?
Is there any way to group expressions together like (ga:country=France;ga:city=Paris),(ga:country=UK,ga:city=London)?
If neither of the above, is there any other workaround?
One of the examples on the reference guide is:
Operating system is (Windows OR Macintosh) AND browser is (Firefox OR Chrome):
ga:operatingSystem==Windows,ga:operatingSystem==Macintosh;ga:browser==Firefox,ga:browser==Chrome
In your situation you could do it in the way of (United Kingdom OR France) AND (Paris OR London) but it would still have your problem if there was a paris in the UK or a london in France.
A workaround would be to make one request where you query the cities in France, and a second different request where you query for the cities in the UK. It would mean making more requests but usually in these kind of cases having smaller but more specific requests is better practice. (And probably easier to manage)