In this table https://cityio.media.mit.edu/api/table/dungeonmaster/

Inside GEOGRID each block has this properties

"properties":{"color":[106,61,154],"height":4,"interactive":"Web"}

and inside GEOGRIDDATA each block has this properties

{"color":[255,255,51],"height":4,"id":0,"interactive":"Web","name":"Residential"}

Do we need to repeat the information in both field? Isn't it redundant? Also the color value are different

The bottom of the lego model is not accurate :(

I am not sure this is the right place to right this issue.

I am working on making the bridge between GAMA and CityScope taking in example bricks.

This bridge has already been done with 2 projects corktown and grassbrook (which are still runing), in this 2 project I am using the meta_gridproperty to initialize the table but i cannot see any meta_gridfield in the following url
in dungeonmaster,

I am ok to point to another field what I'd like to be sure is to keep the retrocompatibility with what has already been implemented and keep it working.

Maybe be meta_grid should be also change in corktown and grasbrook?

[putting as meta issue here to avoid issue per repo, for now]
As discussed, please archive/remove stale repos. As rule of thumb, a repo you're not planning to maintain or wouldn't remember how to maintain, is probably worth archiving.

A few examples (just random pick from 2nd page):
https://github.com/CityScope/CS_Andorra_Table_Demo
https://github.com/CityScope/CS_SpatialDashboard
https://github.com/CityScope/CS_BentoScope

@LAAP as mention here, CityScope/CS_cityscopeJS#115, there's a slight inconsistency with how we describe "P" here: https://cityscope.media.mit.edu/docs/modules/Types%20System vs here:

This is still not converging.

What about having the Luis picture here for now and then converging together on something. Once this is agreed (doesn't mean it's the final version but at least its version 1.0) then no one can creat e a repository that doesn't fit with the proposal

Thanks for adding this -- https://github.com/CityScope/cityscope.github.io/wiki/Specification-for-CityScope-system
should be merged and renamed into https://github.com/CityScope/CS_Hardware to avoid duplication.
CS_DEPLOY for naming?

Hello Ronan - The above is great!

I have a few questions/comments. Please note the following:

Comment: should a type include information about utilization or capacity (in the same way we use S, M, or L on the Volpe table)? I do not think it should be S,M,L, but we could use a person/meter or some scale factor to add to the definition of components within a type. IE: For a given land-use, we need to outline how they are aggregated? Is it 1 unit or 3 units/floor.

Comment: there will never be an economic activity without a land-use, but there can be land-uses without economic activity. Would it be better to format or organize the data in a way that associates a NICS code of each land-use, when a NICS code is available?

Question: what does the "P" above each land-use mean?

related to #15

I've briefly checked @doorleyr's ronan branch, specifically this file and @RELNO's CityScope/CS_CityScopeJS readme. and I have a question.

for writing up the data formats, how much strictness do we want? Essentially it's a JSON, so the types provided are:

• null
• true
• false
• Number
• String
• Array
• Object

Specifying each element on this level of granularity is something we can aim, but was wondering if it's useful if we go deeper.

"NICS" : 1212.50 // 1-1. int float mismatch
"NICS" : -1 // 1-2. int type mismatch
"latitude" : -2121.00 // 1-3. out of range
"rent" : "100 USD" // 1-4. ?? -> or "rentPerSquareMeters": {value: "100.01", unit: "sqm"}

// 2-1. no NICS field.
"NICS" : [] // 2-2. empty arrays / objects
"NICS" : null // 2-3. null
"NICS" : [{}, [[], []], null] // 2-4. 2-2 and 2-3

Again, it's just JSON, so it's really up to the parser (and it's language) how to handle it.

Too much is stupid (2-4) and I think people can communicate to straiten things out, so I'm not too worried but what do you think @RELNO, @doorleyr, @agrignard?

This is an attempt to have a common place to discuss on the unification task. Nothing is set in stone but at least let's try to converge on a common place to discuss.

What we have so far (not pretending to have an exhaustive view so feel free to complete/comment)

So here the current entry point that should be used to unify everything and that should be included in the wiki if everyone agree:

• wiki https://github.com/CityScope/cityscope.github.io/wiki/CityScope-Data-Format-version-2.0 (it has been moved from the cityIO repo to here). It is pretty weak for now but this is what we have (this is more or less the RS, RM, RL OS,OM,OL, etc) and it will hopefully quickly evolve as a synthesise of this issue in the following days

• Other non github reference (for non github user), is the paper an overleaf initiated by @LAAP that should be also used as a reference
  https://www.overleaf.com/project/5dc19bd7180565000164bd25

• Concerning cityIO
  https://github.com/CityScope/CS_CityIO/wiki/cityIO-Data-Structure

• Concerning ABM Standard:
  https://github.com/CityScope/CS_Simulation_GAMA/wiki/GIS-Structure here the documentation of the input that a volpe like model is requiring to run
  https://github.com/CityScope/CS_Simulation_GAMA/wiki/Game-IT for what we call the Lyon Model

• Concerning Macro Mobility
  https://github.com/CityScope/CS_Mobility_Service there is some standard here used to drive the ABM micro mobility model (both macro and micro) we can think on how to migrate it to this repo or at least make a link

• Current github issues related to this topic:
  CityScope/CS_Simulation_GAMA#66
  CityScope/CS_cityscopeJS#5

I am sure there is other entry point so please feel free to complete it.

• @amcarrero to PR new docs onto the old docs repo
• @RELNO to consolidate docs

Now that the CityScope Framework seems pretty well advanced what about having a common Hello World table and a series of showcases? Right now it's difficult from the documentation (https://cityscope.media.mit.edu/) to access to existing project unless you know the name of an entry table (e.g dungeonmaster)

What about having an entry with:

1. A Hello World/Showcase something similar to volpe (a Volpe2.0) but in my opinion should have another name (e.g MITScope, MediaLab, CityScienceScope, Cambridge?) or whatever but something more meaningful than volpe as very few people outside of Cambridge knows what it is

2. A list of the existing project that can serve as a gallery/library of what can be done so far (right now we have corktown, grassbrook)

Hello everyone,
I can't imagine to be the first one to ask, yet I couldn't find any information on this:
Do you provide the CAD files for the table setup as well? There are great DRAWING-ASSEMBLY(.pdf) instructions in the repo, but to apply our own adjustments, we'd be happy to receive the raw CAD files!
Any place I forgot to browse?
Thanks in advance!

Right now, for this CityScope organization, we have two groups of people. Members and Outside Collaborators. While the definition of an outside collaborator is already vague, the repo guide line does not explicitly define the rights of such position.

Here is how Github puts outside collaborators

BTW, it seems that outside collaborators can make repos, since it doesn't say he/she can't...

Hi Everyone;

As commented on Friday, I have finished the first draft of my understanding of the CityScope diagram/scheme. It is a marged/update of 2 or 3 of the schemas that we already have:

Please, let us know your thoughts

GAMA docs now live here:
docsite/docs/modules/Simulation_GAMA/Simulation_GAMA.md

They are part of the midnight update.

We have to work on that. Assuming that every repo has a licence it should be doable

https://tlo.mit.edu/disclose-protect-your-intellectual-property/disclosure-faqs

This is the proposed procedure of adding new repositories to this github Organization. The reason behind this is to constrain the number of repo's.

1. First develop your code in your own personal account
2. Once you have the initial version (working) discuss collectively whether it's worth it having it official
3. If approved, we add it on the list

Not sure if this is the right repo to post this issue, but I noticed we haven't updated the hostname for the examples in the API documentation. It still reads miragecity which was the test server.

https://cityscope.media.mit.edu/backend/API

We see an emerging ecosystem of the Javascript Suite that @RELNO has been working, we would like to think about how we structure an one-stop solution using (only) JS.

• no external downloads (like Unity, Rhino)
• cross platform
• minimal configuration of the camera
• various visualizations

@popabczhang @agrignard @doorleyr @RELNO @LAAP

(Not sure if this is the best place to raise this, let me know if not)
Per discussion today at lunch with @agrignard @LAAP @doorleyr, we need a solution for getting sending/getting large files to China (e.g. 4K videos for projection mapping).
I did some research and speed test with @SutaBeacon, the following service can get large files in China that uploaded here, vice-versa. But each of them has pros and cons:

1. Baidu Cloud
   https://pan.baidu.com/
   Pros: a) fast upload and download both sides; b) permanent link
   Cons: a) website only have a Chinese version, maybe can Google translate it; b) not direct link (need a key code to download, unless totally public)

