Meeting on 2024-03-06 at 09:00 AEST

[carlhiggs]

Attendees: @dapugacheva , @gboeing , @duelran , @rychennn , @ryn-trnr, @carlhiggs
Chair: Carl (Melbourne)
@global-healthy-liveable-cities/software-spatial

Spatial/software catch ups moving forwards

It was proposed and subsequently organised to hold meetings with a rotating chair for fairer sub-region access. Based on our spatial team membership we have organised a monthly rotation of 9am on approx first Wed/Tues of month in Melbourne, Los Angeles, Helsinki, Melbourne, etc. This may mean that one region 'loses out' timezone-wise once every 3 month cycle, but for such meetings maybe '2 out of 3 isn't bad' --- and we can share notes/catch up online.

User Experience audit

As per #375 and #379, @rychennn and @dapugacheva presented on their recent user experience audit, respectively focusing on use of the web app and Jupyter Lab. Recommendations have been made for improved documentation of processes including checklists, user interface enhancements, additional functionality for more flexible usage, and improvement of cross-platform usage experience.

Various suggestions were made for adding to a Frequently Asked Questions section; we have one at the following link on the software documentation website, but perhaps it could be featured and linked to more prominently from the GitHub site:
https://healthysustainablecities.github.io/software/#Frequently-Asked-Questions

A suggestion was made for geometry checks on user provided data, specifically for the study region boundary. It was discussed whether provision of an incorrect boundary geometry type (eg LineString) should be handled and/or alerted. We agreed that alerting users, but not handling incorrect geometries was the correct approach (ie. polygons are required, and an attempt to analyse a region lacking a polygon boundary or equivalent urban boundary query should be halted, with advice that this is required, in order to avoid unintentionally poor boundary choice). A specific example was given for a city boundary based on a MultiLineString comprising a 'north' line and a 'south' line, that would not provide an adequate study region boundary for analysis, and hence shouldn't be supported.

• implement a check that data format is right for study region boundaries

@ryn-trnr, @rychennn and @dapugacheva suggested providing some information for users on expected run time, which we discussed could perhaps be done by collating information on run times from different user systems.

• collate user processing run time by city/city size and system specifications (@ryn-trnr shared this already; thanks Ryan!).

We could gather data for different system specifications, but this is sufficient for now I think. As per e-mail to Ryan, Ryoyu and Daria, the main thing is overall analysis time --- not sub-steps which won't be of interest to most users. We know that the network retrieval, setup and analysis will take longest and the city size and user system will be determining factors for how long these steps take. Other steps are trivial; these are just components in the overall analysis, which is the main thing. We could consider adding back in more user feedback to show incremental processing, rather than print this to log file perhaps. But the time to do this could also be spent re-factoring code to make things run quicker potentially!

New environmental indicators and validation study

Drawing on the @global-healthy-liveable-cities/cycling-indicators-working-group (aka Active Environments Network), @ryn-trnr has arranged validation of new public green space indicators for multiple cities. Ryan will use similar approach for a heat vulnerability index. We are also working at implementing SNAMUTS transport indicators (http://www.snamuts.com/), and I will loop @shiqin-liu into this work given her transport and GTFS expertise.

Policy and Spatial report templates

@eugenrb has provided some updated designs for these following iterations w/ @mdlowe and @Dsalvo, and I will look to start implementing these later this week/next.

Conferences

@gboeing suggested coordinating on conference submissions for the year; we'll do this across coming month. @duelran emphasised need to build connections with resilience community; I mentioned @mdlowe will be keen to do this given fellowship focus on resilience indicators (specifically what @ryn-trnr is working on). @gboeing suggested geography conferences often have good intersection w/ resilience.

If there is anything I missed in the above, or you'd like to anything, please feel free to add!