[Download Route 66 Maps Navigation
Melvin Amey
After you download an area, use the Google Maps app just like you normally would. If your internet connection is slow or absent, your offline maps will guide you to your destination as long as the entire route is within the offline map.
Offline maps that you downloaded on your phone or tablet must be updated before they expire. When your offline maps expire in 15 days or less, Google Maps tries to update the area automatically when you're connected to Wi-Fi.
I've figured out how to create maps and share them with people, but I'm having difficulties with the directions functionality. Once I've saved a route I can't seem to do anything with it; I can view the route on a map but that's it. This is okay I guess for walking but it's obviously pretty useless for driving or transit.
How do I start the route? As in: get directions, traffic, time estimates, navigation etc? At the moment I'm looking at the saved route on the map and just copying the source and destination locations into a new directions page on Maps, but this obviously doesn't give you the actual same route that you customised on My Maps.
To give directions you need to use the fully-baked map. It makes sense, I suppose, since traffic, construction, etc., is something you need up-to-date information on, and your static "My Map" may be out of date.
It's easy enough to save directions. Just take the URL that you get when you search for directions. (U.S. Capitol Building to White House. Look at all of that information embedded in that URL.) If you're concerned about sharing something so complicated with someone, it's easy enough to pass it to an URL shortener like goo.gl.
love tracking my rides with Rever. This app does this and a heck of lot more. There is a ton of single track moto rides where I live and the tracking system/gps is very accurate. I like the new feature of auto pause and of course I like to see how fast I ride as this app gives me my highest mph which I can compare with my friends. Before Rever came along I would use Map my ride but this was not a motorcycle specific app. Now I track all of my rides and can share them with my friends. Great app!
I had planned over 20,000 kms of rides after I had discovered this app. The wife and I are riding 29 states and 3 provinces after I complete a 24 border to border run to Mexico. Planning the trip was easy and with the Butler map overlay completely changed the route we are taking. I was having no luck with the mobile app however... Turns out the email address I used to sign up for facebook was used to log in. Hadn't used that one in years. The found it and it works awesome now! Wicked customer service!
The answer then, to my initial question of "Have they really made it better?" would be yes. And as an alternative to other, motorcycle-specific maps, my wife Judy, who is our chief navigator, spent a lot of time comparing several and concluded that the Butler maps are the best.
Navigation systems like the Garmin and TomTom have always fascinated me. I've wanted to implement small map/navigation applications to try out various pathing algorithms and expand on my knowledge of them.
1.) How is Map data stored? - When you have a network of roads, how is this data generally stored? What parts of the data are retained inorder to reproduce a map later? Is each road stored as a series of points where it changes direction? What kind of file formats is this data stored in? Are there publically available libraries for easily parsing these files? Does anyone have specifics on how map/road data is stored/represented it would be very helpful.
2.) Navigation/Pathing - When doing basic pathing on this map data (a la Garmin) is my assumption correct that it is converted to a directed graph? Is each road intersection a vertex with the edge weights the distance between vertexes? This is what I was thinking about doing so I could try some basic well known pathing algorithms and see what I get.
Instead, PNDs store information pretty much as Simucal presumed. Roads are broken down into segments. This keeps the model a lot simpler. Within a segment, attributes like maximum speed don't change.
For planning purposes, road segments act as the edges in a graph. For each nodes, incoming and outgoing nodes are both stored. Planning is then done using a modified A* algorithm. Edge weights are typically not distances, but estimated travel time (or in TomToms case, actual, measured time).
Road networks are typically hiearchical, though, and normal A* is a slow starter. When travelling from one town to another, A* will spend excessive amounts of time crawling through the start town. However, we humans know it's best to use highways when travelling longer distances. That's what they're built for. PNDs likewise prefer highways. And as highways are a lot rarer, this saves a lot of memory.
Another optimization is forward and backward search; you plan from both sides towards some middle point. The big advantage of this is that if you take a wrong turn, you can search again from a new start point. The backwards search tree is unchanged as your destination didn't move.
I don't know specifics about navigation system units, but in the standard GIS world, map data is stored basically as a collection of polygons, lines and points, each described by its coordinates (and the projection used and some other parameters). For instance, one of the most common formats, shapefiles, is described here, and the database based format standard is here.
I've successfully used this storage model for roads display and route calculation, using PostgreSQL, PostGIS and PGRouting. Calculations are done using the usual graph algorithms and the data stored in the common format is stored also as a graph to allow for their application. I can't extrapolate that experience to an embedded device as they likely do it very differently given their limited computing capacity. They very probably precalculate lots of stuff.
Typically roads will be stored in the file as a "lines layer", that is a set of polylines with attached metadata. So each road will have a series of vertices, and depending on the quality of your data it will hopefully have information such as whether they're one-way or not, speed estimates and some sort of connection id.
Solving quickly is a tradeoff between precomputation and storage space (an embedded device may necessitate a different choice here to a PC). There are some very interesting algorithms out there for doing that.
Mohammed: Okay, I didn't go into much detail there because the original question seemed pretty comfortable on that aspect. If you aren't familiar with graph theory, it's probably a good idea to do a bit of reading on it now - Wikipedia is fine for an introduction.
What typically happens is that in the GIS data the roads are stored as polylines with attached metadata. That's fine for displaying them onscreen etc, but to be able to navigate them you need to know which ones are connected to one another. So in the metadata there's normally a node id for each end of the road, so you can say "this is road segment 457, it goes from node 332 to node 667". So when you read in the GIS data you build up a representation of it as a set of nodes connected by arcs (ie. a graph).
If that metadata's not available you could infer it from which roads have the same start/end coordinates (this is the case with some not-so-wonderful GIS data). The "directed" bit just means that roads have direction - some of them can be travelled along in either direction, but others are only one-way.
The typical algorithm for finding a path through a digraph is Dijkstra's algorithm; various derivatives are used in practice. Basically that involves moving from node to node along the arcs of the graph, so you need the appropriate data structures to support that.
If you want some code to look at to get some idea about how routing applications work, try having a look at some of the routing applications linked from the openstreetmap.org wiki. Navit and Gosmore are both open source and fairly easy to set up in particular.
I thought I'd add a bit to the above. Firstly, I'd define a navigation system as a system that assists you how you get to where you want to go based on your current location, typically by costing a number of possible alternative routes and recommending the lowest cost one. Possible routes may be dictated by mode of transport, cars stay on roads for example whereas hill walkers don't. Costing of routes may vary by mode of transport too as well as user requirements. Cars might want to take quickest route based on road speed, trucks might want most fuel efficient route, hill walkers might want the safest direct route, boats or aeroplanes might want a route that avoids dangerous weather systems, while also minimising fuel cost and time spent.
At the most simple level a map and compass is a navigation system. Replace the map with a small screen, a scalable raster map and a GPS and you still have a navigation system. Most low to medium end maritime navigation systems still work this way, with charts representing the coastline and seabed and GPS to give you location, and echo sounding for depth.
At the more advanced end of the spectrum, autonomous robotic navigation systems such as the Mars Rover navigation system generate DTM models on the fly as a basis for short range navigation, and satellite gathered DEMs for longer range navigation.
To suggest that all navigation systems work like consumer Garmin or Tom Tom devices is a rather naive presumption. FWIW, many modern Garmin devices also include raster based DEM data where low cost GPS heighting can be wildly inaccurate.
Everglades National Park consists of over 800 square miles of marine waters from the Ten Thousand Islands to Florida Bay. While operating a vessel in Park waters, please familiarize yourself with the park's system of boating management zones (e.g., pole and troll zones), channel and navigational markers, and recreational opportunities (e.g. campsites) to enhance your stewardship and enjoyment of the park.
Though not a substitute for the necessary in-depth park knowledge and experience required to properly navigate park waters, below are several maps the park has developed to help boaters understand how and where to travel by boat. Please visit this page periodically as the park will be updating and adding new maps.
In addition, we are working with GPS navigation companies to have park-specific information incorporated into their products and systems. View the drop-down menu below for the most current information.