Comments (13)
I totally agree with the downside you mention @clausnagel. However, as Stelios mentioned, unfortunately I don't think it's possible to do with the JSON Schemas, at least not with "vanilla ones". The concept of inheritance does not exist as in XML. So one would have to overwrite "Building" type, but this is not what we want.
The only way would be to define ourselves the mechanism, that is we "stitch" the attributes in a given file to the "Building" type, it's rather easy to do but I hesitate to go this way. The validation becomes less generic, and one can't validate with a generic JSON Schema validator.
However, it should be said that with the Extensions CityJSON has already gone down that path... the validation is a 2-step process: (1) generic CityObjects; (2) the Extensions are validated one-by-one. So if we all like the idea, it's possible to do so.
Do we?
from specs.
ok, I took the "favourite way" from above and implemented it, it's in the branch 'development'.
The schemas have been all revamped, ie now they use _AbstractObjects
which are reused for the Extensions; it's now simpler and less error-prone to extend objects for Extensions.
I too prefer to have all the attributes inside "attributes"
only (single point of entry for developers), and this is the behaviour I forced for adding new attributes to existing City Objects. Of course if one defines a new CityObject she can have another list, but if it's only extending the attributes of a CityJSON Objects then it's must inside "attributes"
.
All new attributes/properties/CityObjects start with +
; the only question left is whether we force the "namespace" before the attributes as Claus discussed above. I would leave it to the person making the Extension to decide. What you think?
You can read the draft of Extensions online: https://www.cityjson.org/en/development/extensions
from specs.
I think this is a very nice idea. Having a predefined single point of extension attributes, like the proposed "extension-attributes", is probably the best way to standardise the process.
As far as I understand, though, it can only be offered as a "best practice" suggestion, as JSON schemas cannot force/validate all those rules. For instance, the extension creator can only standardise the attributes of the "+noise-attributes" object, but cannot specify which types of city object can have this attribute. In addition, JSON schemas cannot really validate whether extension attributes are inside the "extension-attributes" or not (I think).
So, in the end, fully complying with this will be up to the developer/user. But I still think this is the best possible solution and maybe it should be encouraged through the documentation.
from specs.
Ok, I understand that a standard JSON Schema validator would not work. So, the cjio
validation is a specific implementation to be able to deal with CityJSON extensions?
As @liberostelios wrote, I would also be happy if the approach would only be encouraged through the CityJSON documentation in a first step.
Just because I'm curious: If you take the CityJSON schemas plus a set of extension schemas that follow a well-defined structure, then it should be possible to write a small software that combines them and outputs a valid JSON Schema file. This could then be fed to a standard JSON Schema validator in order to validate a given dataset. The extension "schemas" would not even have to be fully compliant JSON schemas themselves, but could just be snippets. Is this correct? If so, sounds doable.
from specs.
That's a brilliant idea.
I indeed already stitch and resolve the references to build one schema (from the different files), so if there was a small script stitching the different parts (defined in JSON, in a structured way) into one schema that should work. And this would work with generic JSON Schema validators.
from specs.
Cool. To complete this thought, there could be a nice validation process:
- A CityJSON file must provide references to all extension "schemas" (structured, JSON-based) used in the file
(very much like the current"extensions"
property) - Using these references, a parser can create an integrated JSON schema
(by using own code, a lib/software or - what I like most - by calling a web service) - Using this schema, a parser can validate the file
(again by using own code, a default JSON validation lib/software or some online tool)
Sounds pretty flexible and strong.
from specs.
I love the idea of having a script that merges all schemas to validate everything at once.
Now, getting back to the original topic, I think having a single point of entry to get all extension attributes is much better than having to iterate through all the children of a City Object.
That being said, in most cases I'd honestly prefer to just have extension attributes inside "attributes". A simple best practice of prepending them with the extension name could solve clashes (i.e. "noise-level", "energy-level"). This fits better with the CityJSON philosophy IMHO and would ensure that software supports many extensions automatically.
from specs.
Well, the current CityJSON 0.8 extension specification explicitly discourages putting extension attributes inside "attributes"
but recommends to document them in their own JSON schema by defining a new City Object. In the Noise ADE mapping example, a "+NoiseBuilding"
is created for this purpose, but the extension attributes still go into a new "noise-attributes"
container instead of "attributes"
. I think this is overly complex if you just want to add some attributes to a "Building"
, and I do not see how this would enable CityJSON software to automatically handle extension attributes.
I do agree though that putting all extension attributes inside "attributes"
is a valid alternative to my proposal. And I also acknowledge that having long attribute names is a JSON way to at least reduce the probability of name clashes. So, I also like this proposal. I think the CityJSON specification should then state that any (simple or complex) extension attribute should go inside "attributes"
, no matter whether you deal with predefined or newly defined City Objects. This would enable CityJSON software to handle extension attributes automatically. It still might be beneficial to require the name of an extension attribute to start with a "+".
I think independent of whether using "attributes"
or "extension-attributes"
it should be possible to define extension attributes in a way that would allow creating a single JSON schema for validation.
from specs.
Oh and I forgot: stitching the schemas together is doable, but takes more time than I had thought... so not available yet, I'll do this at some point.
cjio validate is being updated, so the branch 'develop' works (beta version...) for the v09 schemas and extensions.
from specs.
all, great work, thanks.
from specs.
One question while reading the draft specification: In the first attribute example, color
does not start with a +
. Is this by intention? Is a +
only required if the attribute is defined in an extension schema?
{
"type": "Building",
"attributes": {
"storeysAboveGround": 2,
"colour": "red"
},
"geometry": [...]
}
from specs.
I want to allow new attributes because JSON makes it easy. This attribute can be whatever you want. Not an error, but you'll get a warning (implementation to follow soon).
Only if you want to document in a schema an attribute, then do you have to put the "+".
from specs.
Thanks, understood. And +1 from me.
from specs.
Related Issues (20)
- How deep is the City Object family of 2nd-level objects? HOT 1
- Building "address" is a JSON object but Metadata "address" is string. HOT 7
- Missing name member in texture objects HOT 2
- Where to put semantics/materials/textures for Geometry Templates? HOT 1
- are "vertices-texture" restricted to [0, 1]? HOT 3
- Normals orientation HOT 1
- Are there any possibility or plans to support curved surfaces and lines? NURBS/bsplines, subdivisions or whatelse? HOT 1
- Missing Example for the ways of storing CityJSON Object properties in JSON Lines text HOT 2
- should "appearance" be inside a CityJSONFeature or in the "first line" (global)? HOT 16
- 2.2 and 2.12 miss info about which Objects must have parents
- Can a CityJSONFeature be of a 2nd-level type? HOT 4
- Which City Objects can be parents? HOT 1
- cityjson -> dotbim conversion
- support for compound-CRS?
- CityJSON 1.1 datasets using the "Generic" extension are broken HOT 2
- Add "+GenericSurface" to the Generic extension HOT 1
- Restrict the schemas to valid values HOT 7
- Require at least one item in the boundaries array HOT 1
- Is an empty boundaries array allowed? HOT 1
- add `"additionalProperties": true` for "metadata"? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from specs.