In our last blog post 'Bringing GIS to the Masses' we looked at how the ArcGIS Maps for SharePoint web part can bring your corporate GIS data to users who tend to work in a SharePoint environment,
who may not even be aware of the spatial data that is available within their organization. Also, how it can add context to the information and documents that they deal with on a day-to-day basis.
Tools such as Safe FME are widely used to pull data from internal and external repositories, transform it (as, or if required) and then written to enterprise geodatabases, for consumption in internal desktop GIS and web GIS systems. This can lead to a situation that the 'best set' of spatial data and its related attributes is only held within a GIS environment, and not pushed out to other applications or disciplines – for example, an Information Management team who may work quite separately from a Subsurface Data Management team.
There are always going to be discussions (disagreements?) about who owns, or what is the 'master data' within an organization, but what about the data that may come from, say, a regulatory agency? Could this be used to add or improve the quality of the information stored in SharePoint Lists or Document Libraries as a quick win? That information may already be used within a Data Management or GIS team for their systems, but are they aligned? For example, is an asset or licence called the same thing in both systems, and is it then a manual process that someone has to remember to do on a regular basis to update it?
Wouldn't it be nice if there was a way that both these processes could be automated and happen at the same time to update both your GIS and SharePoint systems, to free someone up to do more important work?
"Just throw some more FME transformers at it..."
Let’s consider the following scenario using the UK's Oil and Gas Authority's publicly available licence information – we, as a Data/Information Manager, have been tasked with ensuring that for the licences our company has an interest in, the information about them are up to date and correct, and management want a procedure in place to make sure that this happens. Not just in the GIS environment, but also in the corporate document management system (SharePoint)- which the entire company use on a day to day basis.
Our FME workbench for the first part of this exercise is fairly simplistic:
The second part is more interesting: take the output from the filter in step 3 and then use this to update a SharePoint list (in the below example LicenceTest).
To update a SharePoint list using FME we need to retrieve the internal sharepoint_item_id first (using the SharePoint Reader), along with the attribute to match on, in this case Licence and pass these into the FeatureMerger. The sharepoint_item_id attribute is then needed by the SharePoint Writer, when it is set to update a list. (If a new list is being created then this isn't required).
Going back to the previous blog about how geoenabled lists can be created and consumed within the ArcGIS Maps for SharePoint – by using the GeometryExtractor transformer and setting the output geometry to ESRI JSON. This is written to an attribute called Shape within your SharePoint list – and automagically this list is now geoenabled. This also negates the need to manually run the Locate workflow within SharePoint, as the spatial data is there and in the right format.
If we then go to our ArcGIS Maps for SharePoint web part and look at the options under Add data from SharePoint, we can see our test list in the tree view on the left and one of the features in the map window with its associated attributes. (Note: I haven't added in any other map layers yet in the screenshot below).
Now, you may look at this and think "how is this any different from just pulling a web map service direct?". The value in getting it into SharePoint is that this data can then be used and combined into a view with other information that is only stored within SharePoint lists or document libraries – for example licence obligations or work commitments. Or, in case of a licence award: automatically populate the key attributes into the system (and then send an alert to the key users that new data has been added and they need to do something!).
Adopting this approach would allow you to know that the key attributes and feature geometries are up-to-date and consistent across (or at least a good part) of your technical landscape.
How do you reach the great geo-unconverted masses? Well, we would like to advocate a “take the GIS to the people” approach (as opposed to bring the people to the GIS) – by integrating geospatial content with SharePoint.
One year in business already, and our thoughts on working with Azure and on-premise IT. What have we learnt?