Meeting on 2023-02-15 0800 AEDT

[carlhiggs]

Attendees: Carl, Eugen, Geoff, Jonathan, Shirley
Apologies: Vuokko
Minutes: Carl

What we've been doing

• We have an FAQ site with draft directions for using our software to conduct analysis and reporting of urban indicators
• Submitted an ethics amendment to recruit our users to provide feedback in a participatory action research project, using this website (should be approved in a few days).
• merged in pull request #180
• made new pull request addressing a number of other issues #194
• Eugen has been trialling running the process
• from Vuokko:

Plans` for testing OSM data enrichment /validation in a crowdsourced manner (=organizing a mapathon for this purpose) are in the air, this could potentially happen in March, and most probably in Turku, Finland as they have an active group of people organizing mapathons (both HOTOSM and local mapping). This could feed into a practical example of “how-to” a) validate existing data b) input/update missing/erroneous/outdated data c) overall how to engage volunteers and stakeholders in the work.

What we discussed

• process is tricky to run (many assumptions on technical aspects for users; need to make simpler -- simpler directions and simpler process)
  • Geoff advises: numbered step-by-steps reduced to a bare minimum; link to external technical concept guidance so we aren't responsible for maintaining this
• simpler retrieval --- don't advise people to use Git; they can retrieve using zip file once we create a package
• we could have additional advice where we add extra bits that may be of niche interest (eg WSL2, using Git, etc)
• folder restructure would be appropriate
• demonstration data would be useful
  • link to externally hosted zip file for download
  • data structure proposed below
• define our scope of work in 2-phases
  1. We have what we have
     • immediate priorities are simpler, clearer documentation and video
  2. Identify what we should have
     • come up with agreed process for implementing API breaking changes and minor revisions
     • plan for future releases

What we need to do

• Team discussions are being deprecated apparently! Need to transfer this to GitHub Discussions, whatever that means; I'll let you know when its done.
• Schedule as a spatial software feedback session a fortnight from when our ethics amendment is approved
• Share markdown for the software analysis and reporting directions on Google Docs for collaborative contributions
• Simplify documentation
• Mock up videos
• Simplify/clean up folders
• Provide demonstration data / worked example
• Simplify launch (maybe directly into process folder, or not even present users with bash interface at all)

Proposed data structure

Some data sources are shared by multiple regions, so it doesn't make sense to cluster data solely by region; it should be by purpose. For example, while population or boundary data files could be just for a single region, they could also be for multiple (e.g. datasets with global coverage). The paths are configured in configuration files, but for storage purposes we should have conceptual sub-folders as the basic structure, I propose. We basically do this ad hoc now; I am proposing that we formalise it.

data
    - population
        -  [_a sub-folder with a descriptive name for a subset of tiles from GHSL or a national grid, e.g. "GHS_STAT_UCDB2015MT_GLOBE_R2019A" or "GHS_POP_P2030_GLOBE_R2022A_54009_100_V1_0"_]
            - [_one or more .tif files and associated metadata, e.g. "GHS_POP_P2030_GLOBE_R2022A_54009_100_V1_0_R14_C12.tif"_]
    - boundaries
        - [_a specific file with the region boundary_]
        - [_optional subfolder for grouping boundary files, e.g. "Belgium"]
        - [_a specific file with the region boundary, e.g. "adminvector_3812.gpkg"_]
    - OpenStreetMap
        - [_a .pbf or .orm excerpt of OpenStreetMap; should be dated with a suffix to indicate publication date e.g. "las_palmas-latest.osm_20230210.pbf" or "oceania_yyyymmdd.pbf" where yyyy is the year, mm is the 2-digit numerical month, and dd is the 2-digit numerical day date_]
    - urban_regions [_optionally, a study region can be defined by or restricted to a defined urban region from the Global Human Settlements Urban Centres Database_]
        - GHS_STAT_UCDB2015MT_GLOBE_R2019A_V1_2.gpkg
    - GTFS
        - [_some region specific GTFS parent folder, e.g. "Belgium"_]
            - [_one or more sub-folders containing unzipped files from GTFS feeds, e.g. de_lijn-gtfs_20230117, where the suffix indicates date of publication (feed metadata is also recorded in region config file)_]