When retrieving reverse isolines based on time with a list of ranges does anyone know the behavior?
For example if range is 50,100,150,200,250,300,350,400 the polygon for 50 is much different then if range is 50,100,150.
Based on the two parameter sets below the range is extremely different for the 30 second revere isoline range. The two calls occurred at the same time.
For https://isoline.route.ls.hereapi.com/routing/7.2/calculateisoline.json?apiKey=xxxx&mode=balanced;car;traffic:default;motorway:-3&rangeType=time&destination=geo!43.805388,-79.525348&range=30,1800.
The polygon is:
"isoline": [{
"range": 30,
"component": [{
"id": 0,
"shape": ["43.8079834,-79.5238495",
"43.8066101,-79.5204163",
"43.8038635,-79.5204163",
"43.8024902,-79.5245361",
"43.8038635,-79.528656",
"43.8066101,-79.5293427",
"43.8079834,-79.5272827",
"43.8079834,-79.5238495"]
}]
}
For https://isoline.route.ls.hereapi.com/routing/7.2/calculateisoline.json?apiKey=xxxx&mode=balanced;car;traffic:default;motorway:-3&rangeType=time&destination=geo!43.805388,-79.525348&range=30.
The polygon is:
"isoline": [{
"range": 30,
"component": [{
"id": 0,
"shape": ["43.8059235,-79.5258236",
"43.8059235,-79.5245361",
"43.8057518,-79.5240211",
"43.8054085,-79.5240211",
"43.8050652,-79.5250511",
"43.8047218,-79.5253944",
"43.8047218,-79.5257378",
"43.8054085,-79.5264244",
"43.8057518,-79.5265102",
"43.8059235,-79.5262527",
"43.8059235,-79.5258236"]
}]
}]
The behaviour is same as single range, just that multiple range allows calculation of many isolines with the same start or destination.
Check this link for your reference.
https://developer.here.com/documentation/isoline-routing-api/dev_guide/topics/use-cases/multi-range-isoline.html
Related
For some coordinates, the Here isoline API returns the same polygon for all the time distances, regardless of the range[values] value.
The example is for Burlington GO train station, ON, Canada, and changing the coordinates a few meters causes invalid data.
example:
curl --location -g --request GET 'https://isoline.router.hereapi.com/v8/isolines?transportMode=pedestrian&range[type]=time&range[values]=50,600&destination=43.339900,-79.809388&apikey=XXXXXX'
{
"arrival": {
"time": "2022-08-31T06:28:52+00:00",
"place": {
"type": "place",
"location": {"lat": 43.33981,"lng": -79.80958},
"originalLocation": { "lat": 43.3399,"lng": -79.8093881}
}
},
"isolines": [
{
"range": {"type": "time","value": 50},
"polygons": [{"outer": "BG86o1yC3mmn4E1C2GhI2C1KAhI1CArF4K1KgI1CiIqB2CgEA4G" }
]
},
{
"range": {"type": "time","value": 600},
"polygons": [{"outer": "BG86o1yC3mmn4E1C2GhI2C1KAhI1CArF4K1KgI1CiIqB2CgEA4G"}
]
}
]
}
If I change the coordinates just a few meters, to "lat": 43.3403845, "lng": -79.8089106 then it returns correct isolines.
Is there a best practice when selecting destination coordinates, any extra parameter I should use to make the results more predictable?
I consider this a bug, if you cannot return valid results you should throw an error, not return invalid data to clients.
I think you can get better results if you use the additional parameter "radius" (meters) for the place (lat, lng) that you provided.
This parameter instructs the router to consider all places within the given radius as potential candidates for route calculation. This can be either because it is not important which place is used, or because it is unknown. Radiuses wider than 200 meters are not supported.
For example: destination=43.339900,-79.809388;radius=100.
I hope this information is useful for you.
Regards.
We're currently investigating in the HERE Routing API v8 but can't really determine what the actual result consists of when units is set to metric.
Example result:
"summary": {
"duration": 1670,
"length": 12865,
"baseDuration": 1506
},
"transport": {
"mode": "truck"
}
Would the length be in metres perhaps? And what about the duration? Is that in seconds?
Please find the following parameters along with their units of measurement
duration:
required
integer (Duration)
Duration in seconds.
length :
required
integer (Distance) >= 0
Distance in meters. For more information please refer to the following API Reference
This is probably more complicated as it sounds, at least with Grafana.
I have an experiment, where for every location (1-100) a value is changed over time. I want to show this with a line graph (or a bar graph), where x-axis correspond to the locations (1-100) and y-axis correspond to the average value for this location for the time interval that is set in Grafana in the upper right corner. Data comes from database. Please, suggest me, which type of graph (dashboard) should I choose in Grafana to achieve the goal. I can only see two kinds of them, those with time on x-axis and those of type histogram but none seems to be applicable.
seems Grafana builtin panels only support
time series, which mean x-axis must be 'time' type.
bilibala-echarts-panel
I use this third-part panel bilibala-echarts-panel
https://grafana.com/grafana/plugins/bilibala-echarts-panel/
achieved the goal: x-axis not use time value.
It can use a custom callback function, to handle data and render
setting
in grafana query setting:
format as time series
// time series need 3 column:
time // time or number (can be parse as time)
metric // string: series name
value // number (otherwise got value error)
assign the value to time column.
// it may rander as 1970-01 in table view, but in echart we can read it as number
in echart panel option:
data.series got the grafana data
// convert/adapte it to echart data here.
maybe format as table can have more flexible data,
and parse them in the callback js.
summary
grafana and echart have different theory,
have to understand both of them ,
and do the convert in js.
// bilibala-echarts-panel using echart v4 #2022-07
We have implemented the graph using natel-plotly-panel plugin.
"panels": [
{
"pconfig": {
"traces": [
{
"mapping": {
"color": "64",
"size": null,
"text": "metriccat",
"x": "loccat",
"y": "valuecat",
"z": null
},
"name": "My value",
"show": {
"line": true,
"lines": true,
"markers": false
}
},
...
]
},
"pluginVersion": "7.5.5",
"targets": [
{
"format": "table",
"group": [],
"metricColumn": "none",
"rawQuery": true,
"rawSql": "SELECT\n avg(column_with_values) AS valuecat,\n loc loccat,\n avg(column_with_values) as metriccat\nFROM ... \nWHERE\n $__timeFilter(timestamp)\nGROUP BY loc\n\n",
"select": [
[
{
"params": [
"value"
],
"type": "column"
}
]
],
"timeColumn": "time",
"where": [
{
"name": "$__timeFilter",
"params": [],
"type": "macro"
}
]
},
...
],
"title": "Average Values Along the Locations",
"type": "natel-plotly-panel",
"version": 1
}
]
Making a Rest call to calculate matrix of HERE routing with multiple starts and destinations but getting proper response only for direct one to one start and destinations and getting status:failed for other inter combinations (getting only for principal diagonal values). Facing the issue only for few countries (here it is India) but working for the samples in the website (Europe)
Rest GET call: https://matrix.route.ls.hereapi.com/routing/7.2/calculatematrix.json?apiKey=<API_KEY>&mode=balanced;car;traffic:disabled&summaryAttributes=distance,traveltime&start0=17.251160,78.437737&destination0=16.506174,80.648018&start1=13.069166,80.191391&destination1=12.971599,77.594566
Response: {
"response": {
"metaInfo": {
"timestamp": "2020-02-04T12:36:09Z",
"mapVersion": "8.30.105.150",
"moduleVersion": "7.2.202005-6333",
"interfaceVersion": "2.6.75",
"availableMapVersion": [
"8.30.105.150"
]
},
"matrixEntry": [
{
"startIndex": 0,
"destinationIndex": 0,
"summary": {
"distance": 286827,
"travelTime": 24236,
"costFactor": 24029
}
},
{
"startIndex": 0,
"destinationIndex": 1,
"status": "failed"
},
{
"startIndex": 1,
"destinationIndex": 0,
"status": "failed"
},
{
"startIndex": 1,
"destinationIndex": 1,
"summary": {
"distance": 339029,
"travelTime": 26924,
"costFactor": 26845
}
}
]
}
}
The reason behind the observed behaviour is that the road network in
India is quite dense, and in some areas the algorithm is not able to
find an optimal route within a reasonable time limit.
We suggest trying out our Large Scale Matrix Service. It supports two use cases:
Matrix Routing calculations with live traffic information for matrices up to 10000x10000 size in a limited size region (up to 400km in diameter).
Matrix Routing calculations without live traffic information for matrices up to 10000x10000 size without region limitations for fixed sets of parameters (profiles).
I'm trying to learn to use Freebase, however when I try and do a sort by "/people/person/date_of_birth" for a search for actors for a show, it returns:
"code": 400,
"message": "Must sort on a single value, not at /tv/tv_program/regular_cast./tv/regular_tv_appearance/actor./people/person/date_of_birth"
Here is the full MQL query:
[{
"id": "/m/0524b41",
"name": [],
"sort":"/tv/tv_program/regular_cast./tv/regular_tv_appearance/actor./people/person/date_of_birth",
"/tv/tv_program/regular_cast": [{
"/tv/regular_tv_appearance/actor": [{
"name": [],
"/people/person/date_of_birth": []
}]
}]
}]
But you're not asking to sort on /people/person/date_of_birth, you're asking to sort on that long nested expression which goes through multiple intermediary nodes, some of which can appear multiple times (as indicated by the [] array notation). It's this multiplicity that MQL is complaining about.
To fix it, take your query, paste it into the query editor, click on the innermost /person/date_of_birth and then click "Invert Query." That will turn the query inside out and give you something that looks like this:
[{
"name": [],
"/people/person/date_of_birth": [],
"type": "/tv/tv_actor",
"!/tv/regular_tv_appearance/actor": [{
"!/tv/tv_program/regular_cast": [{
"id": "/m/0524b41",
"name": [],
"sort": "/tv/tv_program/regular_cast./tv/regular_tv_appearance/actor./people/person/date_of_birth"
}]
}]
}]
which isn't exactly what you want, but indicates the general shape of your target query.
Getting rid of the array brackets for single valued properties and moving the sort clause to the outside gives us:
[{
"name": null,
"/people/person/date_of_birth": null,
"sort": "/people/person/date_of_birth",
"type": "/tv/tv_actor",
"!/tv/regular_tv_appearance/actor": [{
"!/tv/tv_program/regular_cast": [{
"id": "/m/0524b41",
"name": null
}]
}]
}]
which is functional and returns our 81 regular Game of Thrones actors sorted by birth date, but could still be cleaned up a bit more. The !inverse property notation isn't necessary since we have forward equivalents and we don't really need to get the Game of Thrones info over and over again since it's constant and we really just want to use it as a filter.
Incorporating these final tweaks gives us a final query like this which returns nice compact results:
[{
"name": null,
"/people/person/date_of_birth": null,
"sort": "/people/person/date_of_birth",
"type": "/tv/tv_actor",
"starring_roles": [{
"series": {
"id": "/m/0524b41"
},
"limit": 0
}]
}]
The "limit": 0 clause is a little trick to cause MQL to use that subquery for filtering, but not bother returning any of the (constant) information in the results. The /tv/tv_actor/starring_roles and /tv/regular_tv_appearance/series can be abbreviated to the simple property names because their types are implied by their context.
Since there are only 81 results, MQL's default limit of 100 is plenty and we don't need to worry about increasing it or using cursors.
Oldest Game of Thrones actor: Peter Vaughn, born 1923.
Youngest: Lino Facioli b. 2000
Note that 7 actors don't have birth dates in Freebase, so we don't know where they rank age-wise. Here's a bonus query which returns their names and ids as well as their character's name. If we were running a production system, we might use something like this to feed a human curation queue to fill in the gaps.
[{
"name": null,
"/people/person/date_of_birth": {
"value": null,
"optional": "forbidden"
},
"type": "/tv/tv_actor",
"starring_roles": [{
"series": {
"id": "/m/0524b41"
},
"character":null
}]
}]
The seven character/actor pairs are (were): Roose Bolton - Michael McElhatton,
Gregor Clegane - Conan Stevens,
Hizdahr zo Loraq - Joel Fry,
Rickon Stark - Art Parkinson,
Janos Slynt - Dominic Carter,
Hodor - Kristian Nairn,
Tommen Baratheon - Callum Wharry. I say "were" because I couldn't resist fixing Hodor's birth date. The strange thing is that it was in Wikipedia, so should have been picked up automatically by Freebase. I think there's a bug lurking there somewhere.