Tags vs. eu_gl object

[therter]

@maesbri What are the benefits of the tags against the dp_eu_gl object. Because at the moment we use the dp_eu_gl object at many places and it seems easier to use than the tags.

[maesbri]

The tags property is more general, so we can put there any "tag" we define and makes the specification more flexible for the future. In addition, these tags can be later on used with the references in order to facilitate the association of information (which is not possible with the current structure of the eu-gl object. e.g., "Heat wave hazard event (temperature 28ºC, duration 6 days) in the Metropolitan region of Naples"
We can associate in this resource for instance for each damage-class the corresponding wms service for visualizing it. This was not possible with the other approach.

  "tags": [
    "service-type:emikat",
    "resource-type:hazard-event",
    "eu-gl:vulnerability-analysis",
    "eu-gl:risk-and-impact-assessment",
    "hazard:temperature:heat:heat-wave",
    "hazard:temperature:heat:heat-wave:index:heat-wave-duration",
    "hazard-event:heat-wave-duration:$temperature=28:$duration=6",
    "element-at-risk:population",
    "vulnerability-class:population:age-group<15",
    "vulnerability-class:population:age-group15-65",
    "vulnerability-class:population:age-group>65",
    "damage-class:population:d1",
    "damage-class:population:d2",
    "damage-class:population:d3",
    "damage-class:population:d4",
    "damage-class:population:d5",
    "event-probability:frequent",
    "emissions-scenario:rcp45"
  ],
  "references": [
    ["@mapview:ogc:wms", "damage-class:population:d1", "https://service.emikat.at/geoserver/clarity/wms?service=WMS&version=1.1.0&request=GetMap&layers=clarity:view.2813&styles=DamageLevel1Q&bbox=4650500.0,1942000.0,4713000.0,1995500.0&width=768&height=657&srs=EPSG:3035&format=image/gif&cql_filter=HAZARD_EVENT='HW.6d_28C'"],
    ["@mapview:ogc:wms", "damage-class:population:d2", "https://service.emikat.at/geoserver/clarity/wms?service=WMS&version=1.1.0&request=GetMap&layers=clarity:view.2813&styles=DamageLevel2Q&bbox=4650500.0,1942000.0,4713000.0,1995500.0&width=768&height=657&srs=EPSG:3035&format=image/gif&cql_filter=HAZARD_EVENT='HW.6d_28C'"],
    ["@mapview:ogc:wms", "damage-class:population:d3", "https://service.emikat.at/geoserver/clarity/wms?service=WMS&version=1.1.0&request=GetMap&layers=clarity:view.2813&styles=DamageLevel3Q&bbox=4650500.0,1942000.0,4713000.0,1995500.0&width=768&height=657&srs=EPSG:3035&format=image/gif&cql_filter=HAZARD_EVENT='HW.6d_28C'"],
    ["@mapview:ogc:wms", "damage-class:population:d4", "https://service.emikat.at/geoserver/clarity/wms?service=WMS&version=1.1.0&request=GetMap&layers=clarity:view.2813&styles=DamageLevel4Q&bbox=4650500.0,1942000.0,4713000.0,1995500.0&width=768&height=657&srs=EPSG:3035&format=image/gif&cql_filter=HAZARD_EVENT='HW.6d_28C'"],
    ["@mapview:ogc:wms", "damage-class:population:d5", "https://service.emikat.at/geoserver/clarity/wms?service=WMS&version=1.1.0&request=GetMap&layers=clarity:view.2813&styles=DamageLevel5Q&bbox=4650500.0,1942000.0,4713000.0,1995500.0&width=768&height=657&srs=EPSG:3035&format=image/gif&cql_filter=HAZARD_EVENT='HW.6d_28C'"]
  ]

[maesbri]

A way to cope with the "tags" properties would be to create a small function for each of the possible tag types (i.e., service-type, damage-class, emissions-scenario, etc.) that returns null or an array with matching values that latter on you can use in the part of the code where you were using the "old" property. Therefore, instead of accessing eu_gl.damage_classes properties you just make a call like this: getDamageClasses() (or even more generic: getTags("damage-class")). Implementing this should be quite straight forward since all tags follow this approach tag-type:xxxxxx)

