scores parameter of cityiograph.City unclear

[kalyons11]

This parameter can cause issues when sent to JSON, as sometimes the order of the list values in city.scores does not match the same order of the keys in city.metrics.

As I see it, there are 2 solutions for this issue.

1. Remove the scores parameter altogether. We know it can be quickly calculated, as it is done here:

scores = [ weight * fun(city) for name, fun, weight in self.metrics ]

2. Change city.scores to be a dict mapping metric key -> weighted score value. This way, you never lose clarity in which score value matches up to which key. This may also come into play when it comes time to visualize scores in the GH client.

[popabczhang]

Agreed. I will prefer solution 2, because Unity and GH client need it to visualize the scores. I will edit the GH CV client to send the JSON format as you suggested: {"grid":[...],"objects":{...,"scores":{"density":0,"diversity":0,"energy":0,"traffic":0,"solar":0}}} Alex once pointed out that the values of these scores should not be multiplied by the AI Weight, but the original scores calculate the from the city. Because when you visualize them in GH and Unity client, you don't want the radar chart to show zero scores when the AI Weights are put to zero by the users.

[popabczhang]

Question: will the order issue happen on the following lists in JSON? "densities": [1, 1, 1, 1, 1, 1], "AIWeights": [0.2, 0.2, 0.2, 0.2, 0.2], "AIMov": ["CELL", 0, 0, 0],

[kalyons11]

1. Then what makes this scores parameter any different from the metrics dictionary if we are not multiplying by the respective weights?

2. I don't believe those other lists, like densities, AIWeights and AIMov are inverted. We haven't had any issues in the past with density indices changing. I just saw that in a few of the example predicted cities, the scores and metrics did not match up numerically element-wise.

[popabczhang]

JSON format update: