GeoCMS: Bringing Together Content Management and Digital Mapping for Spatial Workers

Intro

We all know that data has become an integral part of businesses around the world. At its core, data is information used to make informed decisions that can produce the best outcomes. We don't usually think about it, but documents are also a form of data. Searching for and within documents is consuming more and more time of professionals in various industries. Volume is increasing with 36% of a typical knowledge worker's day spent searching for information, and only 56% of the time finding what they need. Important capabilities that will increase efficiency in this area of technology is more intelligence/automation, improved usability, and smarter search.

These capabilities are being realized in some of the largest content management systems like Box, OneDrive, and Dropbox, but there's something missing here for spatial workers. The activities of organizations like utilities and local governments almost always occur in a space and place and location is inherent in the data that is generated during these activities. Current CMS technology is largely lacking location functionality and is less effective for spatially focused organizations. Some applications have enabled the attachment of documents to geographic data for quickly finding related documents, but I think a lot more can be done. We need to create a content management system with geographic capabilities: A Geographic Content Management System (GeoCMS).

User interface and capabilities

What capabilities should a GeoCMS include? It should have all the standard features of leading content management systems like cloud-based access, mobile ready applications, version management, and granular security. Let's focus on the geographic component here where some useful capabilities emerge when we integrate location technology with CMS functionality.

A civil engineer might be tasked with building a new road that connects two existing roads. For a project like this, a lot of due diligence takes place before any digging is started. Due diligence is, among other things, effort spent to understand a construction site. There could be sewer pipes, electrical conduit, or abandoned infrastructure running through the site, potential right-of-way and ownership conflicts that exist based on past legal agreements or building and zoning restrictions that need to be collected and reviewed.

To find all this information traditional methods would be used like digging through folders or using a document management system. Rather than focusing on more important activities, engineers and many others would have to spend a lot of time on this due diligence. Let's imagine a GeoCMS was implemented in the years before this project and replaced the old way of doing things.

Above is a mock-up of a web page I made where someone would search for documents using a map. A user logs in and rather than clicking through hundreds of (hopefully) organized folders of information, they could navigate to a location of interest in the left panel. Then, a filter could be set based on document tags like 'As-builts', 'Legal', and 'Building Code'. After the available documents are filtered a user could select the documents in their area of interest (the red dotted line in the left panel). This would display all available documents in the middle. You might notice a folder button at the top. I was thinking entire folders can be mapped so you could more easily find information that doesn't have an explicit location to it. From the middle panel promising files could be previewed, shared or updated. Files previews would appear in the right panel (there's also a full screen mode for easier viewing).

Another mock-up I wanted to show you is from the 'View' tab above. Imagine having the capabilities of file explorer, something most of us use daily, in the same application. You might not always need the map when looking for files, sometimes the folder is our friend! You can see the three-panel layout is at play again with our familiar drop-down lists in the left panel, folders and files in the middle and previews on the right. Something unique here is a detail in the middle panel called 'Mapped' that displays a green icon if a file has a location available. This could help users know if something needs a location added.

If you're wondering where I came up with the interface for the 'Find' mockup page, inspiration came from several places. I always say there's a time to innovate and a time to imitate. There's no point in reinventing the wheel if you see things that work well in the web applications you use everyday! The upper part of the mockup came from Cartegraph OMS that organizes focused functionality using tabs. The three-panel layout is from Wrike, a project management software, which works naturally with a map to the left, files in the middle, and previews on the right. Lastly, the left panel is based on the minimalist web app layouts of Esri's ArcGIS Web App Builder that can be customized with specific functionality called widgets. In our case we had a 'Filter' widget and a 'Select' widget.

Value props

An obvious benefit that comes to mind is having everything in one place. You could have all your data layers like storm water assets, street lights, fiber optic and more on the map right alongside any relevant documents. Not only are you finding information faster using a map rather than a folder, you save time by avoiding the cognitive load of switching from one application to another. The old way of doing things would be going from ArcGIS Online, to Windows File Explorer, to viewing a file in Word or Adobe PDF viewer.

Collaboration will also be better between and within spatially-focused organizations. Keeping with the local government model, everyone at a city would have better access to relevant documents across departments like Finance, Engineering, Police, and Public Works. Everything a government does is done somewhere and using location to find documents is a logical way to access and organize information. Digging through folders of different departments or emailing someone to find what you need can slow down the task you're trying to accomplish.

Agencies frequently share data between themselves as well. Imagine being able to share your GIS data along with any documents relevant to an area of interest with a click of button. Instead of clipping shapefiles and zipping up spreadsheets and PDFs you could simply share a link to everything at once. The person receiving this link could open the link and the map with related documents would appear.

There's a lot of potential for new capabilites as well. How great would it be to do a keyword search focused on a particular area like a street or parcel? You could navigate to a location on the map, highlight an area of interest, and type in any key words related to your search. Not only are you limiting your search results based on key words, but you improve your odds of finding what you need by significantly narrowing the scope based on location.

If multiple agencies used the same platform a comprehensive search could be done all at once. A request for data could be submitted for a particular location and the request would go to the city, electric utility, federal government, and more. Here again we see time being saved by doing a single request once on one application, avoiding the cognitive load of having to go to multiple websites or emailing a variety of organizations.

Challenges and future development

With any new technology or idea there's challenges that come with it (I love this about new things). Many of us feel at capacity with everything being asked of us and new resonsibilities come up every day. A GeoCMS would require people to change their behavior and take effort to map documents manually. It doesn't take too long to map a single document, but things add up. I think there's some ways to reduce this effort. There are services that can analyze text, like AWS Comprehend, that can identify location information. This could be an address, street, city or even lat/long coordinates. Pair that with an OCR software to get text out of documents and you could greatly reduce manual mapping time. Doing this accurately and in a user friendly way would be difficult.

Avoiding duplicated or incorrect versions of a document being mapped could be an issue. We don't want a search to yield several documents that are slightly different as this would increase to time to find what you need. Leveraging version control that many CMS applications already have would be key. Maybe when a new document is mapped it could detect if a similar or identical one is already there?

Initial implementation is also a challenge. Organizations have hundreds of thousands, if not millions, of documents all over the place. Getting even some of these mapped would be a Herculean effort! Recall our filter capability in the 'Find' mockup page. Reducing our search criteria with tags can greatly improve our results. Would it be reasonable to manually tag everything? I think machine learning could be used to identify types of documents and automatically tag them. I'm unsure of how precise this could be, but I think a hybrid approach could be used that would require a user to confirm tagging for documents that the computer is unsure about (a similar thing could be applied to the automated mapping of documents).

We could spend a lot more time on this. I've laid out the foundation of an idea to get you started and offer some insight on a very useful tool. Sometimes we just need some inspiration to take the first step and I think there's a lot more to be explored in the GeoCMS space! I plan on defining a back-end architecture in the near-future for an overview of how the Geo Cloud could be leveraged to keep you focused on the fun stuff. I encourage you to run with this and see what you can come up with. If you do, send me an email and I'd be happy to share it with everyone! Happy building!