[maesbri]

@therter, @p-a-s-c-a-l I have updated the DataPackage model in drupal according to the latest specification. By updated I mean, added all new properties (I haven't removed anything "old" yet ).

It would be good if you can test using the new properties, specially, the "tags" and "references" ones. For that, I have updated these two resources in the Naples DataPackage:

• agricultural-areas: http://github.com/clarity-h2020/data-package/examples/dc1-naples#r1 (https://csis.myclimateservice.eu/node/217)
• heat-wave-duration_historical_19710101-20001231 --> http://github.com/clarity-h2020/data-package/examples/dc1-naples#r15 (https://csis.myclimateservice.eu/node/293)

If your testing/modifications are ok then I will proceed to modify the other resources and remove the old properties.

[p-a-s-c-a-l]

Ok, I'm trying to implement the changes in the map component first. But this will take some time.

BTW, did you consider the changes to other parts of the CSIS Drupal Implementation? E.g. on the Data Package Views. Because they still use the (deprecated?) [EU-GL Context Type] and not the tags fiels. Since the tags field contains terms from different taxonomies, I don't know if filtering is that easy. Anyway this particular view has to be changed and I don't know if there are any other views that need an update. @DanielRodera @patrickkaleta @fgeyer16 can you please check?

We have to make sure that the system is not left in an incoherent state where some parts still use the (deprecated?) EU-GL Context Type and others the new tags list.

[maesbri]

I didn't remember about that particular view, but indeed, it should be updated accordingly (I did update the Data Package Wizard according to the new specification, by adding the new fields in the form).

These are the changes (I think I didn't forget any):

• ADDED properties (within the dp_resource object):

  • parameters
  • tags
  • references
  • thresholds

• UPDATED Taxonomy DP_ServiceType (with additional service types (e.g., ogc:cws, emikat)

• ADDED Taxonomy DP_ResourceType (so in the tags list we can select the resource type (e.g., hazard-index, hazard-event, etc.)

• (TO BE) REMOVED properties (within the dp_resource object):

  • eu_gl (as most of its properties now are modelled as tags (e.g., service-type:ogc:wfs) or references (e.g., mapview))
  • id (this was introduced at the beginning as a request from @humerh , but actually it is not necessary, as the resource name MUST be also unique and therefore can act as identifier)
  • service_type

• Other objects (TO BE) REMOVED:

  • dp_hazard_event (modelled as a reference to another resource)
  • dp_mapview
  • remove_crs_grid
  • remove_dp_spatial_context
  • remove_trs_context

[patrickkaleta]

Ok, I'm trying to implement the changes in the map component first. But this will take some time.

BTW, did you consider the changes to other parts of the CSIS Drupal Implementation? E.g. on the Data Package Views. Because they still use the (deprecated?) [EU-GL Context Type] and not the tags fiels. Since the tags field contains terms from different taxonomies, I don't know if filtering is that easy. Anyway this particular view has to be changed and I don't know if there are any other views that need an update. @DanielRodera @patrickkaleta @fgeyer16 can you please check?

We have to make sure that the system is not left in an incoherent state where some parts still use the (deprecated?) EU-GL Context Type and others the new tags list.

At least for Views, filtering should still be quite easy (or even easier now since no intermediate step via the EU-GL Context type is necessary anymore), because I can specifically set the taxonomies a field should be filtered by like this (shown for the new tags field):

In the Maintenance overview for Resources I added both, the deprecated Workflow step field and the new tags field. That might help us with the transition to the new tags field. Resources can be filtered by their EU-GL step both ways (via tags and workflow step field).

Regarding the Datapackage views, they have to be adapted now. Since @fgeyer16 implemented those, I think it would be best, if he would do that.

I don't think I'm using the EU-GL context type anywhere in my implementations/Views, but I'll check to make sure.