are "geometry-templates" allowed in JSONL?

[hugoledoux]

the text contradicts itself, should they be "resolved" (real-world coordinates) or is it okay to put them in the 1st line or stored somewhere?

[hugoledoux]

If we put the whole "geometry-templates" in the first line (and do not dereference them in the objects), then for the Railway dataset the 1st line is pretty large: 21KB (without spaces and newlines).

To keep in mind

[balazsdukai]

In contrast, I've been thinking about including the "geometry-templates" in the CityJSONFeature, but only containing the template(s) that is used by the feature.

For instance like this:

{
  "type": "CityJSONFeature",
  "id": "id-1",
  "CityObjects": {
    "id-1": {
      "type": "Building",
      "attributes": {
        "roofType": "gabled roof"
      },
      "children": ["mywindow"],
      "geometry": [...]
    },
    "mywindow": {
      "type": "BuildingInstallation",
      "parents": ["id-1"],
      "geometry": [
        {
          "type": "GeometryInstance",
          "template": 0,
          "boundaries": [372],
          "transformationMatrix": [
            2.0, 0.0, 0.0, 0.0,
            0.0, 2.0, 0.0, 0.0,
            0.0, 0.0, 2.0, 0.0,
            0.0, 0.0, 0.0, 1.0
          ]
        }
      ]
    }
  },
  "geometry-templates": {
    "templates": [
      {
        "type": "MultiSurface",
        "lod": "2.1",
        "boundaries": [
           [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]]
        ]
      }
    ],
    "vertices-templates": [
      [0.0, 0.5, 0.0],
      ...
      [1.0, 1.0, 0.0],
      [0.0, 1.0, 0.0]
    ]
  },
  "vertices": [...]
}

However, the problem with this approach, or with dereferencing the templates in the CityJSONFeature, as it says in the specs currently, is the duplication of objects. Imagine and application, a 3D viewer, that populates the scene by loading the CityJSONFeatures that are in the view. The features are buildings with templated windows on the facades. There are a lot of windows on one building, and even more on many buildings... :-D. If the window-templates need to be duplicated for each feature, then that'll mean a lot of extra geometry, which could be avoided by loading the templates only once and reusing them for the features.

I don't particularly like the idea of dumping more and more stuff in the "first line" (I call it metadata), but I think if we include the template definitions with the features, then we practically lose the possibility of using templates (in their true sense), when using CityJSONFeatures. And since CityJSONFeatures are meant for handling large areas, templates are probably even more useful than in regular CityJSON files.

[clausnagel]

I agree that dereferencing geometry templates is a strong limitation of the current CityJSONFeature approach. Putting the templates in the first line would be a valid solution. It also means that a software creating the stream of CityJSONFeature objects must know the required templates a priori. In a database scenario, for example, this might require additional and possibly expensive queries before being able to write to the stream.

Another solution would be to store a geometry template with the first CityJSONFeature object that uses it. The next CityJSONFeature could then reuse this template. For this purpose, templates would require a unique identifier to be able to reuse them. This would avoid duplicate templates in a CityJSONFeature stream and therefore keep the stream compact. And no extra queries required in the database scenario from above.

I am aware that this idea breaks with the current philosophy of having all templates at one place, which also has a lot of benefits. Just wanted to put it on the table as another approach.

[hugoledoux]

I am not a big fan of the 2nd solution: put the template in the first CityJSONFeature, since then each feature can be different. And how to ensure uniqueness?

I think the best is to have in the first line, and/or in the metadata somewhere (at the cost of some operations for a database, agreed).