If your organisation is receiving data supplies from a vendor or perhaps data that is being shared by another organisation, it is worth considering what changes you could be making to ensure that the data is as useful as it can be. Data that is supplied often comes with a lot of assumptions. Because it needs to be versatile for many organisations it often contains intricacies that are less than useful or even unhelpful. It may have come from a legacy system that has a flawed design or is formatted for a commonly used target legacy system.

There is a cost that your organisation is exposed to for handling this data. Firstly, it may place limitations on how you can use the data or what you can use it for. Secondly, any workarounds that you design to use the data effectively have to be re-performed every time you want to use the data, which is inefficient.

You can choose to remodel and simplify the data, designing a geospatial repository that meets your needs. It can also means designing a transformation that can be performed repeatedly. An example might be to take Road Centreline data, and split into 3 sets, Navigable Road Centrelines, Tracks and a Separate State Highway layer. Doing this has a number of advantages. It ultimately saves time and will allow you to easily do what was difficult or unworkable before. Every time you go to use it, the data will be easier to use so you are more likely to make use of it.

By pre-processing in this way, it has the advantage of removing bottlenecks. If you have already transformed your data, you have reduced much of the work needed for translating your data through to your production systems and had the opportunity to identify errors or inconsistencies with the data at the time of receipt, not necessarily when the pressure is on to produce outputs using it. Ensure that you have a good relationship with your provider by actively providing feedback in the most useful way possible for them. Only code in data fixes as a last resort, it is much better to feed data problems back to your supplier for them to fix. Hard coding data fixes can come unstuck if the Supplier corrects the data and you are still applying fixes to it. Also having a good relationship and a data supply agreement means that you should expect a consistent data supply. If this is not happening then negotiate one with your supplier.

There are exceptions to most rules, and one area where you may choose not to update your model is if you are detecting changed data and only applying the changes. In such cases, consideration needs to be given to ensuring that a data model change does not make this a more difficult task.

We actively promote excellence in the geospatial industry and support all initiatives that make geospatial data and analysis accessible and easily interpreted.

The resources you see below have been created as a way to share our expertise with others in the industry.

Please feel free to utilise this information as you see fit. We welcome your feedback and suggestions for future articles.

Implementing a Data Service Checklist - New Data

A robust checklist for modelling and implementing new dataset: documenting and implementing the services to ensure consistently high quality and reduce uncertainty, downtime and rework.

Link to Google document

Implementing a Data Service Checklist - Existing Data

A robust checklist for documenting and implementing new or changed services of an existing dataset to ensure consistently high quality and reduce uncertainty, downtime and rework. Includes documenting the existing dataset if required.

Link to Google document

Geographic Data Service Catalog Template

A Service Catalog template for documenting the geographic data services needed in an ITIL environment.

Link to Google document