add support for <grp:CityObjectGroup>?

[hugoledoux]

on another channel, @clausnagel and I discussed <grp:CityObjectGroup>, see https://github.com/citygml4j/citygml4j/issues/10

The question is: should we add support for them in CityJSON? The proposal of Claus is simple and doesn't affect any parsers, just that the type should be ignored. I'm in favour, although it's seldom used in practice it seems.

Claus' solution

introduce a new CityObject type:

"CityObjects": {
  "id_01": {
    "type": "CityObjectGroup",
    "parent": "id_of_parent",
    "members": ["id_of_member_1", "id_of_member_2", "id_of_member_3"] 
  }
}

So the CityObjectGroup would basically just list its parent and members by gml:id. Would make the group more explicit and possibly more easy to query. In CityGML, a group can even have geometry, so this could also be represented in CityJSON if the group is represented in this way.

[hugoledoux]

I thought of it a bit, and a new CO is cumbersome since it's not really an CO like the others and programmers need to skip that type.

Why not just creating a new member named "CityObjectGroups" and then list them as you propose:

{
  "type": "CityJSON",
  "version": "0.5",
  "CityObjects": {},
  "CityObjectGroups": {
    "neighbourhood-1": {
      "parent": null,
      "members": ["id-1", "id-2", "id-666"],
      "geometry": { ... }
    },
    "neighbourhood-2": {
      "parent": null,
      "members": ["id-44", "id-22", "id-26"]
    }
  },
  "vertices": []
}

[kenohori]

No strong opinion either way. Programming-wise, the first option is easier if one wants to get a hierarchy of objects. The second is easier if one doesn't care about the hierarchy.

Also, is "parent" really needed?

[hugoledoux]

ok, I did what I should have done first--read the CityGML specs about groups--and my proposal is not inline with CityGML since:

CityObjectGroups aggregate CityObjects and furthermore are defined as special CityObjects. This implies that a group may become a member of another group realizing a recursive aggregation schema.

Thus the proposal of @clausnagel is what should be done. "CityObjectGroup" is a new CityObject, with a few attributes and a possible geometry (1 max).

I agree with @kenohori that "parent" is not needed, just adds complexity and bidirectional information is not really needed, so I'd leave out. Also, why can't a member not be part of 2 conceptually different groups?

[clausnagel]

Sounds like a good compromise to me 👍