Folks in shipping, planning, or logistics spend a considerable amount of time wondering, "how far can I get in a certain amount of time?" It's our goal to answer that question, and trim down the amount of time used in the asking. Plus drive-time looks pretty cool, and cool looking stuff is another goal.
IDV's algorithmically inclined Abhinav Dayal created the service and took great care to balance speed and precision. Here are some screenshots from the testbed...
With a service like this, it is a good idea to have sufficient points of entry to accommodate foreseeable workflows. Below, for instance, is a storyboard describing a generic activation from tools workflow. But you might also want to right-click on an ad-hoc location on the map or use an existing feature as the origin point.
Sequence-heavy feature planning benefits from a comic strip. This storyboard describes one of the access methods to the drive-time service.
Some Interesting Notions
Drive-time polygons are only useful if they bear some semblance to reality, and a clear gotcha for anyone behind the wheel is traffic variability. Allowing the user to define a generic offset to the expected speed is a simple way to calibrate these doodads. The inclusion of a real-time service of actual traffic conditions is a clear enhancement, not without its own trade offs.
Changing the location of the drive-time origin and time slices should be easy and natural. This means clicking and dragging to new locations and modifying the number of rings, and their timing in a simple interface. Or something.
Inputs to other Workflows
A drive-time polygon is pretty interesting for interesting's sake. But it's also a useful input for a spatial query. 'How many whatevers are within a certain driving time?'
Anyways, things are coming together and I'll keep you posted on this and other doodads as they cook.