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
Related
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.
I am trying to calculate physical distances between geographic locations (addresses) with ggmaps/mapdist function in R. Apart from the uncomfortable fact that Google Maps allows only 2500 queries/session, I have to cope with the misspelled or other way imperfect "addresses". The most typical problem is that the exact address strings themselves are added by several other info (floor, door etc.), but it is very problematic to detect any pattern in these what would allow applying regular expression.
My goal is:
Check if the address string is recognizable to Google Maps;
If not, find a way to truncate to an acceptable form, perhaps by parsing words step by step from the string.
Have anybody coped with this kind of problem?
Thanks.
There are a couple of factors running into each other here. One factor is the misspellings and other complexities related to addresses and the other is pinpointing (geocoding) a given address. Although they are related problems, each must be handled to accomplish your objectives.
There are numerous service providers out there that can do either or both with minimal cost involved. This can be found with a simple Google search. You can then investigate each to see if they match your use case and licensing requirements.
All of that considered, you'll want to get your address list cleaned up on a minimum. Doing that will enable you to utilize any number of geocoding providers.
Depending upon the size of your list, you can get your list cleaned up and geocoded for perhaps $20.
In the interest of full disclosure, I'm the founder of SmartyStreets. We provide a web interface (to help clean up the address list) as well as an API (which can be used on a continual basis to keep addresses clean). We also geocode your list at no extra charge. Further, we don't have any licensing restrictions on the number of lookups that can be performed during a given timeframe. (We have customers that hit us hundreds of millions of times per day.) The entire process of signing up and cleaning up your list takes just a few minutes.
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
When i have a resource, let's say customers/3 which returns the customer object and i want to return this object with different fields, or some other changes (for example let's say i need to have include in customer object also his latest purchase (for the sake of speed i dont want to do 2 different queries)).
As i see it my options are:
customers/3/with-latest-purchase
customers/3?display=with-latest-purchase
In the first option there is distinct URI for the new representation, but is this REALLY needed? Also how do i tell the client that this URI exist?
In the second option there is GET parameter telling the server what kind of representation to return. The URI parameters can be explained through OPTIONS method and it is easier to tell client where to look for the data as all the representations are all in one place.
So my question is which of these is better (more RESTful) and/or is there some better way to do this that i do not know about?
I think what is best is to define atomic, indivisible service objects, e.g. customer and customer-latest-purchase, nice, clean, simple. Then if the client wants a customer with his latest purchases, they invoke both service calls, instead of jamming it all in one with funky parameters.
Different representations of an object is OK in Java through interfaces but I think it is a bad idea for REST because it compromises its simplicity.
There is a misconception that making query parameters look like file paths is more RESTful. The query portion of the address is included when determining a distinct URI so the second option is fine.
Is there much of a performance hit in including the latest purchase data in all customer GET requests? If not, the simplest thing would be to do that so there would neither be weird URL params or double requests. If getting the latest order is a significant hardship (which it probably shouldn't be) there is nothing wrong with adding a flag in the query string to include it.
I am trying to build a map based query interface for my website and I am having difficulty finding a starting point besides http://developer.google.com. I assume this is a rather simple task but I feel as though I am on a wild goose chase. Anyway the problem is the existing site places people into a category based on their address (primarily the zip code), this is not working out because of odd shapes and user density so I would like to solve the problem by creating custom zones.
I am not looking for a proprietary solution because I would really like to accomplish this on my own, I just need some better places to start or better suggestions for searches.
I understand that I will need to create a map with my predetermined polygons.
I understand how to create a map with polygons via js.
I do not understand how data will request which zone it is within and how it will return it as a hash I can store. eg. user=>####, zone=>####, section=>#####
http://blog.appdelegateinc.com./point-in-polygon-checking-with-google-maps.html
has some JS you can add to give the ability to test whether a point is within a polygon (sample: http://blog.appdelegateinc.com./static/samples/point_in_polygon.html ) using this approach: http://en.wikipedia.org/wiki/Point_in_polygon#Ray_casting_algorithm
I think as you place the markers, you'll hold them in an array (of objects)...then loop through, doing some sort of reduction of which polygons to test, testing those that remain, if inPoly, set marker.zone and marker.section to whatever suits your needs