Tell me about a location
So far our prototypes have focused on getting a location or showing a user what data the platform held.
Getting a location is usually the first step in a process. A service needs to determine a location to then be able to do that something else.
Often policies and rules apply to specific geographic regions. Geographic areas can be large, like nations (e.g. in Wales, Land Transaction Tax is paid on property purchases) or small, like wards (e.g. to vote you must go to this polling station). First, you need a location; then you can figure out what geographic policies apply.
With this prototype, we wanted to show how the platform makes building these services easier.
During the proof of concept phase, the team built the “is it in Wales” service. The team used synthetic data to build the proof-of-concept service. We wanted to prove we could rebuild a similar service using real data we’d already managed to collect for the platform.
We wanted to build something that would determine the users’ location, work out what we know about this location and then cross reference the location with any other data to see what applies to the location.
A location in Wales
A location not in Wales
What we learnt
The data is inconsistent
Inconsistent data makes these services harder to build. There is no way to know which dataset a record belongs to if you look at it in isolation. This makes it harder to say the location is in the name National Park. The service builder needs to either check the data record looks like a record from the National Park dataset, or to know they are requesting data only from the National Park dataset.
Service builders also need to know what attributes are used in National park records and which attributes are used in Electoral Wards. For example, they can’t just assume there will be a name attribute used. Electoral Ward records include a name attribute. However, National Park records contain a np_name attribute.
We need to decide how much preprocessing the platform should do when it collects the data. Should the platform try to add consistency to the data or should the onus fall on to the creators of the data? Similarly, what tools are needed for service builders to be able to use the data effectively?
Council tax is more complicated that the available data suggests
We assumed the council tax dataset we were using would allow us to confidently say “this is how much you would pay for a band in a region”. Only by showing this in the prototype were we made aware of the nuances in the data that would mean it couldn’t be used as we’d intended.
The data needed to show the amounts that make up the exact council tax amount are not all readily available. If they were, service builders could use the platform to calculate an accurate council tax amount for any property.
Linking datasets adds value
Another area where the platform can add value is by providing links between the disparate datasets. This would allow service builders to use data in ways that is currently hard to do. For example, the platform can determine which local authority and community a location is in. Then it can use these to return the council or community tax amounts for those areas.
Modelling relationships between data can be something the platform solves once so each service built on top of the data doesn’t have to repeat the same steps.
It doesn’t have to be a map
We don’t always need a map to build a geographic-based service.
Issues to resolve
The prototype doesn’t know how to handle situations where a location is near a boundary. In these cases, small inaccuracies in the data could lead to false results. So maybe the output needs to be less YES/NO and more degree of confidence.
Weeknotes
Each week we share a short update on what we’re learning, along with links to things we think are interesting or relevant.
Blog
- The technical architecture
- Policy challenges
- Every day's a school day – lessons learned from the land and property platform
- Why are inaccuracies creeping into addresses on the Land Transaction Tax return?
- How a map can paint a bigger picture
- Summarising the Proof of Concept
- What we learned about users
- How we used weeknotes
- What we've learned about working in the open
- What do we mean by a data platform?
- Welcome
Prototype
We built a number of prototypes to test our assumptions, platform capability and ideas.