Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extra extension attributes for semantic surface objects? #203

Open
clausnagel opened this issue Aug 19, 2024 · 5 comments
Open

Extra extension attributes for semantic surface objects? #203

clausnagel opened this issue Aug 19, 2024 · 5 comments

Comments

@clausnagel
Copy link
Contributor

I'd like to add extra attributes to semantic surface objects like, for instance, a +material to "WallSurface". I understand that I can simply add attributes to a semantic surface in a schema-less way. But I'd like to define a schema for these additional attributes in the same way I can define a schema for additional attributes of city objects.

Is defining extra attributes for semantic surface objects supported by the extension mechanism? At least it seems that the spec only covers the definition of new semantic objects.

And why are JSON objects not allowed as attributes of semantic surface objects but only simple values? For example, if I had a value and a unit of measurement, the following attribute would be possible for city objects but not for semantic surfaces:

"myAttribute": {
  "value": 10
  "uom": "m"
}
@hugoledoux
Copy link
Member

hugoledoux commented Aug 21, 2024

Is defining extra attributes for semantic surface objects supported by the extension mechanism?

Yes! If you look at the specs you can see that you can define extra attributes and make them "required".

Here's a simple example, cjval cube.city.json -e thermal.ext.json --verbose to test/validate.

And why are JSON objects not allowed as attributes of semantic surface objects but only simple values?

Hmmmm, I guess we wanted to keep it simple, but I agree that it could be useful. Maybe @balazsdukai remembers why we/I did this? This could I guess be changed easily for future releases

@balazsdukai
Copy link
Member

balazsdukai commented Aug 21, 2024

No, I don't remember unfortunately, I can only guess. That guess would be the same as yours, to keep parsing as simple as possible and avoid deeply nested objects as attribute values.
I have some vague memory that we might have discussed scalar-only semantic attributes with @hugoledoux at some point, years ago, but maybe I'm just dreaming... :-D
But yeah, if objects are allowed values for CityObject attributes, then I don't see a reason why not allow them for Semantic surfaces too.

@balazsdukai
Copy link
Member

I just did some digging and the array/object CityObject attribute type was made explicit with 63fa008, as agreed in #141 .

@clausnagel
Copy link
Contributor Author

Thanks @hugoledoux for your example. I would prefer not to define a new semantic object like "+ThermalSurface" though but just to add new attributes to the predefined semantic objects of CityJSON. I have slightly adapted your example to illustrate this: cube-adapted.city.json

I know that you can add arbitrary attributes to semantic objects in a schema-less way like, for instance, the "slope" attribute of the "RoofSurface" in the example. But this "slope" attribute is not defined in any schema and, thus, cannot be automatically tested (e.g. correct spelling, correct data type and value). I would rather like to define an attribute like "+azimuth" of the "WallSurface" in the example and define this attribute in an Extension schema similar to extra attributes for city objects. But this is not covered by the spec at the moment, is it?

@balazsdukai, thanks for pointing to #141. I guess a similar clarification as added with 63fa008 would be nice for semantic objects as well.

@hugoledoux
Copy link
Member

oh now I understand what you mean, sorry.

No it's not covered by it at the moment, but I guess this could (should?) be added to the next release, I see that it could be useful indeed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants