HERE API: Toll cost is not optimized - here-api

I'm exploring HERE API in order to evaluate usefulness to our application. My interest is focused on estimated truck transport cost (toll, vehicle, driver). I'm facing with a problem in generating optimized route between 2 points: from 50.893017,20.615645 to 52.055324,21.010707. Driver cost set to 10, vehicle cost set to 1.
And when I'm using https://fleet.ls.hereapi.com/2/calculateroute.json I get the distance in total 211km with 260.17 PLN cost (including 0 toll cost)
When I'm using https://tce.cit.api.here.com/2/calculateroute.json I get distance 159km with 221.28 PLN (including 38.55 PLN toll cost).
As you can see first API didn't returned cost optimized route. Moreover it looks like the first API is trying to omit toll gates, while this better than go around.
Am I missing something? Why there is so much difference? Parameters for both queries looks similar.
First api parameters (excluding api keys):
jsonAttributes:41
waypoint0:50.893017,20.615645
waypoint1:52.055324,21.010707
detail:1
routelegattributes:li
routeattributes:gr
maneuverattributes:none
linkattributes:none,rt,fl
legattributes:none,li,sm
currency:PLN
departure:
tollVehicleType:3
trailerType:0
vehicleNumberAxles:2
trailerNumberAxles:0
hybrid:0
emissionType:3
fuelType:petrol
trailerHeight:0
vehicleWeight:40t
disabledEquipped:0
hov:0
passengersCount:2
tiresCount:4
commercial:0
heightAbove1stAxle:1m
width:1.8
length:4.41
mode:fastest;truck;traffic:disabled
alternatives:2
driver_cost:10
vehicle_cost:1
Second api parameters (excluding api keys):
jsonAttributes:41
waypoint0:50.893017,20.615645
waypoint1:52.055324,21.010707
detail:1
routelegattributes:li
routeattributes:gr
maneuverattributes:none
linkattributes:none,rt,fl
legattributes:none,li,sm
currency:PLN
departure:
tollVehicleType:3
trailerType:0
vehicleNumberAxles:2
trailerNumberAxles:0
hybrid:0
emissionType:3
fuelType:petrol
trailerHeight:0
vehicleWeight:40t
disabledEquipped:0
hov:0
passengersCount:2
tiresCount:4
commercial:0
heightAbove1stAxle:1m
width:1.8
length:4.41
mode:fastest;truck;traffic:disabled
alternatives:2
driver_cost:10
vehicle_cost:1

Please don't use in URL request nor the domain name tce.cit.api.here.com nor tce.api.here.com or some old parameter names also for fleet.ls.hereapi.com .
This tce.api.here.com is legacy and will be sometimes wrong calculate a toll.
Read please this documentation for tollPass parameter:
Comma separated list of owned passes: Senior_Pass, transponder,
Annual, Nr_of_Days, Nr_of_Months, SunPass, E-Z Pass (last 2 are
examples for real toll transponders). Allows traversal of
'transponder-only' toll booths and allows cost free traversal of
certain toll sections.
Some toll booths and toll sections are allowed to use only by driver who has some toll pass e.g. tollPass=transponder otherwise a driver have to avoid these booths/toll sections to use more long way.
if you try to use e.g. tollPass=transponder parameter for request to fleet.ls.hereapi.com then you will see using toll section.

Related

Empty Results from Here API for the sample zipcodes

When I do the GET Request to the here API with the below zip codes I am getting an empty list. But When I google these zip codes, I can see that they are valid.
Here is the GET Request URL: https://geocode.search.hereapi.com/v1/geocode?qq=postalCode=[Insert-zip-code];country=USA&apiKey=[Insert-API-Key]
Below are the fallowing Zip Codes:
75046
34988
68902
45258
19486
88102
32245
28603
68501
93403
68602
91365
Try with https://geocode.search.hereapi.com/v1/geocode?q=postalCode=zip_code+USA&apiKey=your_api_key
Notice that there is only one q.
The above will work, but in some cases it will give you results not only from the United States.
Keep in mind what the API documentation says for this service:
Address lookup by postal code (SGP, IRL)
(...) This feature is available for these two countries only.
It's only for Ireland and Singapore.
There is an alternative for the United States (and Netherlands), but it requires the zip+4 code.
What is a Zip+4 Code?
A ZIP+4 code uses the basic five-digit code plus four additional
digits to identify a geographic segment within the five-digit delivery
area, such as a city block, a group of apartments, an individual
high-volume receiver of mail, a post office box, or a specific
delivery route
Example: https://geocode.search.hereapi.com/v1/geocode?qq=postalCode=60606-1506&apiKey=your_api_key
Notice that there are two q's.

