Can a CityJSONFeature be of a 2nd-level type?

[hugoledoux]

I realised this is not 100% clear in the specs, should this below be allowed?

Notice the BuildingPart type. This would imply that somewhere in the stream (before or after I guess) there is another CityJSONFeature with "id"=id-99 and that the client must handle this case. This makes the life of the creator of the stream easier, but complicates that of the receiver (the features are not independent anymore).

I am ambivalent about this, curious about other opinions here!

{
  "type": "CityJSONFeature",
  "id": "id-1", 
  "CityObjects": {
    "id-1": {
      "type": "BuildingPart", 
      "attributes": { 
        "roofType": "gabled roof"
      },
      "parents": ["id-99"],
      "geometry": [...]
    }
  },
  "vertices": [...]
}

[balazsdukai]

It says in the specs that "all the children of the "CityJSONFeature" must be included (and the children of the children (recursively), if there are any)." To this means that all related 2nd level objects must be included with the parent in the same feature. If we send a 1st level object, then all it's children must be included. We are allowed (or not forbidden) to send 2nd level objects on their own. With these conditions then, I receive a BuildingPart, but then I also want its parent. When I receive the parent Building, it will contain the BuildingPart again.

I think it should be the same rule for 1st level and 2nd level, but not a mix. Bundling relatives make for more complicated server side operations, but improve the quality of life for the clients in my opinion. It's probably more efficient too, since i'm guessing that all relatives of an object in most cases. If we send them in one bundle that's a single transfer. If they are separate, it's one transfer per relative.

So I think we should bundle.

[clausnagel]

Good catch, @balazsdukai. Having the building part twice in the stream as in your example would be redundant and quite confusing.

I'd also say that a CityJSONFeature should be a 1st-level object with all its children included, but not a 2nd-level object. Makes consuming the stream easier and I don't really see an issue on the producer side.

[cportele]

My preference would also also be to include children always together with the 1st-level object.

[hugoledoux]

OK, thanks for the prompt replies everyone!

We stick to what was there.