I am using HERE API to get additional information about geographical points through Layers and their attributes. I see there are two ways to go to get these information:
m.fleet.ls.hereapi.com/2/matchroute.json/?routemode=car&attributes=... with attribute list in the request:
attributes=ADAS_ATTRIB_FCn(HPX,HPY,HPZ,SLOPES,HEADINGS,CURVATURES,REFNODE_LINKCURVHEADS,NREFNODE_LINKCURVHEADS),LINK_ATTRIBUTE_FCn(ISO_COUNTRY_CODE,VEHICLE_TYPES,URBAN,TRANSPORT_VERIFIED,TO_REF_NUM_LANES,FROM_REF_NUM_LANES),LINK_ATTRIBUTE2_FCn(FOUR_WHEEL_DRIVE,SCENIC_ROUTE,PARKING_LOT_ROAD,PARKING_AVAILABILITY,PRIORITY_ROAD,CARPOOL_ROAD,REVERSIBLE,EXPRESS_LANE,TRANSITION_AREA,EXPANDED_INCLUSION,DELIVERY_ROAD,TRUCK_ROAD_TYPE,BICYCLE_ACCESS,BICYCLE_PROTECTION_TYPE,BICYCLE_TRAVEL_DIR_OVERRIDE,SURFACE_TYPE,GENERALISED_BICYCLE_PATH),TRAFFIC_SIGN_FCn(VEHICLE_TYPES,TRAFFIC_SIGN_TYPE)
https://m.fleet.ls.hereapi.com/2/matchroute.json API + https://s.fleet.ls.hereapi.com/1/tiles.json to get attributes of layers
What is the difference in these approaches? Will all attribute values be the same for same longitude-latitude points input?
Both API used for specific use cases.
Route matching is an alternative to calling PDE(Fleet advanced data set) along the route, for selected use cases.
When to retrieve attributes directly in the route match call and when
to fetch them afterwards from PDE?
In general, a matched route spans a few PDE tiles only, because the major part of a route is on functional class 1 roads (motorways) that are stored in PDE layers with large tiles. Hence, after a route match, the distinct set of tiles to load from PDE should rarely exceed 20 or 30, resulting in a few PDE requests, because each PDE request can ask for multiple tiles of multiple layers. The advantage of using PDE is that the retrieved full tile content can be cached for up to a month, and hence repeated transmission is avoided, if the assets are repeatedly driving in similar areas, which is usually the case.
However, asking for the attributes directly in the route match request is more simple on client side, and only the data of the links along the route are actually transferred.
Related
The Region resource accepts the definition of areas as lists of coordinates.
Unfortunately, since the resource seems to be only expecting GET requests, trying to display various areas or more precisely defined areas is limited by the constraints on the size of the query string.
Is there any possibility of consuming the resource with a POST request instead, like it is already happening with other resources in the API?
Currently POST method is not supported except for the route resource and it is limited to payloads of 8K maximum.We can take this request as feedback for a later release if you would like that.
I'm designing an API to query the history of a value over a time period. Think about a temperature value, and you want to query all the values for today.
I have a from and a to parameter to specify the boundaries of the query.
The values available may not exactly match the boundaries requested. For example, if from is 2016-02-17T00:00:00Z, the first value may be on 2016-02-17T00:04:30Z. To fully represent a graph of the period, it is necessary to retrieve one more value outside the given range. The value on 2016-02-16T23:59:30Z is useful and it would be convenient for the user to not have to make another query to retrieve it.
So as the API designer I'm thinking about a parameter with a pair a of boolean values that would tell for each boundary: give me one more value if there is no value exactly on the boundary.
My question is how to name this parameter as English is not my native language.
Here are a few ideas I have so far but with which I'm not totally satisfied:
overflow=true,true
overstep=true,true
edges=true,true
I would also appreciate any links to existing APIs with that feature, either web API or in programming languages.
Is it possible to make this more of a function/RPC that a traditional rest resource endpoint, so rather than requesting data for a resource between 2 dates like
/myResource?from=x&to=x
something more like
/getGraphData?graphFrom=&graphTo=x
Whilst its only a naming thing, it makes it a bit more acceptable to retrieve results for a task wrapped with outer data, rather than violating parameters potentially giving unexpected or confusing results.
When requesting a multi-leg route via the HERE API (e.g. Point A to Point B via Point C), is it possible to prevent or restrict u-turns? I am trying to produce a map to be followed by a school bus, and u-turns are not allowed. However, I often find that the directions suggest to do a u-turn upon arrival at the intermediate points. I would like the bus to keep going straight after making its stop. Is this possible to do?
I'm not aware of the possibility to restrict this type of maneuver.
Nevertheless, you can use truck routing in Here Location Platform for Enterprise, see the documentation here:
https://developer.here.com/documentation/download/routing_lbsp/6.2.32.0/Routing%20API%20v6.2.32.0%20Developer%27s%20Guide.pdf
It should retrieve much more adapted route for your use case and it might avoid u-turn.
Also, one final simple solution is to calculate route with alternative set to 3 (or make multiple call with other optimizations) and iterates through the different result in order to exclude routes that would include maneuver with a type associated to a u-turn
As part of my academic project, I have to build a routing engine based on data supplied from OSM. I have looked at the data model of OSM and I'm all fine with it. However, I'm having trouble converting an OSM XML file into a graph structure (nodes and edges) that I can use to apply search algorithms (Dijkstra, A* etc.) on. I would like the graph to be stored in memory to allow fast read/write.
So can anyone shed light or suggest techniques on how this can be done, or even provide pointers for further research.
Please note that I'm not allowed to re-use existing routing engines as this would defeat the purpose of doing the project.
All you need to do is:
create a node for every <node> item
every <way> entry is a sequenced list of <nd> items, each of which is a backreference to a node. So for each <way>, you iterate pairwise through its <nd>s and create an arc between the two nodes referenced.
You can do this in one pass using a streaming XML parser, since the XML data defines all the nodes before the ways.
The data doesn't intrinsically include distances, so you need to calculate that from the latlon of each node. You should also take account of the road type (highway=*) and the access info (access=*) in your routing, and you probably also want to ignore ways that are not traversable (eg waterway=stream) but that's all down to your specific situation.
http://wiki.openstreetmap.org/wiki/Elements
Let's say I have a flat file containing incoming messages. Where would the appropriate place be to inject the logic that takes identifying information from the message and sets primary key properties to link it to internal record IDs. For example, to map a customer's version of order ID into our internal order ID.
Sounds like you are looking to do a conversion of the incoming id to the internal id before sending the further along.
There are multiple places to do this.
You could do it in a pipeline component that either reads directly from its run-time configuration or from a database. You could also do it in a orchestration.
The easiest and most suitable place to do is probably however in a transformation map. Just make sure not to hard-code the transformation table (what id maps to one of you internal ids) as these usually change a lot. Have the map do a lookup ion a database for example to find the matching id.
Doing these kind of tasks in a map compared to the other options gives you a bit more flexibility as you can then apply the map directly in receive or send port. So if you don't need to do any workflow based logic you can use a messaging pattern and skip any orchestrations (always preferable).
I would consider doing this type of conversion in a map.