# 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. \ \ or \ \ or \ \ 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. \ \ or \ \ or \ \ 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](https://auth.ordnancesurvey.co.uk/my.policy)