Number sequences hiding in TravelItineraryReadRQ

I'm using TravelItineraryReadRQ to get information about Price Quotes in pnr. In some cases service response hides number sequences with ("XXXX") even if it was not credit card information. For example:
PQ creation commatnd: WPASU‡EDUFS123456‡FINVOICE*QUW12345‡RQ«
and here is what I get in response:
<tir39:PricedItinerary DisplayOnly="false" InputMessage="WPASU¥EDUFS1XXXX6¥FINVOICE*QUW1XXX5¥RQ" RPH="1" StatusCode="A" StoredDateTime="2018-12-21T09:13" TaxExempt="false" ValidatingCarrier="SU">
<tir39:AirItineraryPricingInfo>
<tir39:ItinTotalFare>
<tir39:BaseFare Amount="1980" CurrencyCode="RUB"/>
<tir39:Taxes>
<tir39:Tax Amount="2541" TaxCode="XT"/>
<tir39:TaxBreakdownCode TaxPaid="false">2265YQ</tir39:TaxBreakdownCode>
<tir39:TaxBreakdownCode TaxPaid="false">276RI</tir39:TaxBreakdownCode>
</tir39:Taxes>
<tir39:TotalFare Amount="4521" CurrencyCode="RUB"/>
<tir39:Totals>
<tir39:BaseFare Amount="1980"/>
<tir39:Taxes>
<tir39:Tax Amount="2541"/>
</tir39:Taxes>
<tir39:TotalFare Amount="4521"/>
</tir39:Totals>
</tir39:ItinTotalFare>
<tir39:PassengerTypeQuantity Code="ADT" Quantity="01"/>
<tir39:PTC_FareBreakdown>
<tir39:Endorsements>
<tir39:Endorsement type="PRICING_PARAMETER">
<tir39:Text>WPASU$EDUFS1XXXX6$FINVOICE*QUW1XXX5$RQ</tir39:Text>
</tir39:Endorsement>
Is there any way to get those numbers?
I believe Sabre has logic on their end due to GDPR requirements that masks credit card info from being viewed unless you have the CC in the correct form of payment field AND your EPR has the "CCVIEW" attribute assigned.
Essentially, Sabre doesn't want CC data stored anywhere but the secured Form of Payment field and they control who can and cannot see that data by using the EPR Keywords (the login info you get from Sabre).
So, for your example, my guess is that Sabre's regex or whatever they use to identify credit card data sees your strings in those fields, assumes they are CC numbers, and masks them. You may want to open a ticket with Sabre to address this, or as Andy K suggested above, try adding CCVIEW to that EPR (although I think that probably won't work).

How can reserve Air Seats for all segments in a given PNR?

I am planning to use the <AirSeatRQ> request using Sabre's SOAP API, but according to the documentation, you have to request a seat assignment for each passenger on each segment with the user's preference.
Something like this according to the example on Dev Studio:
<AirSeatRQ ReturnHostCommand="false" TimeStamp="2011-10-27T15:30:00-06:00" Version="2.0.0">
<!--Repeat Factor=0-->
<Seats>
<Seat BoardingPass="true" ChangeOfGauge="true" NameNumber="1.1" Number="21A" Preference="AN" SegmentNumber="1"/>
</Seats>
</AirSeatRQ>
Also, according to the request documentation, the repeat factor for the <Seats> request is zero. Does that mean that if I want to assign seats for all passengers on all segments do I have to send several requests?
Ideally, I would like to have the seats for all passengers in all segments automatically assigned after reading the PNR. Is that possible through Web Services?
Checking the <PassengerDetailsRQ> XML Schema definition, an <AirSeatRQ> can be sent along. I guess you can perform a standalone <AirSeatRQ> request, but bundling it with the passenger details is easier and save us from making extra requests to Sabre's API.
You have to send a <Seat\> request for each passenger in each segment of the itinerary. This is a working example I did for a two legs itinerary, each leg consisting of two segments for two adults:
I'm omitting most of the passenger details properties and focusing on the AirSeat element:
<PassengerDetailsRQ Version="2.3.0">
<PriceQuoteInfo HaltOnError="true"></PriceQuoteInfo>
<SpecialReqDetails>
<AddRemarkRQ>
<RemarkInfo>
<Remark Code="H" Type="General">
<Text>THANK YOU FOR BOOKING MAURICIO CUENCA AIRLINES</Text>
</Remark>
</RemarkInfo>
</AddRemarkRQ>
<AirSeatRQ>
<Seats>
<Seat NameNumber="1.1" Preference="AN" SegmentNumber="1"/>
<Seat NameNumber="1.2" Preference="AN" SegmentNumber="2"/>
<Seat NameNumber="1.1" Preference="AN" SegmentNumber="3"/>
<Seat NameNumber="1.2" Preference="AN" SegmentNumber="4"/>
</Seats>
</AirSeatRQ>
<SpecialServiceRQ HaltOnError="true">
<SpecialServiceInfo></SpecialServiceInfo>
</SpecialServiceRQ>
</SpecialReqDetails>
<TravelItineraryAddInfoRQ HaltOnError="true">
<AgencyInfo></AgencyInfo>
<CustomerInfo></CustomerInfo>
</TravelItineraryAddInfoRQ>
</PassengerDetailsRQ>
This way, right after the PNR is created, all seats for all passengers in every segment are already assigned and there is no need for further requests asking for seat assignments.
that seems to be the case.
Testing multiple <Seat> elements inside <Seats> returns a schema validation error. Same when using multiple <Seats> elements.
Looks like the only option right now is to send multiple requests, one for each passenger on each segment.

