Complex attribute type for building function

[ozgetufan]

I tried to convert a CityGML file to CityJSON with citygml-tools where the buildings may have multiple functions, but since building attributes in CityJSON are all string types, only the first function is translated and the rest of the information is lost. I also opened an issue for citygml-tools but I've gotten the answer that this is because CityJSON doesn't have complex attributes, and even though they can be added with an extension, I believe it is not possible to use this for the conversion between CityGML and CityJSON.

[hugoledoux]

why not just concatenating the 2 values with a ";", so "function": "winkelfunctie;woonfunctie",

[ozgetufan]

If I manually add functions, then yes, this would work well. But then wouldn't it be better to standardise this (mentioning the use of a specific separator, etc.) in the CityJSON specification, so that conversion between files is more straightforward? Like the case of converting from CityGML to CityJSON with citygml-tools.

[balazsdukai]

I would not standardise a separator it to be honest. There are multiple ways to solve this problem, the simplest is using a separator as above, but one can also create complex attributes in CityJSON. What is best, depends on the goals of the application. Concatenating the values with whatever separator is completely fine, and it even saves space compared to complex attributes. It's not difficult in a client application to split a string at a certain separator, and a data analyst working with the attribute values will often transform the attributes to what is best for their particular analysis.

[hugoledoux]

also, since in v1.1 we went away from prescribing the attributes, any attribute is fine: https://www.cityjson.org/specs/1.1.2/#attributes-for-all-city-objects

this means in theory you could have "functions": [ "winkelfunctie", "woonfunctie" ]

I am also against standardisation of this.

[clausnagel]

Interesting discussion. There are now different proposals for how to encode multiple function attributes. Of course, it is easy for an application to split a string based on a delimiter if the application knows the delimiter a priori. And as a tool developer I'd rather prefer to avoid implementing different ways for encoding the same thing knowing that the next CityJSON dataset I come across might even use another encoding. Seems to hinder interoperability.

On the other hand, I understand the schemaless philosophy of CityJSON. I think going back and forth between CityGML (it's GML encoding) and CityJSON is a very common and frequently requested use case. I would therefore appreciate a common way to map complex CityGML attributes in this conversion so that no information is lost and applications can rely on one representation. But imho CityJSON does not have to standardize this. It could be an implementers' agreement or a best practice - with a corresponding CityJSON Extension schema in the best case.

[hugoledoux]

Since the conversion CityGML->CityJSON is probably done by your software @clausnagel (FME is the only other option, but there people can control how attributes are mapped and transformed), I think you can take the decision yourself as to what you think it's best.

For CityJSON->CityGML conversion, then I admit that it's not always easy for citygml4j... But you could indeed define a few rules, and if files do not follow those then too bad the conversion of those attributes is skipped.

[clausnagel]

You are right, @hugoledoux, that's a way to deal with it. I guess the "too bad" thingie was one reason for starting this issue. So, I think it should rather not be left to a tool to avoid interoperability issues. But all good, the best-practice idea was just a proposal.

[hugoledoux]

okay, what about we draft here something and we can add it to the cityjson.org website? This would be what you use internally for citygml4j also.

[clausnagel]

Sounds great, @hugoledoux. I am happy to contribute. Most of the complex attributes are mapped to simple ones by citygml4j currently, so there are not too many rules.