type of "layers" should be array

[kunlinyu]

IndoorGML-SWG/IndoorGML2/IndoorGML2-v.0.3/Part II/JSON/indoorjson2.schema.json

Line 292 in 27d5089

"type": "object",

[TaehoonK]

This is not an array of layers but a SET of layers according to "additionalProperties"; A JSON object is essentially a set of (key-values).

IndoorGML-SWG/IndoorGML2/IndoorGML2-v.0.3/Part II/JSON/indoorjson2.schema.json

Line 293 in 27d5089

"additionalProperties": { "$ref": "#/definitions/ThematicLayer" }

This is because, like InterLayerConnection, we need a reference by object name (as the key of the object).
Similarly, "cellSpaceMember" and "cellBoundaryMember" have the same structure.
Take a look at indoorjson2_dummy.json, I think you'll find it easy to understand.

Of course, you can add an "id" attribute and use it to maintain a reference relationship, but for now, we've implemented version 2.0 using the structure used in the previous IndoorJSON, so we've used the same structure.

[kunlinyu]

@TaehoonK I think "key" should not be the id of an object. I mentioned it in another issue. that will make the parser and encoder very complicated. Accturally there are so many ways to handle the "id" or "reference" issue without write any code. I think we can just find one and use it.

[kunlinyu]

@TaehoonK let me give you an example:

https://github.com/kunlinyu/IndoorSim/blob/master/Assets/src/Tests/full_test/circle.indoor.json

{
	"$id": "1",
	"indoorFeatures": {
		"$id": "2",
		"layers": [
			{
				"$id": "1000000",
				"cellVertexMember": [
					{
						"$id": "3",
						"Id": "no id",
						"Geom": "POINT (-2.4650919437408447 2.3991801738739014)"
					},
					{
						"$id": "4",
						"Id": "no id",
						"Geom": "POINT (0.09227617084980011 2.4519088268280029)"
					},
 ... ...

In this implementation, each json object has a field named "$id", some of json object has a field named "Id".

The "Id" was been used according to business logic. The producer add it and some consumer may use it. It is nothing to do with the standard. We can treat it as a private extension.

The "$id" was been generated automatically by some Json serializer. That is because in the code:

// java
class CellSpace {
  Polygon geometry;
  CellBoundary partialBoundedBy;
}

// C
class CellSpace {
  Polygon geometry;
  CellBoundary* partialBoundedBy;
}

// C++
class CellSpace {
  Polygon geometry;
  std::sharped_ptr<CellBoundary> partialBoundedBy;
}

There is a reference declared in the CellSpace. For all programming language support reflection, they can add a non-existing "$id" field in the json and refer it in another json object, just like this:

"cellSpaceMember" : [
{
  "$id": "1";
  "geometry": "//WKT";
  "partialBoundedBy": {"$ref": 2}
}
],
"cellBoundayMember": [
{
  "$id": "2";
  "geometry": "//WKT";
}
]

Most of serialization library written by language support reflection can add extra "$id" and "$ref" to support "object graph". this is a common issue when we need to serialize a object graph to json which can only represent a tree.
When we use this kind of serialization libray, nothing we need to do. There is no need to do this:

class CellSpace {
  string id;
  // other fields
}

"$id" will generate automatically.

At last I think make layers to be an array is better. Because it is an array indeed.