Data Management and OS Data Hub

Who needs access?

There are a number of questions that need to be considered with access to the OS Data Hub:

What is the need?

• Create Data Packages?

• View and Download Data Packages?

What role?

• Administrator, allows you to create, edit and delete data packages.

• User, allows you to view and download existing data packages.

Do they need it all? Only give access to those who actually need it

Is there any risk? By giving someone permissions are you enabling them to do something they shouldn't, or you ​wouldn’t want them to?

Picking your Product

When picking your product there are a number of factors to think about: ​

What Product?

• What is the requirement e.g. what is the data being used for?​

• Raster or vector?​

• Could I use an API?​

• What level of content do I require?

What coverage?

• Do you need national supply?​

• What’s the business need? ​

• What is the operational area?​

• Do I need a buffer?​

• Have I ordered for this area before?​

What format?

• What formats can I consume?​

• What’s the easiest to handle?

Update Options?

• How frequently does the business need updates?​

• Full supply can be quicker​

• Do I have the tools to process change only updates?​

• What if I miss an update?

Manage your data packages​ effectively

Name them sensibly:

e.g. <System> <Product> or <Contractor> <Product> or <Format> <Product> or any other useful combination.

Let OS do the hard work!​

• One size doesn’t have to fit all.​ It’s easy to create lots of data packages per product.​

• Not all systems require the same data holdings, so create different packages.​

• Not all systems consume the same data formats, so create different packages.

Delete them when no longer required.

Gives a clearer picture, reduces mail traffic.

Editing your Data Packages

Think very carefully about it – especially with addressing products.​

​What does this really mean?

Editing a data package enables you to change the area of coverage.​ This effectively is then a full resupply followed by future change only updates (if applicable).​ It is not a expanded change only update.

Am I better creating a new package?​

So the questions to ask here are 'Does the package number matter?'​ and 'Is there a cost associated to a full resupply?​'

and then…think very carefully about it again, as you can’t revert back.

Expanding a data package

Manage your API Projects​ effectively

Name them sensibly:

e.g. <System> <Environment> or <Process> <Environment> or <Contractor> <Product> or any other useful combination.

Let OS do the hard work!​

Different API endpoints can be contained in the same project e.g. Group API’s by target system together.​

Fair Usage Policy & Security​

Don’t use the same API key in every application.​

If you need to change one you don’t want to change them everywhere.​

Delete them when no longer required.

This makes it easier to manage and monitor usage across your estate.​

Os Data Hub API page

​Managing Contractors​

We understand that you have a requirement to provide contractor with OS data. There are several ways to achieve this, allowed under the contractor licence:

Direct Access ​

Create a user account for the contractor to download their own data and manage their own API keys.​

Positive: Reduce Administration. Can provide autonomy to contractors. ​

Negative: Full visibility of your Data Hub account. Potential Risk. ​

​Indirect Access​

Manage the data the contractor requires yourself and provide them with the downloaded data or the API keys. ​

Positive: Retain full control. Zero visibility of data hub account. No account management. Reduced Risk. Consistency with naming etc…​

Negative: Increased administration compared to Contractor Read-Write

Contractor licence page

---

This content has been developed from what was originally a Lightning Talk PowerPoint slide set. These slides are available to PSGA members to view and download from the PSGA members area of the OS website