The old text said "These properties may be accessible, for instance as a JSON object (the first one)".
And then in the stream example there was a {"type": "CityJSON","version": "1.1","transform":{...},"metadata":{...}}, which is invalid CityJSON btw.
This was very confusing, because the example suggested that the first json object should also be a CityJSON object, but the description only mentioned a JSON object, thus any JSON object.
IMO it is better to stick to what is already in the specs, such as using CityJSON objects. But this implies that this object must be valid, even if it has redundant, empty properties (CityObjects, vertices). This makes for a cleaner implementation.
Because if the first object is not valid CityJSON, then the transfrom, CRS properties can be stored in whatever member of the JSON object and then the cityjson client cannot parse them.
The old text said "These properties may be accessible, for instance as a JSON object (the first one)". And then in the stream example there was a
{"type": "CityJSON","version": "1.1","transform":{...},"metadata":{...}}
, which is invalid CityJSON btw.This was very confusing, because the example suggested that the first json object should also be a CityJSON object, but the description only mentioned a JSON object, thus any JSON object.
IMO it is better to stick to what is already in the specs, such as using CityJSON objects. But this implies that this object must be valid, even if it has redundant, empty properties (
CityObjects
,vertices
). This makes for a cleaner implementation. Because if the first object is not valid CityJSON, then the transfrom, CRS properties can be stored in whatever member of the JSON object and then the cityjson client cannot parse them.