List of possible land-Use types to be table-specific and read from cityIO

[doorleyr]

The list of possible LU inputs needs to be different for different tables. Therefore, instead of being read from a static text file, they should be read from cityI/O.
The type definitions for grasbrook, corktown and aalto_02 are currently in the header of the GEOGRID on cityIO.

[RELNO]

Thanks, list looks good. I'm wondering if instead of using "num":{...attr}", we can simply call the type in name: "name":{...attr}" . Then, the grid field will point to the index in the list. What do you think?

[doorleyr]

If we're using a dictionary with name as key then we can't use numerical indexing. In python for example, dicts are unordered so there is no way to access the ith element of a dict. If we instead use a list of objects with name as an attribute, i.e. [{'name': 'the_first_name', 'attr1': 1 ....} , {'name': 'the_second_name', 'attr1': 2 ....}, then that would work. But that's pretty similar to what we're doing now.

[LAAP]

Dear all,
I am still working on the crosswalk between NAICS with the LBCS (little by little is happening), but I think that so far we can extract 12 "Types" at the "X0000" level that covers most of the "databases-uses". I think that it is a good step for a 1st iteration:

1 | Residential
2 | Shopping
3 | Restaurants
4 | Office
5 | Industrial
6 | Infrastructure
7 | Transportation
8 | Events
9 | Parks
10 | Leisure & Sports
11 | Natural resources
12 | Nature

I am still working on this doc:

https://docs.google.com/spreadsheets/d/13doHHa1A4jAQ886ehkBUvIf6j9HDaMF6FZJV5A6fZ68/edit#gid=854063265

[yasushisakai]

Therefore, instead of being read from a static text file, they should be read from cityI/O.

There is nothing stopping you from using cityio for this but just asking out of curiosity. Could the land use json be a repo by itself and get requested via https://raw.githubusercontent.com/foo endpoint? This way the static files can be versioned, and access previous versions via this url (with the commit id).

please disregard if there is dynamic data involved and you actually need a rest api backend.

[yasushisakai]

you can leverage the pull request governance too to dictate which changes are permitted and which are not. (whic cityio only lets you with coarse auth)

[RELNO]

@LAAP thanks. One suggestion is that we can use https://cityscope.media.mit.edu/CS_cityscopeJS/ [click on page: data standards] to keep documentation of types. This documents are all stored here: https://github.com/CityScope/CS_cityscopeJS/tree/master/docs which are .md files to which users can PR and issue as needed. This might also answer @yasushisakai question.

[RELNO]

ref'ing our past conv on this CityScope/cityscope.github.io#15

[agrignard]

Some comment
@LAAP and @markus (withou github account ) I think you are working on this but just to be sure can we work on the same document
Luis one is this one
https://docs.google.com/spreadsheets/d/13doHHa1A4jAQ886ehkBUvIf6j9HDaMF6FZJV5A6fZ68/edit#gid=593854283
and markus on is this one
https://docs.google.com/spreadsheets/d/1S57LJHtZklmHplF08b3oA3qnd8Hx6DqMUQXvj9wO-oU/edit#gid=586484925

Then after for the documentation, I think it's better to keep this on this repo as this information is language agnostic and might be share with many cityscope project https://github.com/CityScope/cityscope.github.io

[agrignard]

And one last question I guess there is a good reason why 12 types but why The 9 from LBCS were not enough? is it because some of the 12 are not landuse?

[LAAP]

Hi Arnaud, Markus has unified in his old excel: https://docs.google.com/spreadsheets/d/1S57LJHtZklmHplF08b3oA3qnd8Hx6DqMUQXvj9wO-oU/edit?ts=5e692a4f&pli=1#gid=586484925 Maybe he will change the name I am still trying working (when possible) into the correlation between NICES and LBCS Best Luis El lun., 23 mar. 2020 a las 16:40, Arnaud Grignard (< notifications@github.com>) escribió:

…

Some comment @LAAP <https://github.com/LAAP> and @markus <https://github.com/markus> (withou github account ) I think you are working on this but just to be sure can we work on the same document Luis one is this one https://docs.google.com/spreadsheets/d/13doHHa1A4jAQ886ehkBUvIf6j9HDaMF6FZJV5A6fZ68/edit#gid=593854283 and markus on is this one https://docs.google.com/spreadsheets/d/1S57LJHtZklmHplF08b3oA3qnd8Hx6DqMUQXvj9wO-oU/edit#gid=586484925 Then after for the documentation, I think it's better to keep this on this repo as this information is language agnostic and might be share with many cityscope project https://github.com/CityScope/cityscope.github.io — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#57 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AETLUDPCNLUKDD73G4V4S4TRI7CLZANCNFSM4K7VSFZQ> .

-- *Dr. Luis A. Alonso Pastor* *City Science Group* *MIT Media Lab* *E15-368* *20 Ames Street, E15, Cambridge, MA 02139* *Tel: 617-253-5960* *Cell: 857 285 1600* http://cp.media.mit.edu/luis-alonso http://cities.media.mit.edu/andorra-about/

[LAAP]

2nd. After correlating the 9 LBCS "Categories/Types/whatever-name" at the level X0000, With the 19 "Categories/Types/whatever-name" of NAICS, the conversion gave us 12 (so far). I think that that will be the final ones, however, it is not set in stone yet

[yasushisakai]

to keep the conversation linear, please disregard my comment earlier.

[doorleyr]

Related to progress on CityScope/cityscope.github.io#15

We should now be able to update the FE so that the list of types comes from cityIO rather than the text file.

https://cityio.media.mit.edu/api/table/corktown/GEOGRID/properties/
https://cityio.media.mit.edu/api/table/grasbrook/GEOGRID/properties/

Note that the new attributes (NAICS and LBCS) should not go into the GEOGRIDDATA because (a) they are static and can be looked up from the name of the type and (b) including them would make the data exchange much larger on every update. The format of the GEOGRIDDATA can therefore stay exactly as it is. Any module which needs the NAICS/LBCS information can get it from the GEOGRID properties on initialisation.

[RELNO]

#77 closes this, open again if needed