Dates in the Oil & Gas industry data can be a little tricky.
Especially when aggregating data, such as production volumes, to a daily level, and trying to connect multiple tables with date columns.
Some tables, such as tank levels or production volumes, could be based on a Gauge Date (aka Report Date) since the data is measured, aggregated, reported or “gauged” on that date (today), but in essence it is yesterday’s data, or to be more accurate, it is the data for the 24 hour period that began yesterday at the contract hour (e.g. 6am) and ended today at that same time, or the Production Date.
Other tables could have actual dates, such as sales tickets, run tickets, operation logs, etc.
Most websites that offer Nutrition Facts and Food data lookup functionality seem to offer a top down, food driven search function. First you select or search for a food and they return the nutrition facts for your selection. I was looking for the opposite and I couldn’t find it. Thanks to Power BI, I was able to build one in minutes, here’s how I did it…
One evening last week I wrote an important email to a client and I thought I sent it but I didn’t. I wanted to let the client know their project is ready so in the morning they can start using it. And after I finished writing that email, while checking for typos, I got distracted by something, and by another thing…and I never sent it that night.
Over a decade ago I had the pleasure to create a small desktop application for Chammas Cutters, this was the Grain Selector tool pictured above, and it helped their clients quickly determine how much gas-generating grain to use in the application of their chemical cutter tool.
While pretty basic (and written in it) the desktop application served a good purpose for the past 10 or so years. Prior to the desktop application, clients would have to resort to a rather bulky and complicated spreadsheet-type catalog tables, which can be more time confusing and can lead to human error.
Now that it needed to be improved or rewritten, I decided to replace it with a Power BI report that took just a few hours to create. Here’s why I chose that path:
About a year ago (March 2020) We needed a line chart that can do the following:
Allow the viewer of the report to change the Y axis scale on the fly
Allow the X axis to be placed near the top of the chart
Have the ability to invert the Y axis*
When we started, we didn’t want to reinvent the wheel, so we searched first but couldn’t find a chart on the App Source marketplace that could do all of these thing I listed above*. So we started creating our first custom Power BI Chart Visual: CHARTURO
As an end-user of a Power BI report, a chart that looked great at first might look not so great once you start applying filters or using slicers. Very large values in the data might throw off the scales and now your line chart might be suddenly all squeezed at the top or the bottom. Does any of the above sound familiar?
Usually it’s the report designer who has all the power, this article is about giving more power to Power BI end users…
End users’ ability to change the scale, appearance or formatting of that chart is limited. That’s why I started creating the Mi4 Line Chart Power BI custom visual that lets you switch scales on the fly, and eventually have more overall control of the visual without having to edit the report.
Last week I wrote a blog post talking about the TX RRC publishing data to the public that previously was only available via a paid subscription.
After downloading the different data sets and examining the various types of data and formats, I decided to take a closer look at the data that might prove to be useful to us and to our Productioneer clients.
It is not uncommon for location and depth data, as well as other well-header and meta data to be incomplete or non-existent during a software migration, after all this data might not be considered crucial for the daily gauge sheets. Especially in the case of Excel gauge sheets, where additional columns are a waste of “prime real estate” and might be considered as cluttering that particular production report.
It would be nice if we have a quick way to pull the Lat Long data in bulk to speed up the on-boarding process.