Material/texture questions

[clausnagel]

The v0.2 Json schema only defines "material" and "texture" properties for the geometry types Solid and MultiSurface . What about CompositeSurface, MultiSolid and CompositeSolid? In CityGML, also their surface members can receive appearances.

What about the depth of the arrays of "material" and "texture" for each geometry type? According to the examples in the spec, "texture" seems to have the same hierarchial structure as "boundaries", whereas "material" seems to be a flat array. Is this correct? Would be great to have these definitions in the Json schema as well.

Often not all surfaces of a building shall receive a material or texture. Just think of the GroundSurface, which is not visible in most viewers anyways. How do you denote non-colored resp. non-textured surfaces in the "material" and "texture" arrays?

[hugoledoux]

1. I forgot these, yes of course all 3D primitives having surfaces can have a texture. This is also related to the issue #3 , which I'll find a way, probably a key-value pair "name"-"texture"/"material" for each one, the "name" giving the context of the texture (like "winter" or "night"). Something that is I believe not prescribed in CityGML is: which one to use for a visualisation? I couldn't find anything. I was thinking of having teh first, but if I use a key-value then the order is not guaranteed to be preserved... suggestions?

2. This is indeed rather sloppy in v0.2, my plan was to work on this for v0.3. In short, yes texture has the same structure as the boundaries array (each vertex is mapped to another one), but material has (depth-2): each surface "[[]]" get a material, which is an integer. I'll enforce this (soon) in the schema and in the software "cityjson-valschema"

3. another thing on my list. I reckon that null should be used, but I'm not sure what is the proper JSON way to do this. or -1 since we index from 0.

[clausnagel]

ad 1: You could introduce some property like "defaultTheme" whose value would be the name of the default theme. If this property is not present in a CityJSON dataset, then it would be up to the viewer to decide (possibly by asking the user for input). CityGML 2.0 in fact does not support to denote the default theme. Maybe worth a CR.

ad 2: Great, thanks. I am currently working on CityJSON support for citygml4j. I think it makes sense to wait for the appearance representation to be more stable before implementing it.

ad 3: Well, I use Gson for parsing/writing Json in Java. It easily supports null values:

"material": [
    [0, 0, null, 1, 1, 1]
  ]

Maybe that's alreasy a feasible way?

[hugoledoux]

1. done, see #3 for my proposal

2. I saw, this is great and very much welcome! That means that we'll be able to convert back-and-forth, right?

3. yes null works for sure, I was more thinking whether an empty object {} is better... or if I have a surface that has no textures, do I put [[]] or [[null]] ? I chose the latter at this point, but need to fiddle with my json library.

[hugoledoux]

✅ see #3