The end goal of Cadasta is to simplify workflows and speed up land documentation processes. Printing PDF reports are one major way that partners can finalize the land documentation process. The needs can be broken up into three main stages:
(1) printing default reports from the platform,
(2) printing custom-formatted reports (table views, different layouts, field orders, multiple parties per location, multiple locations per party) and
(3) printing summary and filtered data views.
The map view, fields, and formatting will differ partner by partner.
Context/Use cases
Stage One (Default Reports)
(1) Paper versions of the data collected:
A default layout that includes options for headers, footers, map views, and fields (on or off)
(2) Report for community data validation (can be supported on the platform or through QGIS at the moment)
A map containing community points of interests (their geometries) is included in the report
All geometries within the project will be included in the map
A label for each the geometries can be included (for identifying the different locations)
Partner will be able to include texts and images (typically logos) in the report
Stage Two (Custom-Formatting Report)
(1) Report for formal recognition of the land.
Typically used for applying to local authorities for some sort of formal recognition of the land property
One location geometry will be included in the report, using a specific basemap (i.e. OSM, imagery, etc)
For this reason, formatting and styling needs could be very important
Partner should be able to precisely define where to include the different fields of the report (texts, images, field attributes, maps, etc)
A good example of this report could be this (a RoR property document in India containing a geometry and field attributes associated with the geometry).
Bulk printing of reports for multiple locations would be a plus
Stage Three (Summary and Filtered views)
(1) Report for individual data validation
The information contained in this report will be very similar to (1), but the flexibility in terms of styling and formatting is much higher.
This report is typically used by partners to go back to the field and validate the accuracy of the collected data (typically the validation of geometries)
Bulk printing of reports for multiple locations would be a plus
(2) Report for harmonization of geometry boundaries
Partner will define an area of work where several geometries are contained
A map containing these geometries will be included in the map
Partner will select the basemap to use
A label for each the geometries can be included (for identifying the different locations)
Partner will be able to include texts and images (typically logos) in the report
Requirements and User Stories
Stage One (Default Reports)
Header :: Include organization/funder logos/images and/or text of org names
Ability to print out a map view of one geometry
Ability to print in local languages (Roman and scripts)
Ability to specify which fields are included in the report (location, party and relationship fields and values)
Footer :: Include page numbers and/or org name
[ ] US1.1. As a project manager, I want to click "Print" on a specific location
[ ] US1.2. As a project manager, I want to select the basemap to use in the map (satellite imagery, osm)
[ ] US1.3. As a project manager, I want to select the font to be used in the report (size, type)
[ ] US1.4. As a project manager, I want to include images (typically logos) to be placed in the report
[ ] US1.12. As a project manager, I want to select to paper size to use (ideally A4, Letter, A3)
[ ] US1.6. As a project manager, I want to select the field attributes from the location to be printed in the report (checkboxes next to each field)
[ ] US1.7. As a project manager, I want to select the field attributes from a relationship associated with the location (when there is only one relationship associated to that location)
[ ] US1.9. As a project manager, I want to select the field attributes from a party associated with the location (when there is only one party associated with that location)
CURRENT WORKAROUNDS FOR THESE LATER STAGES ARE QGIS PRINT COMPOSER
Stage Two (Custom-Formatting Report)
All of the above
Ability to change the order of the fields
Ability to change the format of the fields
Include previews of images that are attached to resources to the location, party and/or relationship entities
Ability to choose paper size (A4, A5, letter, etc)
[ ] US2.1. As a project manager, I want to include texts to be placed in the report
[ ] US2.2. As a project manager, I want to set the specific place where the different fields (attributes, external images, resource images, texts, the map) within the document
[ ] US2.3. As a project manager, I want to select the field attributes from more than one relationships that are associated with the location. The attribute (liketenure_type) from all the associated relationships will be displayed
[ ] US2.4. As a project manager, I want to select the field attributes from more than one parties that are associated with the location. The attribute (likeparty_name) from all the associated parties will be displayed
[ ] US2.5. As a project manager, I want the ability to choose between default and pre-specified template (or have it default to one).
Stage Three (Summary and Filtered views)
These print capabilities adds complexity and sorting to the reports. Users have the ability to print out a map view of (1) one geometry, (2) multiple geometries associated with one party or (3) geometries contained in a defined area (selected with a drawing tool on the map).
[ ] US3.1. As a project manager, I can "select all" or some locations to be printed individually (table view with checkboxes for which individual reports to print)
[ ] US3.2. As a project manager, I want the ability to choose between default and pre-specified template (or have it default to one).
[ ] US3.2. As a project manager, I want to print summary views (totals) of specific fields
Misc
Not sure where to be one-off printing or bulk printing
For some custom reports, partners may need to edit the labels and values of the questions/data collected. This means that we will need to have some logic for being able to use different words or abbreviations for certain values, etc.
Notes
It is challenging to build a GUI for custom reports. If we decide to do the printing in-app (which I recommend as I think reports are a key end product for many users), as a first step, we could use allow the ability to write HTML and python. Then later we can create a front end for that work. Alternatively, we could integrate with a third party tool for the complex front end interactions-- something like jsreports.net or webmerge.me.
For many partners, exact formatting (to apply for recognition of property rights to the local authorities) will be very important. Some partners will need exact formatting or they will not be able to use use the platform or have to add another step to the workflow, which could be quite cumbersome.
Fonts are also a key point, as reports may need to be generated with non-latin scripts.
As a nice to have, bulk printing of multiple reports would be useful for partners, so they design first the template to use and then print that report for all the selected locations.
The custom reports for more than one geometry could be better managed with QGIS plugin, but it's been included here for open discussion.
Problem Statement
The end goal of Cadasta is to simplify workflows and speed up land documentation processes. Printing PDF reports are one major way that partners can finalize the land documentation process. The needs can be broken up into three main stages:
(1) printing default reports from the platform, (2) printing custom-formatted reports (table views, different layouts, field orders, multiple parties per location, multiple locations per party) and (3) printing summary and filtered data views.
The map view, fields, and formatting will differ partner by partner.
Context/Use cases
Stage One (Default Reports) (1) Paper versions of the data collected:
(2) Report for community data validation (can be supported on the platform or through QGIS at the moment)
Stage Two (Custom-Formatting Report) (1) Report for formal recognition of the land.
Stage Three (Summary and Filtered views) (1) Report for individual data validation
(2) Report for harmonization of geometry boundaries
Requirements and User Stories
Stage One (Default Reports)
Footer :: Include page numbers and/or org name
CURRENT WORKAROUNDS FOR THESE LATER STAGES ARE QGIS PRINT COMPOSER
Stage Two (Custom-Formatting Report)
Ability to choose paper size (A4, A5, letter, etc)
tenure_type
) from all the associated relationships will be displayedparty_name
) from all the associated parties will be displayedStage Three (Summary and Filtered views) These print capabilities adds complexity and sorting to the reports. Users have the ability to print out a map view of (1) one geometry, (2) multiple geometries associated with one party or (3) geometries contained in a defined area (selected with a drawing tool on the map).
Misc
Notes
It is challenging to build a GUI for custom reports. If we decide to do the printing in-app (which I recommend as I think reports are a key end product for many users), as a first step, we could use allow the ability to write HTML and python. Then later we can create a front end for that work. Alternatively, we could integrate with a third party tool for the complex front end interactions-- something like jsreports.net or webmerge.me.
For many partners, exact formatting (to apply for recognition of property rights to the local authorities) will be very important. Some partners will need exact formatting or they will not be able to use use the platform or have to add another step to the workflow, which could be quite cumbersome.
Fonts are also a key point, as reports may need to be generated with non-latin scripts.
As a nice to have, bulk printing of multiple reports would be useful for partners, so they design first the template to use and then print that report for all the selected locations.
The custom reports for more than one geometry could be better managed with QGIS plugin, but it's been included here for open discussion.