Click on an image to get the full scale image:
Scalar field plots of drive time from (or to) a "source" point. The color changes continuously with drive time in a repeating rainbow pattern. Note that rings of constant color are rings of constant drive time to (or from) the source point. Roads squiggle, and therefore, so do the rings of constant drive time. Varying speed limits add additional ring distortions as do rivers, bridges, traffic signals and signs.
The above images were calculated with road network data for the USA northeast coast. On the first (left) image we see Maine, Cape Cod, Long Island, and down to and including Virginia. At this resolution the colorful roads tend to fill in all intervening space. The second image is a "blow up" near and around York Pennsylvania; you can make out the Susquehanna River. In this second image you can make out lots of road structure in the intervening space, and so this second image has a higher pixel per road length resolution than the first image.
If you're a computer science guy, or girl, you would calculate with a model that is a discrete graph network and solve it using some variation of Dijkstra's algorithm. There is a little more to it, if you want to make it calculate it quickly, but Dijkstra's algorithm is a good starting point for this superficial discussion. Myself, being a physicist first consider it to be a real physical problem with continuous roads that follow continuous lines that travel through a three dimensional space (that is projected into 2D here).
I used a discrete graph to solve for values of drive time at points on the roads; nothing new in the gross scope of things. Then, I mapped the problem back to the continuous road space by linearly interpolating along the roads between the values of drive times at the points, and used this to generate these images. The images clearly illustrate how the drive time to (or from) a point can be modeled as a continuous scalar field. This scalar field model of this network problem is at least useful in visualizing the problem. It shows how we can map the problem from continuous to discrete, and then solve, and then map it back to continuous producing very tangible results, i.e. pretty pictures. It's not just a scalar field, it's a continuous scalar field, the scalar value being drive time.
It seems a little odd because drive time seems like a more contrived physical quantity then say the scalar called temperature, but nonetheless drive time is a real measurable physical quantity. If you are a physicist, or engineer, you'll notice that the spatial gradient of this drive time scalar field is of the form of a Dirac delta function when you come to a spatial position where you stop, like at a stop sign. Just think about it a little and you'll see. Fun stuff ...
The project is currently stalled. The original instigator of the project lost interest and this "drive time engine" has no "clean" source of road network data to fuel it. The project is and always was missing necessary input data such as speed limits for the road networks. The images above where generated assuming constant speed limits, but the program does accommodate reading in speed limits if they are made available. The code can also distinguish between driving to the source and from the source, by ascribing positive or negative speed limits to adjacent points (nodes) in the roads. There was never any financial sponsorship of the project. It's a fun piece of code, maybe I'll play with it again someday putting it into a clean redistributable form. If you're interested contact me.
The driver application for this project was to use this "drive time calculator" as an analysis tool for retail store location selection. Putting a store in a location that has minimum average drive time, weighted by population density, to and from the store location is what is sought, which in turn may tend to give a store a maximum of customer throughput with respect to store location, by assuming that customers like to save time. Clearly other related measures could be contrived and other applications found for this code.
For experts in graph theory and/or finite element methods (FEM) this discourse may be considered baby food. This is not intended to be ground braking research. It's just a superficial summary of work done.