interactive grid for entire design area

[andredaa]

Following our conversation in the email and based on Ronans suggestions I produced a geojson containing georeferenced gridcells within the designable area. https://github.com/andredaa/city_io_to_geojson/blob/site-shaped/resulting_jsons/geojson_global_projection.json

I pushed it to the grasbrook_test endpoint, so you can test it. https://cityio.media.mit.edu/api/table/grasbrook_test/meta_grid

It contains only the properties "properties":{"cell_id": 58, "interactive":true,"interactive_id":1}" Properties like land_use that can be altered are not specified, as this is supposed to be a static json, if the spatial setup of the grid doesnt change.

Let me know what you think about using this as a base for the front-end grid visualization and the georeferencing of the cells for module purposes.

[andredaa]

[yasushisakai]

I may not be getting the whole picture here but, what is cell_id? dosen't the array index suffice as a unique identifier?

[luftj]

the cells present in the geojson as features are a subset of the "rectangular" grid array. Some operations work on the rectangular grid and use their index to determine their spatial relationship (ie index+1 is one cell to the right). So the cell_id is a mapping back to the complete grid array.

[luftj]

The idea is to use a geojson as small as possible, since geojson is about a factor of 50 larger than just a json of the grid array. Traversing and changing data is significantly faster on an array than on the geojson. That's why the data is manipulated in the grid only and the geojson gets calculated only once (or only when the header/spatial info changes). The geojson is just used by modules (and possible the front-end) that need geo-referenced cells

[doorleyr]

@andredaa thanks, this is on the right track but actually to be compatitble with the modules, the geojson should contain all the cells of the rectangular grid. Some of them should have {'interactive': False, 'interactive_id': None}. In the geojson above, you only include the interactive ones so every cell has 'interactive': True. As @yasushisakai mentioned, the cell_id will then be unnecessary as it will just be the index of the feature list. Regarding the size of the geojson, it only gets sent once and never gets updated so performance and size shouldn't matter that much.

[luftj]

@andredaa thanks, this is on the right track but actually to be compatitble with the modules, the geojson should contain all the cells of the rectangular grid. Some of them should have {'interactive': False, 'interactive_id': None}. In the geojson above, you only include the interactive ones so every cell has 'interactive': True. As @yasushisakai mentioned, the cell_id will then be unnecessary as it will just be the index of the feature list. Regarding the size of the geojson, it only gets sent once and never gets updated so performance and size shouldn't matter that much.

We realised this looking at your code. But you don't use the non-interactive features anyway, so why store and transmit them?

for fi, f in enumerate(meta_grid['features']):
    if f['properties']['interactive']:
        int_to_meta_grid[int(f['properties']['interactive_id'])]=fi 

As a matter of fact I get a decent looking point feature geojson from your module with the accessibility values in them after only changing 2 lines of code (see https://github.com/grasbrook-cityscope/CS_Accessibility/tree/grasbrook). See https://cityio.media.mit.edu/api/table/grasbrook_test/access

[doorleyr]

Firstly, you may be getting a geojson output but it's not correct because the module adds 'dummy' links between adjacent interactive cells. If the cells are not in a rectangle, the links will be added in the wrong places.

Secondly, this is not the only module relevant to the discussion. The ABM module reads the land use values of every cell (including the static ones) at initialisation and updates only the interactive ones during simulation.

Thirdly, we shouldn't have a copy of this module in another repo- it makes it difficult to keep track of updates and share improvements made by both our teams. I just made a commit in our repo to make the module work for your land-use mappings as well as ours so that we can avoid this.

[RELNO]

I may not be getting the whole picture here but, what is cell_id? dosen't the array index suffice as a unique identifier?

@yasushisakai @luftj Side question: can these arrays be trusted to maintain order over time?

[yasushisakai]

@RELNO JSON specifies that order is preserved in arrays. If some module messes it up it will be his fault. hash will change.

@doorleyr looks to me @luftj was referring to a forked repo so he can PR to you...?

[yasushisakai]

just a thought, if it's an irregular gird we might think of a bidirectional 2d linked list-ish object ??

{
  "48":{"data":"foo", "top":70, "down": 22, "left": 49, "right": null},
  "49":{"data":"bar", "top":71, "down": 23, "left": 45, "right": "48"},
}

it's O(1) if you know what you want, you can walk though, fine with concave shapes, not so much queries, very bad memory usage.

[RELNO]

just a thought, if it's an irregular gird we might think of a bidirectional 2d linked list-ish object ??

{
  "48":{"data":"foo", "top":70, "down": 22, "left": 49, "right": null},
  "49":{"data":"bar", "top":71, "down": 23, "left": 45, "right": "48"},
}

it's O(1) if you know what you want, you can walk though, fine with concave shapes, not so much queries, very bad memory usage.

I don't think we're in the ballpark on recreating the whole grid concept from scratch, but for fun: this suggestion could be implemented not in the grid data itself, but rather in the mapping json. so that gridcell.id(1...n) will refer to map_gridcell[1...n]{"data":"bar", "top":71, "down": 23, "left": 45, "right": "48"}

[andredaa]

So, based on the skype conversation we had last week I produced the following: 1) a rectangular meta-grid, which contains interactive and non-interactive cells, with the properties: "interactive": true/false, "interactive_id": int/null

• array_index works as cell_id

2) A subset of only the interactive cells of 1) . Resulting in a site-shaped grid that is used as a basis for the user interaction in the online tool. Users can edit all cells in this grid, as all of them are interactive. See here: https://github.com/CityScope/CSL_Hamburg_Grasbrook/blob/master/src/assets/layers_json/geojson_grid.json

• "id" corresponds to array_index of 1)