The Return of the Mullet and Corporate Mashups
November 3rd, 2006by Sean Gorman
Just got back from Barcelona yesterday where we were demoing our technology to folks from British Petroleum. They have developed a very robust and cool mashup with MS Virtual Earth. Definitely a mashup on steroids with all sorts of goodies rolled in ranging from video to IP based coms. It is great to see an enterprise like BP making a significant investment in web mapping and mashups. They are working at being at the fore front of location intelligence and I think it bodes well for where web mapping is headed in the future and its potential to create value for the enterprise. Here is hoping many other enterprises follow suit.
A question to the crowd - a few folks we talked to over the week thought that MS was going to win web mapping for the enterprise over Google. Not sure what I think on this yest, but interested if anyone has opinions. The VE mashup we saw at BP was definately the most robust I've seen to date.
While BP treated us very well and the Barcelona beaches were awesome - there was one disturbing conclusion from the trip.... The mullet is back, at least in Spain. At first we thought it might be Spanish rednecks stuck in an 80's time warp, but no such luck. It was the hipsters - sporting mullets. Several new varieties of mullets in this apparent revival, we saw the rasta mullet - business in front and dread locks in the back. There was also the faux hawk mullet. That’s right short all over except a moused faux hawk in the back. How long before this arrives in America remains to be seen, but be on the look out.
In better news our API and Google Maps mashup will be up next week. We should have an URL up here late Monday or Tuesday for folks to check out.
Popularity: 7% [?]
Google/GeoIQ Mashup Follow Up
October 19th, 2006by Sean Gorman
Thanks for all the comments on the mashup posting. We were excited about the positive feedback and suggestions. The Digg.com posting was awesome and many thanks to Kevin Rose for posting it. The Digg traffic gave us a surprise stress test for the API. Someone clever grabbed the Mac.com homepage url Mookie was testing the mashup with and posted it on Digg. The resulting traffic swamped us pretty quickly, but gave us a chance to tweak the concurrent users parameters and it held up quite well to the onslaught once we sorted everything out. The exception being anyone using IE, who got a non transparent black heatmap. Still sorting out the alpha channel transparency issues on that one, but we'll have it all sorted for the real mash up launch. Since the URL is by no means secret anymore feel free to check it out:
http://homepage.mac.com/prak/gmap.html
A few tips 1) best to use Firefox or Safari 2) we do not have panning hooked up yet so the heat map only refactors when you zoom in 3) you can pan over to any location in the US but will not get a heat map till you zoom in 4) to get the best performance wait for the heat map to pop up before you zoom again otherwise things get a bit backed up in the queue.
We'll have panning and all the other bugs worked out for the real mashup release, but something to play with since it is not longer really secret. Please post any feedback or suggestions. We are finalizing the API for public consumption this week and should have documentation done next week and have it out for people to use shortly after.
As for the real mashup that will go with the API, we thought we'd have a little fun with it and show some of the more advanced features. So the guts of the mashup are going to be a comparison of San Francisco and New York City. We'll have detailed census block demographic data and a yet to be determined point of interest data set - current contenders are coffee shops, bars, bookstores, or some variety of restaurants. Ideally we'll do this with a Yahoo Local API feed so you can look at any point of interest, but there are some issues with that we are working on. The unsolvable one being you can't pull more 20 locations at once, but that is just a general complaint about the API.
The point of all this - showing how you can make decisions with multiple data sets - like finding the highest concentration of coffee shops in high income neighborhoods with lots of single men/women between the ages of 30 and 40. The idea actually came from a trip to a local bar here in Georgetown for an "off-site" and thinking about how we could find the best bar or neighborhood to go out for the night. Back at the office it quickly grew to where could I find the right house, the right school, the right job, the right meeting location etc. etc. It also raised a lot of questions, like does location "A" have a higher concentration of bars and single women or does location "B". Our board never liked the bars and single women analogy, but we always like the simplicity of it. So the idea with the mashup is to provide super detailed demographic data with a lot of destination locations so you can compare which location fits your needs to best. While the mashup will be NY vs SF you can also do neighborhood comparisons, NY (Soho) vs NY (Greenwich Village) or SF (SoMa) vs SF (The Haight) etc. etc. Hope it is something that will resonate with people and get folks thinking about how they could use the API to look at other interesting things.
Popularity: 12% [?]
Heat Maps for Google Maps - (a.k.a GeoIQ mashup)
October 11th, 2006by Sean Gorman
So it has been a while since we posted, but the rationale was we'd wait till we had a working example of moving past push pins. This week we got our GeoIQ API working with the Google Maps API and have the first set of screen shots to show. One of the things we thought is really missing from web mapping applications, right now, is the ability to do geographic analysis. Even the ability to make basic decisions like - is location "A" better than location "B" is missing. With this first simple idea in mind we've built a quick mashup with Google Maps. We took our heat mapping API and integrated it with a split screen Google Maps viewer. That way you can look at two locations at the same time and compare them.
We wanted a fun data set to play around with and thought traffic congestion/delay would be interesting. The Bureau of Transportation Statistics (BTS) has a cool data set with average traffic delay for all the US highways available, so we threw that in. One of the problems with pushpins or polylines in Google Maps (and others) is there is no way to visualize what are the high value or low value pushpins. In this case, which road has high traffic delay and which roads have low traffic delay. We do this with a heat map (similar to Zillow, Google Adsense, etc.) that can be dynamically refactored as you zoom in/out (see previous post). We added to this heat map tool a concentration index - which gives you a score of the value (weight) of your pushpins and how closely they are located together. Once you have the score you can see if location "A" is better than location "B". In this case is traffic delay more concentrated in location "A" or location "B"
A comparison of the concentration of traffic delay in San Francisco and Los Angeles
The GeoIQ API creates a heat map based on an index that measures the amount of traffic delay on the roads and how closely that road delay is located to other delayed roads. The higher the delay and the closer together the roads, the hotter the map and the higher the score. The score ranges between 0 and 1. If all the traffic delay and highways were concentrated at one single location the score would 1 and if there was no traffic delay the score would be 0. In the map above traffic delay for Los Angeles in .26 and for San Francisco it is .15, so if you believe the BTS data traffic, LA is about twice as bad as SF. Lets go east coast - NYC vs. DC.
A comparison of the concentration of traffic delay in New York and Washington DC
According to this score NYC is a little worse than DC. The cool thing about the technology is you can run these comparisons on the fly as you zoom in and out of the map. So - let's compare two big traffic bottlenecks in DC to see which is worse the I-270 Spur or I-95 Mixing Bowl.
A comparison of the concentration of traffic delay at the I-270 Spur and the I-95 mixing bowl - both in Washington DC
The Spur looks to get the better of the Mixing Bowl. In the app you can do this with any data set or mash up multiple data sets to solve a variety of problems surround location decisions. We'll have more to come so stay tuned if this looks interesting.
A comparison of the concentration of traffic delay in San Francisco and Los Angeles
The GeoIQ API creates a heat map based on an index that measures the amount of traffic delay on the roads and how closely that road delay is located to other delayed roads. The higher the delay and the closer together the roads, the hotter the map and the higher the score. The score ranges between 0 and 1. If all the traffic delay and highways were concentrated at one single location the score would 1 and if there was no traffic delay the score would be 0. In the map above traffic delay for Los Angeles in .26 and for San Francisco it is .15, so if you believe the BTS data traffic, LA is about twice as bad as SF. Lets go east coast - NYC vs. DC.
A comparison of the concentration of traffic delay in New York and Washington DC
According to this score NYC is a little worse than DC. The cool thing about the technology is you can run these comparisons on the fly as you zoom in and out of the map. So - let's compare two big traffic bottlenecks in DC to see which is worse the I-270 Spur or I-95 Mixing Bowl.
A comparison of the concentration of traffic delay at the I-270 Spur and the I-95 mixing bowl - both in Washington DC
The Spur looks to get the better of the Mixing Bowl. In the app you can do this with any data set or mash up multiple data sets to solve a variety of problems surround location decisions. We'll have more to come so stay tuned if this looks interesting.Popularity: 100% [?]
Moving Past Push Pins
July 20th, 2006by Sean Gorman
After watching the Microsoft Virtual Earth spiel at their CEO summit (http://www.microsoft.com/winme/0605/27736/BillG_CEO_Summit_MBR.asx )earlier this year it reinforced that the geospatial web has still not really gotten past just putting push pins on maps. Don't get me wrong MS, Google, and Yahoo and the various mash ups they have inspired have done some incredibly cool stuff with putting push pins on maps, but it has not yet evolved to providing true analysis of the push pins that allow users to make better decisions.
The one place where you do see analysis going on is with driving directions, but even that is really just starting to evolve past what Mapquest did years and years ago. In my mind the real contribution of the geospatial web to date has been unleashing the huge amount of geo-referencable data that has been sitting dormant. The easy to use features of Google Earth and KML really kicked it off by providing a dynamic and cool mapping widget for people to look at theirs and others data. The result was a huge number of mashups many times with data no one had seen on a map before like locations of houses for sales with pictures and prices or the location of registered sex offenders by street address.
In addition to looking at the push pins of where sex offenders are and where houses for sale are, the consumer should be able to numerically compare the concentration of sex offenders and home prices in one location versus another location. Go the next step and add in schools, test scores, and user rated Mexican restaurants. What are the locations that have the highest concentration of amenities to make a location attractive to home buyer, business location, marketing campaign, franchise expansion, warehouse etc. You could also calculate the concentration of risk to natural hazards for insurance and security uses. Once you start creating geo-analytics that are easy and intuitive to understand to non-technical users there are a whole host of questions people can start to answer with their push pins on maps.
This is where there is a considerable gulf between the geospatial web and traditional GIS. The geospatial web has made mapping technologies available to the masses but has not been able to provide analytics. Traditional GIS has a vast array of analytics but they are so arcane and technical only formally trained professional can use them. The trick is to harness the analytics of traditional GIS into the easy to use world of the geospatial web. Two big problems block the road to what seems like a straight forward trip. For one the average person has no clue what traditional GIS analytics are or how to perform them - in fact few professionals really understand the mathematics behind what is being done. The intricacies of inverses distance interpolation or Gaussian decays of kernel density functions are lost on 99% of the universe. Yet these are exactly the tools needed to answer the simple user question discussed above.
That is the first bridge to be crossed, but even if you do manage to simplify the labyrinth world of map algebra, you still have severe computational limitation to surmount if you want to deliver analytics to a browser. If you have every tried to run a kernel density analysis with a decent pixel resolution across a large geography on a traditional GIS - you might as well make a coffee run because it is going to be a while before you get a pretty heat map back. This is using a desk top application, not sending it to a browser, and it is creating only one heat map (raster surface). Since Google Earth the mass users are used to getting more detail when they into an image, and they will expect the same of their analytics. Producing raster heat maps on the fly is something that even high powered desktop applications cannot achieve.
We think there are creative ways to solve these problems, and hope to start a discussion with community as we get ready to launch our approach to it. Creating and any and all feedback or ideas about how geo-analytics can be evolved to create value for the geospatial web is the goal of the blog. So join in and hopefully we'll have something cool to show in the next month or so.
Thanks,
Sean Gorman
Popularity: 16% [?]