Errors When Calculating Distance Between Two Addresses

I have the following script which is being used in a spreadsheet to calculate the driving distance between two cities or a city and a zip code of another city. It is being run for approximately 25 locations simultaneously. To better explain, I have cell B3 in which I enter a new city every time. The script is then used in cells adjacent to my 25 plant locations to calculate the distance from each of my plants to the variable city.
It uses google sheets built in mapping api and works on 80% of the calculations but returns "TypeError: Can Not Read Property "legs" from undefined. (line 16). The plants that it fails on vary with every new city so its not like it is for certain locations. It is almost like the api times out before it completes some of them. I split it into two separate scripts with a varied name and that worked for a day but then 20% fail again.
To make things slightly more odd, I have another script that sorts the plants based on closest distance to the variable address. When you sort the plants, even the ones with errors go to their correct location based on distance. So it is like the distance script is obtaining the correct disance but displaying the error anyways.
Clear as mud? Would love any input I could get on how to correct the issue or an alternate mapping api that could solve my problems.
function distancecalcone(origin,destination) {
var directions = Maps.newDirectionFinder()
//Set the Method of Transporation. The available "modes" are WALKING, DRIVING, BICYCLING, TRANSIT.
.setMode(Maps.DirectionFinder.Mode.DRIVING)
//Set the Orgin
.setOrigin(origin)
//Set the Destination
.setDestination(destination)
//Retrieve the Distance
.getDirections();
return directions.routes[0].legs[0].distance.value/1609.34;
}
Have you tried using a try-catch block around directions.routes[0].legs[0].distance.value ?
try{
return directions.routes[0].legs[0].distance.value/1609.34;
}
catch (e){
console.log("error",e)
}
or you could try something like this
alert(directions);
alert(directions.routes[0]);
alert(directions.routes[0].legs[0]);
alert(directions.routes[0].legs[0].distance);
alert(directions.routes[0].legs[0].distance.value);
and so on...to find out which one comes up as undefined the first. That might help you to debug the issue.
Enable Direction Api
1)Go to "google cloud platform"
2)go to "Api and services"
3)search for "direction api" and enable it
The directions service is subject to a quota and a rate limit. Check the return status before parsing the result.
For lots of distances (or at least more than 10), look at the DistanceMatrix.
I'm able to run the script from the Script editor, but not from spreadsheet. The error is "unable to read property legs" when the function is called from spreadsheet. But the property is in place when called from Script editor and contain correct values.
You probably need to use WEB API and have API KEY:
Google Apps Script - How to get driving distance from Maps for two points in spreadsheet

Which optional parameters do improve the accuracy of a google geolocation request result?

I am using gsm cell data to get the current device position. To do this I use the Google Maps Geolocation API. All fields seem to be optional in the first part of the needed JSON parameters (URL: https://www.googleapis.com/geolocation/v1/geolocate?key=API_key):
{
"homeMobileCountryCode": 310,
"homeMobileNetworkCode": 410,
"radioType": "gsm",
"carrier": "Vodafone",
"cellTowers": [
// See the Cell Tower Objects section below.
],
"wifiAccessPoints": [
// See the WiFi Access Point Objects section below.
]
}
Do the first 4 parameters homeMCC, homeMNC, radio Type and carrier have any influences on the accuracy? or the response time? I could not make out any differences.
I can believe that the Google database of cell IDs is organised by carrier and network type, so there might in theory be a quicker response if you supply these parameters, but it would surely be negligible. Can't think of a technical reason why it would need to know your home operator details too. The only information these parameters would give them is (1) whether you're roaming or not and (2) any stored information that they might be holding about individual operators. Does Google have special agreements with any operators?

Resources