I’m not going to lie, I’m slowly mutating into one of those GIS high-level manager types who work less on real day to day map work and more about concepts and frameworks…even, at points strategizing. I hate it, give me some kriging interpolation or some hardcore viewshed analysis any day, but one thing is becoming apparent as I talk with more companies or recruit more staff, no one knows how to deal with their GIS department, and those that do, frequently get it wrong.   

Many companies know they need a GIS function but shove it in the corner to work with IT or the developers, rarely are they sat in their own team with integration into the companies functions, their sole purpose is normally to make maps or to solve extremely easy overlay location problems. So many times, have I chatted with peers and mentors at geospatial events and they have told me how the company are underutilizing them. I, therefore, think it is time to reinvent GIS & Geospatial…  

From where I sit now, I find myself dragging the GIS team into conversations that they should be involved with or providing education to companies with no geospatial capability on how it can empower them but it isn’t because the companies don’t want them, they do…it’s just that there is a gap in their knowledge.  

Think back 20 years, okay, maybe you’re not as old as me, think back 10 years, developers were a similar commodity, everyone knew they needed to get the technological advantage, but no one understood what they really did or how they could get the value out of them…that is until some big developer frameworks came in, things like DevOps and Solution Architecture which gave steps and methods for project managers and product managers to work constructively with these coding people which they had stuck in the cellar (okay, just checking you are still listening).

By employing these frameworks, the developers are free to apply their knowledge and set up core infrastructure but there are user stories, information flow maps, user requirements and wireframes of how it should work, With this information, the non-technical managers could ensure that they got what they wanted and the developers didn’t have to hide in the cellar and send emails as to why the managers got a simulated city instead of the simple model that they asked and cost for.   

You see, with that mutual understanding, both areas of business are able to talk thanks to the framework(s) in place. It is this framework that is so lacking in the GIS and Geospatial industry, a method to make it easier for the manager(s) to relate the information that they need to get the answers the client needs.   

Welcome to MapOps, I know, stupid names and complete rip-offs of the developer frameworks but the scary thing is, the framework for developers is VERY similar to that needed in GIS. See the DevOps stages below:  

  

 

DevOps is a continuing cycle, you plan, create, verify, package, release, configure and monitor, this is never fully complete so you go back to the first stage and repeat the process with a plan.  

Now think about how we GIS experts make maps, it should always start with a plan, you then create the map and then QA it, if you are doing a web map, you may package it, if you are making a PDF you may export it, you then release it. For most PDF maps you journey ends unless the data changes and the client needs an update, so you monitor to see if it needs updating and then start the plan again.  

So, here is my conceptual framework for creating an understandable structure that management can buy into, here are the outline stages,  

  

1.Plan  

There is a requirement for a map or visualization of the data but what format? What orientation? What Coordinate system? The manager won’t understand any of these concepts, so ask for a concept or a use case either from the sales pitch or better still get involved in the proposal. Write it down and send it to get their confirmation.  

2.Build  

Based on the information you’ve been given in (1), you should have all the information you need to build the map, whether it be online, PDF export, or something else. If you haven’t, then go back to (1) or create a system to document the plan better.  

Make sure you have done your metadata, you have correctly labeled your data…all stuff that your manager won’t understand but is vital to the build stage.  

3. Style  

Again, your plan (1) should outline what you need to provide but if not, test a few styles, if you work in a visual-based environment where image is important, then test the styling with another team member or trusted design type person.  

4. Test.  

You’ve got it nailed, it looks perfect, it works as planned…get it tested, don’t trust that you understood what was outlined. If the project manager okays it, move to stage 5.  

5. Deploy  

Off it goes or this is the moment you put it live on the web. Enjoy!  

6. Monitor  

All data is temporal, even historic data, does it need updating? If so, go back to (1).  

Of course, this is high level, in reality, each stage needs its own method of practice, this will provide confidence to superiors and management that they are giving you what you need and getting the answers they want. Once you employ ISO standards, workflows and some spreadsheets, you’ll start to be valuable. Introducing this to the ISO 14000 standards by introducing workflows for the stages as “Records of Practice” ensure that you can maintain an efficient area of work.  

Okay, so you don’t just make maps all day, I don’t blame you, it would drive me crazy too, even though I love maps. You also need to provide Geospatial analysis, you get odds and sods coming in all the time with people asking if you can analyze this or measure the distance to that…it can be quite a difficult job to do if you don’t have a workflow or are disparate from the sales team, or project facing side of the company.   

Again, the method above proves as a fantastic lifecycle which may support the geospatial analytics process to deliver the optimal results. Let’s look at how that might work.  

1.Plan  

Get a detailed description of what the end-user is trying to achieve and get a story, remember that the superior may not wholly understand what it is they are after themselves so get background information on how the results may be used – sometimes I’ve found that all they want is a CSV rather than a full behemoth analysis.   

2. Build  

For anything more than hitting “run” on a tool, create a model. This might sound crazy but at some stage, it will come back to bite you if you don’t. Spend the time to get it right.  

3. Style  

This may seem a little odd but this is where you look at the output and define the outputs, formats and fields. Almost like “styling” the analysis output, I have added extra data or set the model to export in certain formats at this stage.  

4. Test  

Run the analysis on a small sample, ensure it works and then run the full monster. When it has run, go through the logs with a fine-tooth comb and send it to a mate to check!  

5. Deploy  

Send your results or output to your superior.  

6. Operate  

This relates to the analysis model, once proven, you may be required to run more data, hence leading to stage 7 and 1 again or you may just need to store it…ready to pull out at some time in the future.  

7. Monitor  

Data changes as do methods of practice and models, better data may come along or a new tool. Monitor it and go back to (1) if necessary.  

There you go, my idea of how we can create a framework that will fit with the ISO requirements of larger companies, provide a method of practice to enable company strategies, whilst enabling small businesses to work smarter. Will it change your company overnight? Possibly not, but over time it will provide efficiency and better communication. Will it ever catch on? Again, probably not, though it may inspire others to employ workflows similar to this that will take them from being in the corner of the room to being the centre of most projects.   

Nick D