2. AWS
   https://s3.console.aws.amazon.com/
   Pros: a) fast upload and download both sides; b) direct link; c) permanent link
   Cons: a) need to create an account to access and heavy permission management

3. WeTransfer
   https://wetransfer.com/
   Pros: a) fast upload and download both sides; b) direct link
   Cons: a) temporary link (7 days for a free account, need try pro account)

4. DropBox
   https://dropbox.com/
   Pros: a) fast upload outside of China; b) easy to manage and share; c) direct link
   Cons: a) need VPN to download in China and normally slow

For Github specificly, we might want to try Git Large File Storage (https://git-lfs.github.com/) workflow.

I'm ok with redundant repo's letting it go with neo-darwinism, but IMO the concept of CSL repos does not seem to work. (I'm not blaming, we are testing things out) @agrignard @popabczhang @LAAP @doorleyr

couple of findings how this org is used.

• Submodules are too hard for people.
• a wiki is enough for CSL (what do we store when eventually everything becomes a tool?)
  • yet, wiki repo is less apparent compared to code base repo's

so should we stop enforcing CSL repos? Maybe, but we do need a way to track projects...

Thoughts on how we do this? I may unofficially bring this up to next weeks Hamburg meeting if we are bored to death. @RELNO

.
.
.

Although this contradicts with every point above, I would like to share how
I started to manage some projects that involves multiple code bases (with ~10 active ppl).

[Project otherwise CSL level]

• project repo's own wiki repo@ddf0145
• amazing backend server code@45ab0
• killer mobile app code@179f6a (branch)
• epic front end code@4b99cd

The important part is to the wiki.git is also submoduled, so we don't loose it when we transfer and it is clear that we are maintaining a wiki. (and you can add images with relative ease) Two attempts
using this methodology and other team members seem to pick it up. (BTW with slack integration)
Plus, this still lets you link to repos outside this org.

Yes, I go down the rabbit hole

Following BRIX workshop, I was hoping to add our videos segments to the docs. I plan to use MDX.js - react embedding of youtube videos, like in this example: https://github.com/mdx-js/mdx/blob/master/examples/create-react-app/src/content.mdx

How would we go by doing it for your docs? Since they live in your repo, and are read by your docs site, wouldn't using MDX syntax break your doc site?

there are still some formatting issues. eg. in some cases, you have key-value pairs where the key is an object and the value is a proportion. eg.
"NAICS": {{"440000":"0.50", "450000": "0.50"}:"1"}
this is invalid json because the key of a key-value pair must be a string. You can fix the above example by changing it to:
"NAICS": {"use": {"440000":0.5, "450000": 0.5}, "proportion" :1}
I know this is less tidy but unfortunately its necessary. I'm happy to help with correct formatting once the content is nailed down.

Dear @yasushisakai ,

Today the server is down. Please, can you double check it?

Thanks!

clean up this repo in alignment with the standalization effort

@yasushisakai as discussed, please suggest the best way for you to include cityIO docs in here. The 2 options are: 1. simply move 2. copy here, and ask @crisjf to modify a GH action to keep in sync with your repo.
I see [1] simpler and cleaner, but it's up to you.

This is subjective, but I feel creative alternatives are needed for following repo names.

If things are combined separate the functionalities to single repositories. If it needs to be linked, use another repo that uses submodules(recommended) or a readme to indicate the dependencies.

CS_Toolbox
CS_Hardware
**Template
CS_CSharpScope_* (with the exception of BRT)
CS_DataVisualization

kind of related to #7

I purpose we add the appropriate creative commons license to this repo.
Note that this repo includes the hardware stuff, which is also not code.

The discussion is that which license,
From my current understanding, we want to

• share alike: make sure everyone uses the same license if someone adopts it and remixes it
• not for commercial

which is fine but the site implies your not "free culture"

this might be an executive decision but thought its nice to bring it up anyway.