Multiple unknown servers [which is a GOOD thing]

[RELNO]

• There are several new endpoints which are not clear if operative, test or else. Again, it's a good thing, but also introduce a stronger need to specify [maybe in header name? Meta?] who's/why's this table exist. We might as well add a 'kill switch' for non-updating tables after stale period?

• Also -- which is the mockup cityio[v2] table now? [fake or virtual] both are not updating every minute, though virtual did update y-day.

• @doorleyr do you know who's running the https://cityio.media.mit.edu/api/table/cs_aalto table?

[yasushisakai]

on adding fields to the meta or the header, I think it is fine and good to have, but the incentive to add such info will be lower then fields like the grid. The question is whether we want it to be a required field or a optional or something like a convention. Should we have a enforcing mechanism something like the server rejecting posts without them? or the sever can verify and add a isVerified(bool)

other facts

• The virtual_table is the official sutra, it should be now broadcasting again.
• I was experimenting on few other things in the course of this weekend. I killed them now, using the delete endpoint.

[agrignard]

Several thing on this issue that I didn't take time to read carefully

• Indeed it can be nice to specify in the header who is here, even if if ones follow our proposal header we should have at least the position of the table so we should be able to identify who is here

• Speaking about Aalto how come they can produce a json that is still the old school version. I think that raise an issue on the GH side (see https://github.com/CityScope/CS_Rhino_Grasshopper_Template/issues/1). We have to be careful that any new comer is at least using our new template otherwise we loose the track

• I think the name should be self explanatory but why not having one more field in the header

• That raise also the question about having a kind of 'validator' that can say if the table is the right format or not (even if I know that know the server is agnostic to the content as soon as it's a valide json). Maybe we could run a kind of 'cleaner' script like ones every week/month that would keep only the valid table. A bit extreme but at least having a way to identify what are the actual compatible table

[RELNO]

@yasushisakai @agrignard -- In my view, forcing some 'handshake' is counterproductive to the openness we wish to have. Instead, let's just add a header field that defaults with the following:

"header":{ "mapping":{ "type":{ "0":"RL", ... } }, "spatial":{ "nrows":20, "latitude":42.360357, "rotation":0, "physical_latitude":42.360357, "ncols":20, "physical_longitude":-71.087264, "longitude":-71.087264, "cellsize":10 }, "name":"virtual_table",

"owner":"NAME, TITLE, INSTITUTE"

"block":[ "type", "height", "rotation" ] },

So if users don't fill this in, they see this with every GET

[yasushisakai]

@agrignard your 2nd bullet should be a different issue.

@RELNO so is what you're are saying we have it in the wiki, but we don't validate?

[popabczhang]

Agree with @yasushisakai that 2nd bullet should be a different issue. Opening one now.

[yasushisakai]

added in both virtual_table and wiki

closing

[agrignard]

just a small detail

"institude" => institute or institution?

[yasushisakai]

'institute' ref

closing as for a5900e51d2468fcdaaf01ad5ffaacdba1dcc5930