Closed hugoledoux closed 4 months ago
I fixed the 4th above (semantic surfaces) there: https://github.com/cityjson/specs/commit/5544e1bd0c54c508603ec239938d78e07334e963
in a branch for v2.0.1
Point 1 above (version of CityJSON) has been fixed in 1dbd85685dcf7aa5709b48f00b1eccf79d0fdd45
@balazsdukai for the #3 above ("The lod should be restricted to the allowed values"), I am not sure we want to do this... The specs state:
The value must be a string with the LoD identifying the level-of-detail (LoD) of the geometry. This can be either a single digit (following the CityGML standards), or "X.Y"-formatted if the improved LoDs by TU Delft are used.
If we restrict, we go up to what? LoD3.3? What if someone wants LoD4.2?
Maybe @fbiljecki has something smart to add here?
If it follows the two standards, then it is better to constrain it with their possible values and ranges, that is, 3.3
being the maximum in the latter case.
this is the ones that would be accepted with CityGML3 (no LoD4 here)
"Lods": {
"enum": [
"0", "1", "2", "3",
"0.0", "0.1", "0.2", "0.3",
"1.0", "1.1", "1.2", "1.3",
"2.0", "2.1", "2.2", "2.3",
"3.0", "3.1", "3.2", "3.3"
]
}
What if someone wants LoD4.2?
Then it would be an extended CityJSON file, with its own schema that allows LoD4.2 I think. :+1: for 29dfdc4
Hmmm, no that would mean no geometry types since "lod" is a child of "geometry" and this is not possible to modify.
But CityJSON is CityGML (thus only 0-1-2-3) and the TUDelft-LoDs, so restricting is fine. If you want more than you can use IFC I guess
Discussed in https://github.com/cityjson/specs/discussions/186