Could there be anything more fundamental than the study area? Or better yet, why do you need a GIS to choose point A and B? Well you don’t, that’s the point. Hope you enjoyed the first article….hold on a second now, that’s not why you’re reading this, but the fact remains that when and if it comes to siting any linear asset you don’t need a GIS in any part of the process. But then again, I don’t need to use a computer to type these words, or a calculator to add some numbers, or the internet to search for information – surely I could just stick my head in the sand and allow the world to pass by. That was yesteryear and the old school way of doing things just won’t cut it anymore when the people, the stakeholders, we need to please have high expectations which are ever evolving.
Stakeholders can take a wide variety of shapes and sizes with respect to interests and influence, in general, though the only stakeholders considered in our context are Decision-Makers, Decision-Blockers, those affected by the decision outcome, Expert Witness, and the Antagonist (Squeak squeak).
The reality of the situation is that the start and end points of any route are typically the easiest to determine, there is a supply at one end and a demand at the other. It doesn’t really matter if the desire is to move product through a pipeline from a newly developed field into a needy market (“I think there are probably a billion people who would agree about the importance of this”) or a better way to move people in an already mature transportation network (all you have to do is watch the Discovery channel to know that tunnels through mountains mean shorter and faster railways).
The challenge (and one we’re prepared to take on) is to determine how best to connect these two points, but doing this part is just math, albeit fancy math, within a GIS. We’re not just interested in doing the math, we also want to be able to describe and defend the process in front of our internal audience, like management, or an external audience, like stakeholders, and when it really matters, during the information request and “trial” phase of the approval process (let’s not even get started on the irony of the name of this process).
Anyway, the fun part about writing online is that you can do it with the personality and commentary that is so evident in the real world. Let’s answer the question first then and plug away at the details. The answer is “Yes”; the study area is not the fundamental building block of decision support using GIS, Gasp! So what is more fundamental than the study area? It is, simply stated, the need expressed by the client, because in practice, without such a need why would we study anything?
Our next Decision Support article will outline some of the approaches we’ve used or seen used over the years when defining study areas.
My last post was just meant to highlight two issues that we encounter far too often in the world of spatial data management. If it wasn’t obvious from the stories/examples provided let me be a tad bit more deliberate…
The first is that for too many years we (as spatial practitioners) were forced to work with virtually all of our attributes information stored in the spatial coverage (read: generic reference to vector data format). What this lead to is us (read: the spatial community) getting into a mindset where we expect all attributes to be at our ready and many of our workflows, and the tools to support the workflows, are designed around this base assumption.
The second point was simply that the tools and rules available to us in the world of spatial data modeling do not have the same solid underpinning as those available for relational modeling. Sure there are some really great academic books on spatial data types but the number of good references for designing a usable and extensible (while still having good performance) is slim to none.
In the next post on this topic I’ll begin addressing this second issue by proposing some rules we can use for framing out a spatial database built on ArcSDE. Then, in a few posts time, I’m going to show some pretty cool stuff…automagic creation of a spatial data model components from relational database metadata. Way cool!
What is it about an ellipsis, that elusive punctuation mark that doesn’t exist on the keyboard but can be used to parse apart something profound into meaningless babble, or to turn meaningless babble into something profound?
Spatial database modeling…I’m sure there are user groups and sites devoted entirely to this topic (and if there are not then maybe this solves my questions in and of itself) yet there just does not seem to be enough people around who truly understand what goes on underneath the hood. Now I’m not talking about understanding the bits and bytes or the 1’s and 0’s (that’s for propeller-heads — to steal a saying from a co-worker of mine) in the underlying technology but more about how to stitch together a solid spatial database model. No shortage of information on how to do this for relational database modeling but the body of knowledge seems to be a wee bit thin from the spatial point of view.
Quickly, a little background, in my particular case the poison of choice for geographic information systems (and hence spatial databases) is ESRI so I’ll be using geodatabase terminology throughout this post Okay, enough background, oh, and I should warn you that I’m not going to get technical in this post, just want to frame out the situation so we can continue getting into some nuts and bolts discussions later.
First anecdolt of the new blog, had a meeting a couple years back where this self proclaimed database architect took me through painstaking detail on their plan for implementing a spatial database model. The conversation (read: monolog) we one for a just under an hour where the architect spoke about update processes, frequency of updates and maintenance windows, extract/transform/load approaches, …, …, and and and, …, …, and so on. All of that was pretty cool and fairly standard stuff, but then, sweet music to my ears, the architect said they were planning to use the capabilities of a geodatabase! Sweet! No longer did I need to bite the insides of my cheeks to stay awake, this was interesting stuff! Then, out of nowhere flash, poof, the old adage of “waiting for the other shoe to fall” came to mind, didn’t have to wait long for the shoe to show, the reason and only reason, get this, for using ESRI geodatabase capability was so that they could use feature datasets like a folder structure…a common temptation for people just cutting their teeth on geodatabases, but not the type of technical reasoning I would expect from an architect.
Another anecdolt, this one from last summer…In a meeting with some really (and I mean really) smart GIS professionals and some really good IT folks the conversation was about implementing ArcSDE on top of an existing relational data model so that there could possibly be better integration between ArcGIS and another pure relational database application. Sounds like a good idea and absolutely it is a good idea. But we’ve all been in those meetings where an idea gets nods around the table and that really should be the end of the conversation until everyone spends just a little more time thinking it all the way through?? Even if you haven’t been in one of those meetings it was one of those meetings. One of the IT folks wanted to start solutioning and did it from the point of view of “problem space” versus “option space”, in other words, talking about how this couldn’t work because of blah, blah, this, that, blah, blah, and then the kicker, the reason that sealed the deal, the reason was that the relational database model used by the pure relational application was not well thought out for use with GIS. Uh oh, this can always pose a problem, until you realize that what they meant was that the relational database was normalized. Wait now, on what planet is a normalized an evil thing? One of the lectures I teach on spatial database modeling uses the tag line “flat: bad model for the earth, bad model for a database”…I’m definitely a proponent of normalized daabases, especially in the world of GIS.
These couple of anedolts show a couple of sides to spatial data modeling and serve as a starting point where we can dive into some ideas I’ve got on turning relational database models into useful geodatabases. In upcoming posts I’ll shed some light on what the learnings were from the anecdolts above as well as getting my geek on to uncover so really nifty neato tricks for automagically translating well formed database models (PPDM and PODS seem to make the most sense since I’m in the energy sector and a member of each organization) in ESRI geodatabase speak.
Great question and one that most people may ask as they see this series of articles unfold over the coming months, and if we have enough fun with it, years. What we plan to address is the role that Geographic Information Systems (GIS) take in decision support and although others have given this same topic a solid trashing there has always been, in the author’s mind, an embedded mystique in the pracademic (coined term to acknowledge the attempt of academics to practice GIS within a practical/industrial sense) writings that kept the casual GIS user or even savvy managers from embarking on fully realizing the potential value.
So “the degenerate line”, or in more colloquial speak, “the point” of our articles and abstractions is to serve the GIS community with practical observations and insights on the practical usage of GIS in decision support. We’ll begin the series by showcasing a range of techniques for siting of linear assets such as roads, railways, and (our favorite) pipelines.
Unless you’re a baby bird then regurgitation likely just doesn’t do it for you, don’t worry, it doesn’t do it for us either, we’ll give you some real content that goes beyond ctrl+c/ctrl+v from help docs.
Filed under: General
Houston in the summer time! Tourist destination? Depends who you ask — like my wife and I found out a few years ago on a trip to the sunny south (she had never been to Houston so we went for a long weekend) border guards just don’t believe you when you tell them you’re just making a personal visit.