in the examples(https://tcs.ext.here.com/examples/v3/fleet_telematics_api) on any route I set the parameter vehicle = "Trailer truck", in the response I get: "Couldn't reach way point 1 (start links -52308626 52308626 dest links -73483065 73483065 ), closest link to destination reached: 52308626 at 50.11278/8.67522, issues: illegal access, weight".
The appearance of this error is influenced by the value of the parameters "Limited Weight [t]" and "Weight Per Axle [t]". Maximum values at which the request is executed "Limited Weight" = 18t and "Weight Per Axle" = 10t. But the real parameters of trucks with a trailer are higher.
please tell me is this a bug or am I doing something wrong?
Thank
The error message simply means the route calculation failed due to truck weight violation around 50.11278,8.67522, which is in the urban Frankfurt area and heavy weight trucks are banned.
Related
I am wondering what the documentation of cumulativeCost() in GEE exactly means by "nearest source location".
"nearest" in terms of "the closest starting pixel, linearly computed" or
"nearest" in terms of "the closest in terms of cumulative cost" ?
For my analysis I would like to know if the algorithm already reduces the number of potential routes in advance (by choosing only 1 starting point in advance) OR if it first tries the routes from one pixel to all possible starting points, and then takes the value to the starting pixel with the lowest total cost. Does anyone have more detailed information on how the algorithm works in that case? Thanks.
As a QR-Code uses Reed-Solomon for error correction, am I right, that with certain levels of corruption, a QR-Code reader could theoretically return wrong results?
If yes, are there other levels of integrity checks (checksums etc.) that would prevent that?
You can do a web search for "QR Code ISO", to find a pdf version of the document. I found one here:
https://www.swisseduc.ch/informatik/theoretische_informatik/qr_codes/docs/qr_standard.pdf
There are multiple strengths of error correction in the standard, and to avoid mis-correction, in some cases, some of the "parity" bytes are only used for error detection, and not for error correction. This is shown in table 13 in the pdf file linked to above. The ones marked with a "b" are cases where some of the parity bytes are used only for error detection. For example, the very first entry in table 13 shows (26,19,2)b, which means 26 total bytes, 19 data bytes, and 2 byte correction, which means of the 26-19 = 7 parity bytes, 4 are used for correction (each corrected byte requires 2 parity bytes unless hardware can flag "erasures"), and 3 are used for detection only.
If the error correction calculates an invalid location (one that is "outside" the range of valid locations), that will be flagged as a detected error. If the number of unique calculated locations is less than than the number of assumed errors used to calculate those locations (duplicate or non-existing root) that will be flagged as a detected error. For higher levels of error correction, the odds of all the calculated locations being valid for bad data is so small that none of the parity bytes are used for error detection only. These cases don't have the "b" in their table 13 entries.
The choices made for the various levels of error correction result in a very small chance of a bad result, but it's always possible.
are there other levels of integrity checks (checksums etc.) that would prevent that?
A QR-Code reader could flags bytes where any of the bits were not clearly 0 or 1 (like a shade of grey on a black / white code) as potential "erasures", which would lower the odds of a bad result. I don't know if this is done.
When generating a QR-Code, a mask is chosen to even out the ratio of light and dark areas in a code, and after correction, if there is evidence that the wrong mask was chosen, that could be flagged as a detected error, but I'm not sure if the "best" mask is always chosen when a code is printed, so I don't know if a check for "best" mask is used.
Using this example https://developer.here.com/documentation/toll-cost/topics/example-tollcost.html
and description from here https://developer.here.com/documentation/toll-cost/topics/resource-tollcost-input-interface.html trying to calculate tolls on usa roads
First found paid road to be sure to have it on the route - found here https://www.sixt.com/toll-roads/usa/ - rout in Florida from Punta Gorda, FL, United States to Islamorada, FL, United States
From route received two links
0: {linkId: "-91500228", mappedPosition: {latitude: 26.9336687, longitude: -82.0531188},…}
1: {linkId: "+897488196", mappedPosition: {latitude: 24.9598652, longitude: -80.5699824},…}
Then do tolls request
https://tce.api.here.com/2/tollcost.json
?app_id=my_app_id
&app_code=my_code
&tollVehicleType=3
&vehicleNumberAxles=2
&emissionType=6
&height=3.5m
&vehicleWeight=10.0t
&limitedWeight=10.0t
&passengersCount=1
&tiresCount=8
&route=-91500228;897488196
&detail=1
In response always receive:
{"errors":[],"warnings":[{"category":1,"context":"Old response format is deprecated, please use request parameter &rollup"}],"countries":[],"onError":false}
Tried different locations in usa, no matter what - always empty countries array
Please advice what I'm missing, thank you
Here is a working example:
https://tce.cit.api.here.com/2/calculateroute.json?jsonAttributes=41&waypoint0=26.13442,-81.68696&detail=1&waypoint1=26.08104,-80.36682&routelegattributes=li&routeattributes=gr&maneuverattributes=none&linkattributes=none,rt,fl&legattributes=none,li,sm¤cy=EUR&departure=&tollVehicleType=3&emissionType=5&height=3.8m&vehicleWeight=11000&limitedWeight=11t&passengersCount=1&tiresCount=4&commercial=1&heightAbove1stAxle=1m&width=2.55&length=10&mode=fastest;truck;traffic:enabled&rollup=none,country;tollsys&app_id=yyy&app_code=xxx
In general is the parameter rollup missing in your request. This one need to be added in any case. Besides of that is the route you try to calculate quite far over islands with a truck with a specific size and weight. It is quite difficult to get an idea within the pure HTTPRest request. Maybe this demo page helps a bit for debugging such cases:
https://tcs.ext.here.com/examples/v3/route_with_tce
In the documentation I see:
vehicleWeight -- Number. Actual total weight of vehicle incl. its payload but NOT the trailers' weight or payload.
For me the truck itself is 12t. While trying to get costs for toll roads with this value, I'm getting distance 470km, costs 58Eur and it is wrong.
So, I want to know what is the problem: 1) documentation error, vehicleWeight should be mass truck+trailer, 2) I missed some extra parameters, 3) or maybe some other issue?
When I tryied to change vehicleWeight from 12t to 20t (truck+trailer mass) the result is correct, about 85Eur.
https://tce.cit.api.here.com/2/calculateroute.json?app_id={app_id}&app_code={app_code}&tollVehicleType=3&trailerType=2&trailersCount=1&vehicleNumberAxles=2&trailerNumberAxles=2&emissionType=6&height=4.0m&trailerHeight=4.0m&vehicleWeight=12t&limitedWeight=20t&tiresCount=10&commercial=1&cost_optimize=0&driver_cost=0.0&vehicle_cost=0.0¤cy=EUR&rollup=country;tollsys&waypoint0=geo!stopOver!49.4889567,10.978884&waypoint1=geo!passThrough!50.1211273,8.4961394&waypoint2=geo!stopOver!51.2383707,6.6739259&mode=fastest;truck;traffic:disabled&vehicleType=diesel,28
I expect to get here about 85Eur (because distance is about 470km and price for Euro 6, >18t, 4 axles is 0.187cents/km), but actually API returning about 58Eur.
Thank you for reporting this issue. It seems that there was an issue and we could solve it already. Within the next release planned for February this will be solved.
An address containing a "#" (for example an apartment number) frequently gives an incorrect location result, both with ggmap::geocode and with google maps as well, so this is not strictly an R question. In this example, adding a "#3" after the street address changes the location result from Illinois to California:
> test <- geocode('1200 Davis St, Evanston, IL 60202', source='google', output='more')
> test[, c('lon', 'lat', 'administrative_area_level_1')]
lon lat administrative_area_level_1
1 -87.68978 42.04627 Illinois
> testhash <- geocode('1200 Davis St #3, Evanston, IL 60202', source='google', output='more')
> testhash[, c('lon', 'lat', 'administrative_area_level_1')]
lon lat administrative_area_level_1
1 -122.1692 37.72169 California
If you experiment with google maps directly, sometimes adding a hash into an address seems to confuse the lookup, generating a variety of geographically dispersed results. This doesn't always happen, but in my experience happens frequently. It's easily fixed (there's no need for an apartment number when geocoding) but I'm wondering why it happens and if there are other cautions about entering addresses.
Google has recommendations in regard to address formatting in Geocoding API. Particularly they suggest do not specify additional elements like apartment number or floor numbers in requests.
You can check the complete list of recommendations in Google Maps FAQ:
https://developers.google.com/maps/faq#geocoder_queryformat
The relevant part is
Do not specify additional address elements such as business names, unit numbers, floor numbers, or suite numbers that are not included in the address as defined by the postal service of the country concerned. Doing so may result in responses with ZERO_RESULTS.
I hope this helps!