Toolbox wishlist

Earlier this week, the conversation on Software Underground* turned to well-tie software.

Someone was complaining that, despite having several well-tie tools at their disposal, none of them was quite right. I've written about this phenomenon before. We, as a discipline, do not know how to tie wells. I don't mean that you don't know, I know you know, but I bet if you compared the workflows of ten geoscientists, they would all be different. That's why every legacy well in every project has thirty time-depth tables, including at least three endearingly hopeful ones called final, and the one everyone uses, called test.

As a result of all this, the topic of "what tools do people need?" came up. Leo Uieda, a researcher in Brazil, asked:

I just about remembered that I had put up this very question on Tricider some time ago. Tricider is not a website about apple-based beverages, but a site for sharing and voting on ideas. You can start with a few ideas, get votes and comments on them, and even get new ideas. Here's the top idea as of right now: an open-source petrophysics tool.

Do check out the list, and vote or comment if you like. It might help someone find a project to work on, or spark an idea for a new app or even a new company.

Another result of the well-tie software conversation was, "What are the features of the one well-tie app to rule them all?" I'll leave you to stew on that one for a while. Meanwhile, please share your thoughts in the comments.

* Software Underground is an open Slack team. In essence, it's a chat room for geocomputing geeks: software, underground, geddit? It's completely free and open to anyone — pop along to to sign up.

It even has its own radio station!

Have some bacn

You might have noticed a lot of emails from Canadian companies recently, asking you to confirm that you wish to receive emails from them. This is because a key part of the 2010 anti-spam law comes into effect tomorrow. We haven't sent you anything, becase we have always complied with the spirit of the law.

What is spam?

We all know what spam is, and the Canadian government's definition is plain:

commercial electronic messages [received] without the recipient's consent

And here's a definition of bacn (pronounced 'bacon') from author Jonathon Keats:

Spam by personal request

This seems to contradict the first definition, but the idea is that bacn is better than spam, but still not as good as a personal email. It's commercial email that you asked for. (Aside: according to that same author, bacn from geologists is quakn.)

Email from Agile*

Because we want you to have as much control over your inbox as possible, I have just switched our email subscription service from Feedburner to MailChimp. One of the reasons is MailChimp's excellent and rigorous anti-spam policy enforcement. Their emails make it very clear who an email is from, and how to unsubscribe from them. 

If you receive our blog updates via email, I hope you see them as a service and not a nuisance. If you're unsure about subscribing because you fear receiving promotions and so on — I promise that all you will ever get is our blog posts. It's just a convenient way to read the blog for some people. 

Just to be clear:

  • We will never add you to a mailing list that you didn't expressly subscribe to.
  • We will always give you an easy way to unsubcribe.
  • We will never share your email address or name with anyone else.
  • We will only send you emails that have an obvious Unsubscribe option.

Other ways to read

Here are some other options for subscribing to our RSS feed, which you will find at /journal/rss.xml 

We want you to be able to easily find, read, interact with, and share our content. If there is some other way we can serve you, please let us know

The can of spam image is by Flickr's Clyde Robinson and licensed CC-BY.

Machines can read too

The energy industry has a lot of catching up to do. Humanity is faced with difficult, pressing problems in energy production and usage, yet our industry remains as secretive and proprietary as ever. One rich source of innovation we are seriously under-utilizing is the Internet. You have probably heard of it.

Machine experience design


Web sites are just the front-end of the web. Humans have particular needs when they read web pages — attractive design, clear navigation, etc. These needs are researched and described by the rapidly growing field of user experience design, often called UX. (Yes, the ways in which your intranet pages need fixing are well understood, just not by your IT department!)

But the web has a back-end too. Rather than being for human readers, the back-end is for machines. Just like human readers, machines—other computers—also have particular needs: structured data, and a way to make queries. Why do machines need to read the web? Because the web is full of data, and data makes the world go round. 

So website administrators need to think about machine experience design too. As well as providing beautiful web pages for humans to read, they should provide widely-accepted machine-readable format such as JSON or XML, and a way to make queries.

What can we do with the machine-readable web?

The beauty of the machine-readable web, sometimes called the semantic web, or Web 3.0, is that developers can build meta-services on it. For example, a website like that finds the best flights, wherever they are. Or a service that provides charts, given some data or a function. Or a mobile app that knows where to get the oil price. 

In the machine-readable web, you could do things like:

  • Write a program to analyse bibliographic data from SEG, SPE and AAPG.
  • Build a mobile app to grab log mnemonics info from SLB's, HAL's, and BHI's catalogs.
  • Grab course info from AAPG, PetroSkills, and Nautilus to help people find training they need.

Most wikis have a public application programming interface, giving direct, machine-friendly access to the wiki's database. Here are two views of one wiki page — click on the images to see the pages:

At SEG last year, I suggested to a course provider that they might consider offering machine access to their course catalog—so that developers can build services that use their course information and thus send them more students. They said, "Don't worry, we're building better search tools for our users." Sigh.

In this industry, everyone wants to own their own portal, and tends to be selfish about their data and their users. The problem is that you don't know who your users are, or rather who they could be. You don't know what they will want to do with your data. If you let them, they might create unimagined value for you—as does for airlines with reasonable prices, good schedules, and in-flight Wi-Fi. 

I can't wait for the Internet revolution to hit this industry. I just hope I'm still alive.