I love this idea, and also its acknowledgement of prior time maps for rail and other psychogeographic forebears. Its ability to put in relevant data in rational time-based space stops some of those issues that make us take a longer or particular direction because of habit, fear, or misunderstanding of the timespace about us. Nonetheless as a map-lover, I'd love to see how more contextual information could be added for serendipitous and geographical observation.
This is absolutely amazing. If I could use this with a more intelligent search (pub / bar return different things, for instance - whereas I want to search for "places I can get a beer"), this would be fantastic.
Agree. Show me a time map for nearby draft beers with Beer Advocate or Ratebeer scores and I would use this all the time. Bonus points to restrict to certain styles like IPA, lagers, etc. Untappd could actually do this if they wanted.
Interesting concept. I like the overlay idea, but I think simply having that as a standalone map would not be useful in other areas where distance as the crow flies ≠ time traveled. Areas with large bodies of water (like adjacent peninsulas), mountainous areas or areas with strange road infrastructure (Some parts of Virginia).
For what it's worth, I think it would be computationally quite hard. You would have to pick a set of points and maybe isomap them from three dimensions (x, y, and time) to two, then find a visually acceptable cage transformation using those points as anchors. You'd have to do this for each query.
Alternative would be to keep the standard geographic map, but have clear points on all possible destinations X minutes away - ideally with a slider, watching the "X minutes" points slide around. Actually pretty easy, given each road segment knowing expected speed, and "X+1" just extending into untraveled areas.
The Isochrones [0] mentioned in the article include basically all the necessary information. I guess a capable GPU-shader programmer could easily render the distortion in real time. (Hint Hint Hacker News for a cool weekend project)
The problem isn't in getting the data for the transformation but to figure out which transformation to use. It's not possible to do in the general case, imagine e.g. an infinitely quick circle line. Where do you put the part of the map that's inside the circle?
An infinitely quick circle would reduce to a point. Morphing a 2D map in 3D, I would imagine the inside of the circle like a balloon with the circle as the opening. Reducing that to 2D seems impossible without breaking it somehow.
I guess the problem is worth at least a paper, if not a dissertation. Maybe there is some esoteric math paper in topology which already solved that? Or has proven it impossible?
I think as far as figuring out the transformation to use on the a generic map I would:
0) ignore stuff like "infinitely quick" since that isn't realistic for what we are doing :-)
1) For the map I am displaying, pick a handful of points of interest to hse as controls, as well as my current location.
2) Use existing data we already have for stuff like direction routing to get travel times between all the pairs in our points of interest.
3) Draw a weighted graph, where each vertex is one of our points of interest and each edge is weighted by travel time. The initial position of each point should be it's geographic position, but we can then use an existing graph layout algorithm that uses an energy-based method (e.g. pretend the edges are springs) to deform the graph. This way each point will end up with its distance being proportional to travel time.
4) Using initial points as our input control points, and their location in the graph as output cobtrol points, use any number of image warping algorithms put there to calculate our warp / morph / deformation field.
5) Apply to initial map image.
I don't know how well it would work in practice but seems like a reasonable first stab at it! :-)
There's no reason your distance graph should correspond to any continuous mapping of the plane. Two distances constrain a third point to one of two spots. Add a third distance and unless you get lucky, there will be no valid corresponding point in the codomain.
That is absolutely true, and I fully admit that there isn't going to be a perfect way to do this unless you are very lucky. I'm only curious if you could use a method like this to make maps like shown above at http://www.spiekermann-wegener.com/mod/time/time_e.htm where it's approximately correct in a somewhat useful way.
My gut says it's probably more realistic to do this for large scale maps (say between major cities, 100s of miles, where distance is pretty proportional to travel time). Once you get down to the city / street level, yeah it probably gets real dicey with high variation in travel speeds depending on the particular road and how routes are laid out, and you just aren't going to get pretty triangles fitting together nicely :-P.
That looks pretty good! It seems like the transformation could be done reasonably quickly, maybe with a two-component texture (not sure how efficient texture sampling in vertex shaders is), in the vertex shader(s) in that Mapbox GL instance right after the basic projection. I might give this a go. It might get a bit weird around the edges though, gotta make sure to have a margin of additional geometry.
> not sure how efficient texture sampling in vertex shaders is
On a modern GPU, it's basically just as efficient as in pixel shaders, with two caveats:
1. If you want mip-mapping, you have to do LOD calculations yourself, which is likely a bit slower. (Not an issue in what you have in mind.)
2. There are questions around the locality of your memory accesses. As long as you lay out your vertices more or less along a space-filling curve (which is a good idea for grids anyway, due to vertex reuse) you should be mostly fine. Obviously the details will vary depending on the exact architecture.
I suspect it would be relatively straightforward. Treat each datapoint as origin of a voronoi cell, in both realspace and travel-timespace. This would give you appropriate cage boundaries on both maps, and the transformation between them should be easy.
It'd be cool to see a similar map at relativistic scales that shows the relationship between travel time for different speeds and the elapsed time at the origin and destination.
I would love a distance map that includes public transport travel time. For example, if I live close to metro/subway/train and I want to do really big grocery shopping. It would be interesting to see the nearest grocery that includes those I could reach by jumping on the metro and with minimal total walking.
It may be more effective to catch the train to a grocery in a completely different part of town than to walk 30 minutes to the one in your own neighborhood.
I wrote a tool that kinda does that. It shows how far you can travel by different modes of transport, including public transit. It also work with time of day to account for both bus schedules and traffic.
Applied to the maps in the article, this could end up introducing animation to the chart. If your local light rail arrives every 30 minutes, then your ETA to arrive at various different grocery stores is gradually changing, drawing nearer to the center, and climbs up a steep (half hour) cliff when you aren't close enough to the station to catch the train.
You could even colour the destinations by level of urgency - blue for destinations where you can casually stroll to the station, or red for ones where you really need to leave right away to catch the train.
I can't seem to run a search in my location in NY. "Find Me" changes the address but the results are stuck in Seattle. I can't seem to change the query term either.
How is this more useful than an ordered list of search results, exactly? Once you've picked your destination, based on travel time, you still want figure out how to get there.
The map doesn't guarantee that at all. Two items on the map can appear next to each other and take a very long time to get between -- perhaps they're separated by a freeway that you can't cross, for example.
Imagine a long river with a bridge at the point you are currently located, but no other bridges. Two places across from the river from each other might each be an hour away, but two hours apart from each other because you have to come back to your current location to cross the river. They'd look nearby on this map because they're in close places and similar times to get to.
This is actually an extremely common case with public transportation:
There are two channels of buses going N-S in the city, and both channels meet downtown. From downtown, two locations can be about equally distant in travel time northwards, and nearby in E-W distance compared to their N-S displacement, but they're separated by a freeway and lie on different N-S channels, and so the E-W distance takes as long to commute (by foot or transit) as going downtown and back northwards would.
That's an interesting and commonly occurring case for this kind of map. I wonder if the visualization would be improved by introducing visual connections between points that are nearby, and/or painting barriers between points that are close in the map but far away in reality.
Two locations that are close to a third location need not be close to each other. A and B might be separated by some barrier which does not separate them from C. Maybe a bit of an edge case, but still, not that uncommon.
That is true, though in practice it would mostly be true that destinations sharing similar travel times and similar directional vectors would typically be close to each other. If you didn't already have some general knowledge of the area, you'd probably notice the complication of a freeway when you "zoomed in" to the standard map view.
More so, it is common to want to go to more than one place in an outing. Most of the time when I am searching for the "nearest" X, I'm really searching for the X that is least out of the way between points A and B. This map doesn't help answer that question while an isochrone, or heatmap, or even standard map does.
Well it still maintains some geographic info by keeping the direction. This helps for instance in identifying clusters of places, so user can think: "If I go that way there a N other places nearby too". Also the cardinal directions are still preserved, which help to interface with user's preexisting geographic knowelege.
Well, to some degree, yes. Maybe it's even mostly true. But the fact that point A and B are close to point C by some mode of transportation does not guarantee that they are close to each other. They might be separated by some geographic feature like a river, mountain or large road that doesn't separate them from C. Or the transportation options between A and C and between B and C may be excellent, but horrible between A and B. And so on. You need a normal map, or very good prior knowledge of the geography indeed, to know that.
It lets you quickly see which search results you're walking toward and want to check the details on. You could get the same info from reading a result list, but if this takes less attention it's a good presentation.
If you click on A, you will be able to see if it is close to B or not. Or, more generally, clicking on a few points in a cluster on this map should give you an idea of whether you'll be able to travel easily between places once you get there. So I don't think it's as useless as you are making it out to be.
Then again, I fail to see how this is a major improvement over just clicking the first location of interest in an ordered list to generate a new list etc.
My main point is that to me, you're either interested in going to the closest location from where you are, and you'd probably want a brief description of each location to filter out points of interest to you. A list is just as good if not better (since you can quickly glance more information about each place) for that purpose.
Or else you're interested in the geography of the different locations or their exact spatial relationship and then you need a normal map anyway.
Sure, this is a neat geographic data visualization, but I just can't see myself using it in a real world situation.
Honestly I think a standard map with the times for destinations of interest shown in a little caption next to each point would be more useful. That preserves the geographic location information visually.
Well, it's easier to see the distribution of distances. Knowing something is the 3rd closest is less useful that knowing it is actually 30 minutes away.
This map isn't for navigating to the place in mind; it's more of a discovery tool based on travel time. Pick a place and then you get a standard geography based map.
Ostensibly, these kind of maps imply the time-cost of those obstacles more accurately than a standard map in which as-the-bird-flies distances are more explicitly shown.
It does account for it, but only for one starting point. So the spatial relationship of the objects to each other mean less than the relationship of the objects independently with the starting position (the centre). A user would have to do it multiple times manually, or specify some kind of travelling salesman route to figure out the best way. I think our brains do this more efficiently and quickly but this would really be worth looking into with this new map.
Isochronic maps are pretty awesome. However, an isochrone-only projection that ignores geography is prone to the same sort of errors that the alternative creates. One simple example that is personal to me -- when I moved from SF to the East Bay, my commute into the city shortened by ~10 minutes because of where I'd been living (out by Ocean Beach) vs where I moved to and the nature of driving and public transit in the SF Bay Area. And yet as far as my friends who lived and worked in SF were concerned, I was now in this mystical place that they didn't really spend any time in or know much about (the perception of Oakland is also contributing here).
It'd be interesting to take travel data and cluster it such that you end up with an isopsychochronic projection. Commute visualizations I've seen end up feeling kind of close.
Of course, distance on this map corresponds to travel time only so long as one of the points is the center; for a multi-leg trip, it still essentially requires manual inquiry and comparison.
Pretty neat. I frequently use the example of Yelp's list and map views as an example of how maps aren't always better, even as they are more appealing compared to a text list. But I frequently use the list view because I can sort by distance, while still seeing the other important info (such as star rating, cost, food type).
But distance isn't the only important geospatial factor. Frequently I want to find a place to eat/drink that's on the way to another destination (such as a movie theater). This kind of chrono map would be more useful in a new city in which I don't know that a place 0.2 mi away to the west involves crossing an interstate. In a setting I'm familiar with, it's probably not particularly useful on mobile (given the limited dimensions for showing points and text labels), but could be great on print displays. It'd allow designers to show geospatial/time info without also having to render a full map.
On the topic of Yelp and other listing services, maybe some refinements could be made to make lists more geospatially useful. No reason why the list view has to show just distance, rather than time traveled. Or to include a filter option for direction, so that I can just see things west or south of me. It's pretty frustrating sometimes having to switch back and forth between list and map.
My searches for food in Bellevue, WA found a Thai restaurant that closed 6 years ago (Tewada Thai), and a Mexican restaurant that left 2 years ago (Tres Hermanos).
I noticed that for "lunch", "sandwich", "food" in Toronto as well. Strange, since the demo claims to use the Foursquare API, but the same queries in the app offer better/more relevant results.
As a user, I would prefer two options:
• an isochrone preserving relevant geometry geography and transit
• a relative time ordering like this, but with the X and Y dimensions subject to change based on my current interests.
I.e. I appreciate radius from center as a very useful representation of travel time.
But I would liberate X and Y to be things such as rating and cost (to give two likely examples).
Once you distort space so you might as well go all-in (in this view) and let it pack in two more dimensions.
The resulting clusterings would be very interesting and useful I imagine.
This is a pretty neat idea, and I could see myself using this in day to day life.
It's nice to see real thought, study and execution into new ways of portraying things that have the possibility of becoming stale. While maps and their functionalities are very much "still in development" with many developers adding new features to them... most of these "new features" don't try to rethink how we see and use them. They just extend the feature set instead of stopping and trying to re-think what a map is and what it is supposed to do.
You don't think there are thousands of people working on exactly this stuff already?! There is deep research into this in academia and the private sector which has been going on for decades :|
I actually think this is a step too far, conceptually. The isochrone map actually maps better to how I think about travel, and I would find it much more useful.
A pet project I've wanted to do for ages is to hack up a very high-detail (factoring in every road/footpath) isochrone map centred around my home, using openstreetmap data and render the result for a printshop at e.g. 600dpi to create a high quality map/poster
Any suggestions for the best (open) software to achieve this?
I think this is great, but I can see it being potentially improved further if there was a temporary overlay of the physical map whenever you hover over a destination.
Basically, I feel that completely removing the physical map is okay until you've picked a target. Then, having to click on it to be able to see what the route looks like (which streets to take, etc.) is higher friction than I'd like. Instead, imagine if hovering would give you a route overlay, and as you hover your mouse over multiple places you're considering, you're already aware of the physical directions as well.
Having to click back and forth feels quite constraining.
This is simply feedback on a way I think it could be improved further, not to take away from how good it already is.
Location cues like "near the lake" or "near the train station" or "near the homeless camp" are critical pieces of information for me before I pick a target.
Haven't fully thought it through, but I think such a projection would be unintelligible in most cases - it would probably only look remotely 'intuitive' if travel time would always increase with distance.
For a real city, it would likely just be very weirdly morphed blobs of the map all cut up and smushed back together, with bizarrely curved roads, non-aligning roads & train lines, etc.
The more I think about this, the more I'm convinced it'll work. Somehow making the map truly dynamic by changing the scale according to the time it takes to reach the destination will be helpful. So the scale of the map changes as per the traffic and other factors that affect the time taken to reach specific destinations.
This should work, yeah.
Best, although I don't really know how you'd do it computationally, would be something like a London Subway map... schematically correct but only geographically accurate in a broad sense.
And given a suitable vector representation of the street layout, the stretch-and-compress could be given constraints so as not to warp (i.e. curve streets on) the map
Perhaps you can go even further and try to make it so that any two points have pairwise correct distances, like in the Azimuthal equidistant projection?
Perhaps there are metric functions where this is not possible (a quick proof eludes me...[1]), but approximations might be possible anyway.
[1] Edit: actually it's quite simple. Any non-isotropic metric cannot have an Euclidean equidistant projection, simply take a pair of points lying in rays (1,0) and (0,1) in an L^p metric, p not 2, as a counterexample.
Edit2: Forget everything I said :) My geometry is quite rusty I guess. Not only any non-isotropic metric cannot have an Euclidean equidistant projection, any non-Euclidean metric clearly can't have an Euclidean equidistant projection. Metric spaces are defined by pairwise distances! What you can do however, is make the distance to 1 or 2 arbitrarily chosen points correct.
I actually did this for my bachelor's thesis[1] (maps on p52-53). It's not a pure time-distance representation (constraints on angular distortion to preserve similarity to conventional maps), but anyway. Data is from railway/tram time tables.
I don’t think this is a transformation that can be performed by only stretching and deforming the surface (e.g., the maps of a city with time units vs distance units aren’t homomorphic).
Imagine starting on the far south end of a congested city surrounded by a circular, relatively low-traffic highway. Points on the northern end of the city would be “closer” on such a map than points directly in the center.
You could certainly define a transformation that accounts for this, but I think it would necessarily defy most people’s intuitive interpretation of such a map.
You could resolve it by cutting the circular highway att the furthest point, and let the surrounded are baloon out. The map would still make sense close to the user.
It really shines in dense urban areas like the example in Oakland CA. The route overlay would be really important if there's anything like super busy roads or no sidewalks available.
It's also kind of interesting that you can draw some pretty strong inferences about neighborhoods once all the geographic cruft is wiped away. For example, from where I'm sitting in Midtown, Manhattan's east-side retail development bias is clearly revealed by a search for "Starbucks:"
I am finding it useful in realizing that some restaurants, stores are actually closer than assumed. This visual removing roads, hills is useful. It would be helpful to be able to toggle a normal map with all points, not just the selected on.
206 comments
[ 3.6 ms ] story [ 228 ms ] threadNonetheless, an interesting concept!
[1]: http://property.mapumental.com
[2]: https://wiki.openstreetmap.org/wiki/Isochrone#Examples
[0] https://www.mapbox.com/bites/00156/#10/51.6840/-0.1480
An infinitely quick circle would reduce to a point. Morphing a 2D map in 3D, I would imagine the inside of the circle like a balloon with the circle as the opening. Reducing that to 2D seems impossible without breaking it somehow.
I guess the problem is worth at least a paper, if not a dissertation. Maybe there is some esoteric math paper in topology which already solved that? Or has proven it impossible?
0) ignore stuff like "infinitely quick" since that isn't realistic for what we are doing :-)
1) For the map I am displaying, pick a handful of points of interest to hse as controls, as well as my current location.
2) Use existing data we already have for stuff like direction routing to get travel times between all the pairs in our points of interest.
3) Draw a weighted graph, where each vertex is one of our points of interest and each edge is weighted by travel time. The initial position of each point should be it's geographic position, but we can then use an existing graph layout algorithm that uses an energy-based method (e.g. pretend the edges are springs) to deform the graph. This way each point will end up with its distance being proportional to travel time.
4) Using initial points as our input control points, and their location in the graph as output cobtrol points, use any number of image warping algorithms put there to calculate our warp / morph / deformation field.
5) Apply to initial map image.
I don't know how well it would work in practice but seems like a reasonable first stab at it! :-)
EDIT: Apologies for typo, fat fingers on mobile!
My gut says it's probably more realistic to do this for large scale maps (say between major cities, 100s of miles, where distance is pretty proportional to travel time). Once you get down to the city / street level, yeah it probably gets real dicey with high variation in travel speeds depending on the particular road and how routes are laid out, and you just aren't going to get pretty triangles fitting together nicely :-P.
In any case its a fun problem to think about!
I would love an HN/GoFundMe or Patreon mashup, where people could take on cool hacks in a thread that readers are willing to support.
I have zero free time at this point in my life, but would be willing to throw some money at folks who do have free time and skills.
On a modern GPU, it's basically just as efficient as in pixel shaders, with two caveats:
1. If you want mip-mapping, you have to do LOD calculations yourself, which is likely a bit slower. (Not an issue in what you have in mind.)
2. There are questions around the locality of your memory accesses. As long as you lay out your vertices more or less along a space-filling curve (which is a good idea for grids anyway, due to vertex reuse) you should be mostly fine. Obviously the details will vary depending on the exact architecture.
It may be more effective to catch the train to a grocery in a completely different part of town than to walk 30 minutes to the one in your own neighborhood.
https://blog.forrestthewoods.com/visualizing-commute-times-3...
https://www.mapnificent.net
You could even colour the destinations by level of urgency - blue for destinations where you can casually stroll to the station, or red for ones where you really need to leave right away to catch the train.
I can't seem to run a search in my location in NY. "Find Me" changes the address but the results are stuck in Seattle. I can't seem to change the query term either.
There are two channels of buses going N-S in the city, and both channels meet downtown. From downtown, two locations can be about equally distant in travel time northwards, and nearby in E-W distance compared to their N-S displacement, but they're separated by a freeway and lie on different N-S channels, and so the E-W distance takes as long to commute (by foot or transit) as going downtown and back northwards would.
My main point is that to me, you're either interested in going to the closest location from where you are, and you'd probably want a brief description of each location to filter out points of interest to you. A list is just as good if not better (since you can quickly glance more information about each place) for that purpose.
Or else you're interested in the geography of the different locations or their exact spatial relationship and then you need a normal map anyway.
Sure, this is a neat geographic data visualization, but I just can't see myself using it in a real world situation.
It'd be interesting to take travel data and cluster it such that you end up with an isopsychochronic projection. Commute visualizations I've seen end up feeling kind of close.
http://news.nationalgeographic.com/2016/11/us-commutes-revea...
But distance isn't the only important geospatial factor. Frequently I want to find a place to eat/drink that's on the way to another destination (such as a movie theater). This kind of chrono map would be more useful in a new city in which I don't know that a place 0.2 mi away to the west involves crossing an interstate. In a setting I'm familiar with, it's probably not particularly useful on mobile (given the limited dimensions for showing points and text labels), but could be great on print displays. It'd allow designers to show geospatial/time info without also having to render a full map.
On the topic of Yelp and other listing services, maybe some refinements could be made to make lists more geospatially useful. No reason why the list view has to show just distance, rather than time traveled. Or to include a filter option for direction, so that I can just see things west or south of me. It's pretty frustrating sometimes having to switch back and forth between list and map.
I.e. I appreciate radius from center as a very useful representation of travel time.
But I would liberate X and Y to be things such as rating and cost (to give two likely examples).
Once you distort space so you might as well go all-in (in this view) and let it pack in two more dimensions.
The resulting clusterings would be very interesting and useful I imagine.
It's nice to see real thought, study and execution into new ways of portraying things that have the possibility of becoming stale. While maps and their functionalities are very much "still in development" with many developers adding new features to them... most of these "new features" don't try to rethink how we see and use them. They just extend the feature set instead of stopping and trying to re-think what a map is and what it is supposed to do.
Any suggestions for the best (open) software to achieve this?
disclosure: I work for Mapbox (on geocoding, not visual maps)
Basically, I feel that completely removing the physical map is okay until you've picked a target. Then, having to click on it to be able to see what the route looks like (which streets to take, etc.) is higher friction than I'd like. Instead, imagine if hovering would give you a route overlay, and as you hover your mouse over multiple places you're considering, you're already aware of the physical directions as well.
Having to click back and forth feels quite constraining.
This is simply feedback on a way I think it could be improved further, not to take away from how good it already is.
For a real city, it would likely just be very weirdly morphed blobs of the map all cut up and smushed back together, with bizarrely curved roads, non-aligning roads & train lines, etc.
choosing where to go for lunch will be a flash.
What would be cool about this is that it is still a map of the map, but the unit becomes time adjusted mile.
https://en.wikipedia.org/wiki/Azimuthal_equidistant_projecti...
Perhaps there are metric functions where this is not possible (a quick proof eludes me...[1]), but approximations might be possible anyway.
[1] Edit: actually it's quite simple. Any non-isotropic metric cannot have an Euclidean equidistant projection, simply take a pair of points lying in rays (1,0) and (0,1) in an L^p metric, p not 2, as a counterexample.
[1] http://lazarus.elte.hu/hun/digkonyv/szakdolg/2013-bsc/baranc... (in Hungarian)
Imagine starting on the far south end of a congested city surrounded by a circular, relatively low-traffic highway. Points on the northern end of the city would be “closer” on such a map than points directly in the center.
You could certainly define a transformation that accounts for this, but I think it would necessarily defy most people’s intuitive interpretation of such a map.
[1] https://mapumental.com/)
https://imgur.com/0jXYeRW
If you center on the Central West End in St. Louis, you can clearly see that development has mostly happened in the western suburbs:
https://imgur.com/yxnVkiK