My first reaction is that this really looks to be a step too far for the approach we've been using and that you might have to go the GIS route that Allan was originally proposing. That is especially true of the elliptical approach.
Specific things that look quite hard to me with your elliptical buffer approach:
- Determining the shape and orientation of the buffer zone for the pad and all the connected wells.You've drawn it as an ellipse, but I can't think of any way of calculating that from just the centre coordinates of the pad and the wells.
- In order to draw an ellipse we'd need to do the same trick that we used for drawing the circles (i.e. a set of boundary points), but instead of just a fixed offset from the centre we'd need some way of specifying essentially a variable radius.
- Even if we could come up with a way of determining the boundary of the ellipse, I have no idea how to go about determining conflicts with other wells.
The other suggestion (buffers around the lines between pad and well centres) sounds a lot easier - though still quite tricky. I can just about see how it might be possible to come up with a rectangular buffer around each of those lines and if I scratch my head a lot I might just be able to remember enough trig to work out how to identify conflicts. Maybe.
GIS is definitely looking more and more like the right tool for the job, though.
I was originally thinking drawing a line from each well to the pad would be more challenging then just enclosing the pad and all connected wells in a circle (or whatever roundish shape needed). If it is at all possible to draw a line with a rectangle as the buffer, that would even be more desirable to the customer anyway. The customer is LOVING this tool as it stands, it has the functionality needed. It has already caught potential scheduling conflicts and have helped to make scheduling more efficient. I'm told GIS isn't capable of this type of functionality and I've got such a beautiful thing in this tool... Scratch away...
> just enclosing the pad and all connected wells in a circle (or whatever roundish shape needed)
Just enclosing the pad and all connected wells in a circle would be easy - it's the difference between a circle and a "roundish shape" which turns it from easy to nigh on impossible (or at least beyond the reach of my trig from 35 years ago!).
Are the sets of wells associated with each pad pre-determined, or does that change?
I see. The associations would be in my dataset which is updated daily. Currently don't have an association in the data set, but for each pad, I envision a column which lists the associated wells. Not sure I answered your question...
The reason I was asking if the association between wells and pads is predetermined is that doing the whole conflict identification calculation on-the-fly in Tableau's calculation language looks a bit tricky. If the association (and therefore the collection of rectangular corridors associated with each pad) is pre-determined you could possibly pre-calculate the potential conflicts based on locations. The scheduling conflict determination could then just be a matter of looking for scheduled use of wells which are in the pre-determined list of potential conflicts.
I haven't tried to work out what the data structure would need to be - but it sounds plausible.
The spatial conflict determination could then use a GIS tool, whilst still identifying the scheduling conflicts in Tableau.
I wasn't quite clear from your answer if the actual associations between wells and pads change daily, or you were just saying that the association is represented in the dataset which is updated daily (perhaps for other things).
If the association changes daily that would mean that the GIS route wouldn't work unless you automated the whole process - i.e. wrote a program using some sort of spatial APIs, I guess.
To give you an idea of what you would need to do to calculate the whole thing in Tableau, have a read of this stackoverflow thread discussing how to identify collisions between circles and rectangles.
The pads and the wells are static in terms of association. I believe a particular pad is always associated with the same wells, unless a well abandoned or a well is added in proximity the pad.
Ultimately, I just need a way to indicate that no crews should be between the pad and wells during work, whatever the method.
That's what I thought was likely to be the case.
How many wells and how many pads are we talking about? It may be that you can build a static representation of the possible conflicts based on location manually without even using a GIS to calculate boundary intersections.
You could start with all possible conflicts between circular buffer zones calculated as we currently do and then manually add in the effect of the pad to well buffer zones. Even if you have 50 or 100 pads that could still be quicker than learning how to use a GIS!
Having got that mapping defined statically you could then join to your scheduling data to show actual conflicts as currently.
Sent from my phone - excuse the weird typos.
So, it sounds possible, which is great. We are still waiting to get the lat/lon in our system for the pads as currently none exist. I just wanted to drop the seed early to see if this sorta thing would be possible on top of the existing structure. I’ll re-engage with you once I can actually start building and testing. Thanks, Richard.