cityscope / csl_hcmc Goto Github PK

Dear @Hai-Hoang-88 et al.,

After sharing ideas with Nhu, I have learned that most of the indicators are "under control", however, there are some questions related to the Displacement/Gentrification Index.

At the CS group we do not have yet our own Displacement/Gentrification Index, so we base our index into the work made by KAREN CHAPPLE (UC Berkeley).

Here is the methodology that KAREN CHAPPLE has used for her map of displacement:

https://escholarship.org/content/qt6xb465cq/qt6xb465cq.pdf

Since the document is dense, let me highlight some important chapters/Pages, that are worth to read. For this 1st phase, where we just want to visualice and measure the existing conditions this are the most important parts of the document:

- Page 38: Definition of Residential Displacement
- Page 41: Measurement of Residential Displacement
- Page 48: Indicators
- Page 63: Modeling and Gathering data for typologies
- Page 70: Modeling mobility (i think we can use @doorleyr 's methodology, however, it is good to understand how and why they measure mobility as part of the gentrification chalenges)
- Page 77: Modeling Neighborhoods Displacement (Very important)
- Page 88: Modeling Neighborhoods Changes

The rest of the document it is focussed on Assessment and policies. it will be important in a second phases.

Please, let me know your thoughts

Best regards,

Luis

In order for CS modules to understand the land use changes in each scenario, each of these land uses (eg. Educational, Commercial, Public Facility) must be defined using the Types System. At minimum, each 'Type' should have a defined mix of NAICS codes and LBCS codes. These should be in a json file. For an example, please see the Corktown types definitions.

In order to complete issue #1 there is still some atomic change that needs to be done concerning the Road network
Can you please change the file so we have the same consistency for each scenario as you can see here scenario 0, 1 and 3 are covering only district 4 whereas scenario 2 is covering all the area
Scenario 0

Scenario 1

Scenario 2

Scenario 3

@LAAP: after working with Front_End, I figured out we will have 3 interaction models (plate) presenting 3 urban structures (landuse). So to control the year (2021/2030) (which will control the population), we must use tablet to send that signal. In that case, what will happen if audience select the year 2021 and load physical model as scenario 2? Technically we will have 6 scenarios: {scenario 0: 2021+interaction plate 1, scenario 1: 2030+ interaction plate 1, missing: 2021 + interaction plate 2, scenario 2: 2030 + interaction plate 2, missing: 2021 + interaction plate 3, scenario 3: 2030 + interaction plate 3}.
By thinking about it, I think of 2 options:

1. Revise our story telling
2. a mechanism to allow audience fit our only 4 scenarios.

Please lets me know your thinking. Thank you in advance

Originally posted by @Hai-Hoang-88 in #1 (comment)

We will need to provide for each of the 4 scenario 3 differents shapefile: landuse, building and road

So far a first step has been made in this commit 1526e60 where th Scenario2/LandUSe_Scenario2 has been pushed.

So what we miss now is:

Scenario 0 : District 4 as it really is in 2021

Scenario 1: District 4 as it is but with the 2030 population (Increase of density)

Scenario2: Vision towards 2030. Accepted 2014

Scenario 3: Utopian Vision Autonomous resilient communities. Human scaled cities (SDMC + ARC + CS MIT ML) - 2021.

OSM road networks are currently used in analysis because the road network shapefiles are not available in node and link table format. If the road network shapefile can be converted to this format, then these can be used in the analysis. The node table should be a dataframe with the columns: node_id, longitude and latitude. The link table should be a dataframe with (at minimum) the columns from_node_id, to_node_id, length, max_speed.

Alternatively, please review the OpenStreepMap network data for HCMC and confirm if it is accurate enough for the models.

The POI data provided only cover District 4. However, some POIs outside of D4 will still be accessible from D4. Therefore, if we want to model, for example, 15 minute walking accessibility in D4, we need to also have information about POIs in the districts immediately surrounding D4.

Please, find the 1st draft of the text for the demo of the 3 scenarios. Please, let me know your thoughts:

https://docs.google.com/document/d/1iegZ8U6A3uy5qsTP9QaMTJLNPnZ92sJ9Ii7Numhpe30/edit?usp=sharing

This document is a working document so we can try to refine the text that we will pitch on the demos of the HCMC D4 CityScope table. These texts are “educated guesses” based on the comparison of the land use of the 3 scenarios.

The scenario analysis is currently based on a single density (sqm_per_person) value for each land use type. However, as discussed, it is more appropriate to use separate density values for employment and residential capacity as some land use types include both. Once the cs_types_2.0.csv file is updated with the 2 new density columns, the static_scenario_analysis.ipynb notebook should be updated to reflect this.

In order to complete issue #1 there is still some atomic change that needs to be done concerning the Landuse

Can you please change the file so we have the same consistency for each scenario as you can see here scenario 0 and 1 are covering district 4 + Surrounding but Scenario 2 and 3 are only providing the port area
Scenario 0

Scenario 1

Scenario 2

Scenario 3

Cityscope indicators are by default scaled to between 0 and 1 for the radar plot. Some of the indictors such as live-work score and diversity are automatically on a 0-1 scale. For others such as density and proximity, this is done by choosing a max and min value and using the formula:

ind_scaled = min(1, ((raw_value-min_value)/(max_value-min_value)))

The minimum and maximum values of each indicator should be chosen so as to span realistic ranges of these metrics and to deliver the scenario narrative effectively.

These can be edited in the static_scenario_analysis notebook by editing 'density_metrics', 'prox_metrics' etc.

The CSL types need to be fixed as described in #9 before this issue can be closed.

Provide the OD file Warp to Warp

In order to complete issue #1 there is still some atomic change that needs to be done concerning the building

Can you please change the file so we have the same consistency for each scenario as you can see here scenario 0 and 1 are covering district 4 + Surrounding but Scenario 2 and 3 are only providing the port area
Scenario 0

Scenario 1

Scenario 2

Scenario 3

As discussed with @Hai-Hoang-88 we will implement a first GAMA model for this project.

@doorleyr when do you think the issue will be closed #3 so that GAMA can wait for data sent by your module in order to instanciate it.

In the mean time, even if we don't have yet the aggregate value, @Hai-Hoang-88 can you have a look at this repo taht give the possibility to plug GAMA and CityScope https://github.com/CityScope/CS_GAMABrix

In order to convert the 4 scenarios in a compatible CityScope GEOGRID format we need to rasterize (or legotize) the 4 already existing scenarios in a grid format (ideally as proposed by @popabczhang in a 30x30m grid cell size if it's not to big for cityIO).

To do so we first need to close this issue
#1
and this one
#9

Once those 2 issues are finished @doorleyr will make an attempt to create the 4 corresponding CityScope Grid that will be load as 4 differents scenarios

The land use shapefiles reflect the areas pf parcels rather than the built area- therefore using them for the scenario analysis will overestimate the building capacities and therefore the residential and working populations.

However, the buildings files do not have a CSL_Land_Use_Type column, which is needed for the analysis. This can be added by overlaying the land-use shapefile with the building shapefile and assigning each building to the CSL_Land_Use_Type of the parcel with which it overlaps. This can be done is GIS software or by using the overlay() function in python geopandas.

The survey data contains information on home ward, work ward and many other demographic variables such as income, age etc.

The data can be grouped by home ward and aggregated in order to calculate the population in each ward, by demographic attributes. The format of the residential population file should be something like the following:

Similarly, the data can be grouped by work ward to get the working population. The working population file should be something like the following:

The data can also be grouped by both home and work ward and aggregated to produce an O-D matrix. The O-D matrix file should be something like the following:

These operations can be done in python pandas using the 'group_by' and 'aggregate' functions.

For the physical table demo in the summer, we will have 3 static scenarios (0,2 and 3). The hardware interactions need to trigger the scenarios to change. This requires updating the following on each view:

• the GEOGRID and GEOGRIDDATA layers depicting the state of the site
• the accessibility heatmaps
• the indicators
• the mobility visualisations

The heatmaps, indicators and mobility visualisations for the three scenarios are now calculated in a Jupyter notebook here. This notebook can be run for each scenario in turn by changing the 's' parameter to 0, 2 or 3.

This notebook saves the following results for display on the CityScope table into the scenarios/results/scenario_[s] folder:

• access_cs_js_format.geojson : the accessibility heatmap results in the correct format for CityScope_JS (usually read from the /access endpoint).
• indicators.json: the indicator results in the correct format for CityScope_JS (usually read from the /indicators endpoint)
• abm.json: the mobility simulation results in the correct format for CityScope_JS (usually read from the /ABM2 endpoint

It also saves some of the results in alternative formats:

• access_table.csv: access heatmaps in tabular format
• gdf_access.geojson: access heatmaps in standard geojson format
• abm.geojson: mobility viz in DeckGL geojson format (can be viewed using Kepler.gl)

I've also created kepler.gl visualisations as html files in the scenario/results folder to show a preview of how the results should look on the table. The access heatmap defaults to Employment but can be changed between different POIs using the Color property of the Access layer. The Scenario 0 Visualisation can also be viewed here.

@Hai-Hoang-88 can you and your team (i) look through the new Jupyter notebook and make sure everything makes sense to you (I can also do a technical Zoom call to explain anything which is not clear) and (ii) coordinate with the front-end and hardware teams to ensure that the analysis results can be triggered by the hardware interactions.