-
Notifications
You must be signed in to change notification settings - Fork 25
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
Restrict the schemas to valid values #187
Comments
I fixed the 4th above (semantic surfaces) there: 5544e1b in a branch for v2.0.1 |
Point 1 above (version of CityJSON) has been fixed in 1dbd856 |
@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:
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, |
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"
]
} |
Then it would be an extended CityJSON file, with its own schema that allows LoD4.2 I think. 👍 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 #186
Originally posted by balazsdukai November 17, 2023
I experimented with the popular JSON Schema Faker tool to mock CityJSON data.
I used the combined v2.0 schema to fake values for the CityJSON members.
It does generate a seemingly schema-valid CityJSON object, however many members have invalid values, for instance negative vertex indices in the boundaries.
The reason for this is that in several cases the schema does not restrict the values sufficiently.
Below is are the issues and potential fixes that I discovered from the generated CityJSON.
lod
should be restricted to the allowed values.type
. In the example below, the second semantic object does not have atype
member, which is required according to the specs.I don't see drawbacks from applying these restrictions where possible, but maybe others see it differently?
The text was updated successfully, but these errors were encountered: