-
Notifications
You must be signed in to change notification settings - Fork 1
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
Data Package Support #2
Comments
I am not that sure that it would require extending the data package specification. |
Yes but how to decide if an exposure resource is put into the folder population or buildings if there is no additional categorisation property at the level of the data resource and the Data Package contains several Exposure resources (identified by data_resource/analysis_context/resource_type) that belong to several logical categories? |
Indeed, we need a 'category' property with possible values: population, buildings, etc.... The more I think about all these specific parameters, the more I am convinced that we should have a general resource with common attributes and the specialized resources (for BackgroundLayer, Exposure, Impact, etc.) with their specific properties, like the category for the Exposure and Impact analysis. I need to think a bit about it since this would also introduce other problems, like repeating the same resource for each of the steps in the workflow where it is used. |
We'll try to define a REST View to simplify the extraction of the relevant properties from the study and data package entities. See clarity-h2020/csis#22 (comment) |
@therter
I'm not sure if this nested View approach really works (meaning the JSON result is valid but it might be difficult to parse the result), so please check this and if necessary I will change this last part and return only the link to the Map Component Analysis context display instead of its result. The whole process would then take in total 3 calls instead of just 2, but since you mentioned that this wouldn't be a problem for the map compoment, we could do it that way. |
What's the relation of Rest Views to the JSON:API vs. core's REST Module? We should't mix APIs so we have to make a decision for either JSON:API or REST Module! |
@p-a-s-c-a-l |
@p-a-s-c-a-l @patrickkaleta Do we want to have a API which delivers a big amount of data (from which we maybe need only a small piece) with one call. Or do we want a more talking API where we have to ask for every piece with a separate call? The second case is maybe better if the external services have a lot of logic inside and need different data in different cases. What do you think? |
I'm in favour of the JSON API as I have the impression it will replace the REST API in the long term. While it's true that it's up to the client developer to build some complex query strings (once!), it gives us more flexibility and reduces maintenance effort and complexity at level of the Drupal side (no need to create REST Views for each and every special case). What I don't like is the is the structure of the JSON documents, that's far from being clean and simple. Those aren't the javascript objects you really want to work with at client side. Referring to the example (which is btw rather confusing with its mixture of id, uid and uuid), I want to access So we have to put more effort in the client logic that maps these complex JSON objects into the simple state models of our applications (see point 3 and 4 in this issue). But I don't expect that the JSON you'll get from the REST Views will look much better. |
Basic Data Package Support is available. Now we have to deal with the changes to the DP Specification. |
The Map Component must access the meta-data of the Data Package (Example: Background Layers) of the current Study stored in the CSIS via the JSON API and initialize the LayerControl Component with the respective layers. The LayerControl Component must support grouping of layers into different categories. Relevant properties to define the groups are
This information provided in properties of the Data Package / Data Resource should be enough to build and initial categories tree for the Map Component / Layer Control:
If additional categorisation is needed (example in figure below), the Data Package specification has to be extended.
The text was updated successfully, but these errors were encountered: