Exploring the Bakken using WebGL

In the spirit of Done is Better than Perfect, we recently unleashed Subsurfr, a 3-D subsurface visualization web app for oil and gas.

We primed it using 17,000 wells from North Dakota. Since the Bakken shale is a very active play, some geologists and engineers are going to be very happy to have this new arrow in their quiver. Here's a fun look at the very busy Bakken from a well planner's pov.

Building this app pushed a lot of boundaries (for us, anyway). First among them was WebGL. And to broaden the reach to IE, we use Chrome Frame. But also, Subsurfr is a mashup, and exercises Cross Origin Resource Sharing (CORS) capabilities to permit it to use data served directly to the browser from a variety of sources. We also experimented with BrowserID, and OpenID + OpenAuth before chucking identity altogether this iteration -- the business driver isn't in place.

WebGL is a lot more mature and stable than I would have expected. After all, the spec has only been finalized in the last few months. But, after you get past the unfamiliarity of the GL computing model (GLSL, vertex shaders, fragment shaders), and the
trial and error nature of debugging (you can't even print to a console from GLSL) , I found our code just works on every WebGL platform, including Firefox on my Android phone.

Although three.js seems to be the weapon of choice for most new WebGL projects, I chose the lower level threedlibrary (tdl). I didn't do a lot of comparison shopping before I made that decision. It turned out to be a good choice. Because tdl is close to the metal, I never ran into any WebGL capability that I needed but could not use. Yet, as a WebGL noob, I needed the structure of tdl -- tdl taught me how to use WebGL properly while I was actively developing working code. 'Cause that's how I roll. I'm not going to spend $50 on a WebGL book and research the 5 top libraries and do a three week test project in each one before coding.

The web pages making up Subsurfr itself are totally pregenerated -- presently about 35,000 of them. 'Course, lots of the data still comes down via ajax to the browser from the cross-origin servers. By serving only static pages, Subsurfr can run on a small nginx server. How the ajax data servers are going to hold up -- ask me in a few weeks.

CORS itself is a minor challenge. First, it does not run in IE < 10. That's not a problem for Subsurfr because Subsurfr already has to use Chrome Frame to run in IE. However, we use MapQuest as our map server, and they never heard of CORS. Consequently, we chose to proxy our XHR calls to MapQuest via our own server which adds the CORS headers. Additionally, we use the dojo toolkit to execute those XHR calls, and dojo has its own issues there. Finally, our own drilling data server had to be retrofitted to send the CORS headers. So we have several workarounds and patches to get all the CORS stuff going. Still beats IFRAMEs.

Anyway -- check out subsurfr.com to see some real world WebGL in action. If you are interested in Subsurfr from an oil and gas perspective, I've written more about it here.





.