I would like to implement my own routing web service in play framework (due to the fact that it's java and it's a rapid prototyping framework). I also would like to use graphhopper as the routing engine.
My Basic requirements are:
The routing should be based on our own multimodal graph database (consisting of EDGES/LINKS and NODES and also different properties to derive weights from
I want to be able to select different properties for edge weighting during runtime (i.e. an emergency vehicle can take routes, normal cardrivers aren allowedto use)
The graph spreads over half the size of austria (approx. 800.000 edges).
At the moment I have a lot of questions, and don't really know where to begin:
Is the transport vehicle type defined with EncodingManager only, or is it possible to change it during a route? (without rebuilding the graph while runtime)
Whats exactly the difference between RAMDataAccess and MMapDataAccess? Does the latter mean, that the graph is (partly) stored on disc? Does the first mean the graph is only stored in Memory?
I dont understand the NextA and NextB Properties of the EDGE object...what about crossings with 3 or more EDGEs? Which one is NextB from each of the other ones?
Does "...where nodeA is always smaller than nodeB..." mean that the ID has always to be smaller? What about graph direction (i.e. an EDGE pointing to the other direction)?
More questions to come up....
What I did so far:
I was going through the graphhopper docs starting with the developer snippets and the low level API but on th page it says that this is outdated?!?! (What does that mean?)
I also checked the web subfolder of the graphhopper github repository, but there is only a ready-to-use graphhopper webservice based on OSM data built in there.
Unfortunately I could not find any more comprehensive example including building a graph with MMapDataAccess (edit thanks for the tip to look into the unit tests, I think I'll find mor there)
I'd be very grateful to anybody here, who could please give me some examples how to build up my own graph and use (or rebuild it?) when weighting parameters change.
EDIT: tried to make my points clearer
select different properties for edge weighting during runtime out of our database
If you want to select the weighting at runtime you should avoid triggering an external database. It will slowdown everything. Instead feed the weights you have into the GraphHopperStorage itself. Every edge is a row in a big table. Just add one more column per weight you need:
E_CUSTOM_WEIGHT = nextEdgeEntryIndex();
The graph spreads over half the size of austria (approx. 800.000 edges)
Not sure what you mean with multimodal graph (also timedependent?). If normal road network 800k is not much. Whole germany is ten times large and fits into under 1gb
Regarding quickstart. Just the wiki for the low level API is outdated. Have a look into the unit tests of LocationIndexTree for the current usage. (maybe you can update the wiki afterwards :))
Unfortunately I could not find any more comprehensive example including building a graph with MMapDataAccess.
you just change the config or if you prefer low level API:
graph = new GraphHopperStorage(new MMapDirectory(), encodingManager)
Anybody here can give me some examples how to build up my own graph and rebuild it,when weighting parameters change.
have a look into the unit tests. Lots of examples how to build a graph. With 'rebuilding' - what do you mean? Do you mean the CH preparation? CH preparation is not possible if you want to calculate weight at runtime.
Related
I'm planning to use either of popular routing projects OSMR, Graphhopper or Valhalla to find the fastest route including historical traffic data.
Question: I don't have traffic data for all graph edges representing roads (only for a subset), and the missing data has to be extrapolated. What mathematical tools (or ready solutions) can I use to extrapolate/ fill/ guess the missing traffic data given following assumptions:
Ideal arbitrage is performed by drivers. Taking a route without (or partially without) traffic data shouldn't give an advantage.
The routing queries will be limited to an area of a typical European city, say 25km x 25km, what results in a fairly small graph.
The solution can be either: geo-agnostic (refer only on nodes and edge weights) or take into account spatial data ie. physical proximity (or direction!) of graph edges.
Any heuristic can take advantage of the fact that the routing happens for morning or evening rush hours. The traffic significantly differs depending on the direction.
Thank you for your help!
I am using here map api for getting nearby places but it is giving blank data (/places/v1/descover/here). While in /descover/explore/ it is giving so many records on same lat long. I am sharing screenshot for better understanding, Visit https://www.awesomescreenshot.com/image/3804672/65583a3e4f228ade754feba101ef26eb.
This depends on the use case you have.
The Here entrypoint helps users to identify direct places at their location or at a point selected on a map by returning places close to a given point, sorted by distance. (Normally the closest known places are returned, but if the uncertainty in the position is high then some nearer places are excluded from the result in favour of more popular places in the area of uncertainty.)
Then again the Explore entrypoint retrieves a complete list of relevant places nearby a given position or area. It answers the question "What interesting places are in the viewport of the map?" The results presented to the user are confined to those located in the current map view or search area and are ordered by popularity.
In general I would recommend to use the Explore entrypoint as the Here one is deprecated:
https://developer.here.com/documentation/places/topics_api/entrypoint-maturity-availability.html
I'm using the Web Audio API to make a graphic EQ with four BiQuad filters; a highpass, two bandpass and a low pass:
You can see each node representing each filter's frequency. It's working nicely but I'd like to draw the shape of the filter's roll-off you'd usually find in other graphic EQ's.
I have the Q-factor of each filter and the central frequency. What I would like to do is get a formula that allows me to get the frequency of the roll-off at a specific db value. For example what is the frequency of the roll-off at -200db?
It's been a while since I've done any heavy mathematical stuff and so any help would be greatly appreciated.
Have you looked at the getFrequencyResponse method of BiquadFilterNode? https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#Methods.
This demo from my IO2012 Web Audio talk uses it: http://webaudio-io2012.appspot.com/frames/frequency-response.html. You'll have to calculate the responses of multiple filters stacked together from there, of course.
I am trying to get the distance traveled on a transit route -- particularly San Francisco MUNI, but the standards NextBus, GTFS, and Google Maps API appear to be universal. I'm comfortable using any of these APIs, I'm just not sure how to go about this problem.
The easy way - ask Google Maps (this using webservices, but there is also the javascript API):
http://maps.googleapis.com/maps/api/directions/json?origin=37.7954199,-122.397&destination=37.7873299,-122.44691&sensor=false&mode=transit&departure_time=1348109609&alternatives=true
this JSON includes distance traveled, but there are two issues:
Google does not allow you to use this data unless you're displaying a map, which I don't want to do
I would need to ensure that the distance returned is for the correct route/line, since it can/will give multiple routing options. This is probably doable but would require more logic.
EDIT: using alternatives=true (or provideRouteAlternatives: true using the javascript API) only returns a maximum of 3 routes, which here in SF often doesn't include the route I'm looking for (other transit agencies, multiple lines on the same route, etc). So this isn't such a great option.
NextBus:
example route config:
http://webservices.nextbus.com/service/publicXMLFeed?command=routeConfig&a=sf-muni&r=1
The coordinates for each stop are given, but connecting the dots on those is not the same as the route taken -- it will cut corners, etc, and I need this to be accurate. The actual route taken is given under <path>/<point>, but I don't see any obvious correlation between stop and path coordinates. Plus, NextBus says in their documentation (p.10 near the bottom) that you should NOT connect points between <path> segments, they're only meant for drawing on a map and can overlap.
GTFS:
The GTFS data also separates stop and "shape" coordinates (like NextBus paths). Unfortunately, the coordinates are slightly different for the same stops between NextBus and GTFS (rounding), though the stop ID/tags are the same. Also, the data files are in the megabytes, and I need to use this for a mobile app. I suppose I could put all the data in a database and query that, but that still leaves figuring out how to correlate the stops with the shape. The "shapes_distance_traveled" column in the shapes.txt file is especially promising. MUNI chooses to leave the optional "shapes_distance_traveled" field out of stop_times.txt, though.
Any advice would be appreciated, I understand this seems like an epic task to get a simple value. Maybe I'll just throw a map in to legitimately use the distance :)
Instead of using Google Maps, I would look into the un-encumbered licensing of OpenStreetMap. There are multiple
routing engines that can use OSM data. Personally, I would use routing in PostGIS or SQLite, but depending on your skillset you might choose another.
You've clearly done your research, (+1), and as you said, the easy way is to ask Google. If it is worth for you then you might want to look into purchasing a business licence to use the Google Maps API, and negotiate with them about the requirement of displaying a map. That's the only legal way I can think of with the Google API. Alternatively, you can try building you own routing engine with data from the TIGER data set, which is freely available from the US Census Bureau, but again, as you said, it may seem like an epic task. :-)
So what I'm trying to do is the following:
Have a map (such as Google Maps or questMaps). It doesn't matter at all which API I need to use.
On that map have an overlay on the streets. So say (for example) the street has bad lightning at night, it will be colored red. If it has good lightning it will have a green overlay.
Based on the overlay the map creates a custom route (for example the user only wants to walk on the green/well lit streets).
I have no idea how to accomplish this (especially step 3).
First, you'll have to decide what data you need. How do you categorize certain streets as lit or unlit? What if some parts of a street are well lit and some have no lights? Do you need to know the location of every streetlight in your area? What if lights burn out?
After figuring out what data you need, you need to build your dataset. I'd be VERY surprised if this data already exists, so you will probably need to gather it yourself. Either go around town and take notes, or crowdsource the project, or figure out some other way.
Once you have gathered your data, learn the drawing API of whatever mapping tool you wish to use. They all should have functions in their API for drawing colored lines (for streets) or points (for streetlights) on top of an existing map.
Finally, learn the navigational API of the mapping tool you chose. You're right, this is a hard step. I know Google Maps lets you specify certain waypoints when requesting directions; maybe your app can calculate well-lit waypoints and feed them to Google Maps' Directions service to influence the route it generates.
Good luck!
For custom routing, you need to read up on "Graph Theory". This ignores the geography of the street map, and considers it as a set of junctions (nodes or vertices in the graph theory jargon) connected by edges. You can assign weights to edges - these could be lengths, travel times, ones and zeroes etc. Anything. They can have no relation to the position on the map.
So for your application, you'd assign a large weight to unlit streets, and a small weight to lit streets, then use a standard minimum-weight algorithm to get a route from one node to another.