Further resources and geonode documents

[pgiraud]

The "further resources" should be the result of the harvesting of documents from the geonode.

[pgiraud]

@stufraser1 wrote on the mailing list:

Andy has put 20 reports so far on the geonode and will continue to work on loading more. These are listed at http://45.55.174.20/documents/ and metadata at http://45.55.174.20/api/documents/

Many reports contain information pertaining to multiple hazards, and should be displayed in the UI for multiple hazards. In these cases, and because "hazard_type" field only accommodates one hazard type, "supplemental_information" field is used to complete the list, as a comma-separated list.

e.g., http://45.55.174.20/documents/359/metadata

Is this use of two fields acceptable to CampToCamp as a way of listing multiple hazard types? Or would it be preferred that we list all of the relevant hazards in supplemental information so you can pull from one field only?

Should we ensure that the list is preceded by some common text and ends with a certain character to limit the text being pulled by Think Hazard, in case we need to populate the "supplemental_information" field with additional information later down the line?

[fvanderbiest]

Ideally, GeoNode should allow a resource to have several hazard_types, eg :

hazard_types: [
  "earthquake",
  "drought"
],

But I understand this would break the API.

So, yes, technically, we could rely on the supplemental_information field. No need for a special syntax. If the supplemental_information field says "No information provided", then we'll use the primary hazard_type.

[fvanderbiest]

So, we need to map:

• GeoNode's document id to THOR's FurtherResource geonode_id
• GeoNode's document title, eg "Natural disasters in Middle East and North Africa: A regional overview" to THOR's FurtherResource own title
• GeoNode's document URL, eg http://45.55.174.20/documents/434 to THOR's FurtherResource own url field.

Everyone's OK with this ?

[fvanderbiest]

GeoNode's document URL, eg http://45.55.174.20/documents/434 to THOR's FurtherResource own url field

Or directly the download link ? eg: http://45.55.174.20/documents/434/download

[ingenieroariel]

This sounds good to me.

[fvanderbiest]

The "further resources" should be the result of the harvesting of documents from the geonode.

Should all further resources be the result of geonode documents harvesting ? Or just or fraction of them ?

This impacts https://github.com/GFDRR/thinkhazard/blob/master/thinkhazard/scripts/import_further_resources.py#L71-L182

[fvanderbiest]

@pgiraud says every FurtherResource should be harvested from GeoNode

[stufraser1]

Yes, every further resource should be included. There are now 100 on the geonode. Most have hazard_type assigned as the first related hazard, but since that only allows one hazard to be included, we've had to include the remaining relevant hazards in supplemental information. All hazards listed should be taken into account when linking to ThinkHazard! pages. Reports that are primarily related to climate change do not have a hazard type, as this is not currently an option in geonode (so hazard_type is empty). If this field must be populated, we can arrange to include cliamte change in a hazard_type field.

Most have no distribution_url associated as yet (this wil be updated as soon as possible) but users should be able to click on the resource name to access the distribution_url.

[fvanderbiest]

Most have hazard_type assigned as the first related hazard, but since that only allows one hazard to be included, we've had to include the remaining relevant hazards in supplemental information. All hazards listed should be taken into account when linking to ThinkHazard! pages.

OK, this is done in https://github.com/GFDRR/thinkhazard/pull/407

Reports that are primarily related to climate change do not have a hazard type, as this is not currently an option in geonode (so hazard_type is empty). If this field must be populated, we can arrange to include cliamte change in a hazard_type field.

To be handled in a different issue: https://github.com/GFDRR/thinkhazard/issues/408

Most have no distribution_url associated as yet (this wil be updated as soon as possible) but users should be able to click on the resource name to access the distribution_url.

OK, for now, we link to /documents/{id}/download. Please tell us when the distribution_url field has been bulk-updated.

[fvanderbiest]

Note that, for now, we did not take into account the link with regions, because most of the links between documents and regions where empty in GeoNode. ... but this creates huge lists of documents in every report page. So I guess we'll have to handle them as well pretty soon.

Let's take this document http://45.55.174.20/api/documents/449/ as an example. It links to http://45.55.174.20/api/regions/109/ (Haiti)

We'll have to find a way to relate our regions (from the GAUL dataset) with those from GeoNode. @ingenieroariel : do they have an id in common ?

[ingenieroariel]

François, those regions come from the ISO 19915 standard, I believe they go to the country level, so a lookup table would have less than 200 entries.

[fvanderbiest]

Let's go for a countries lookup table: https://github.com/GFDRR/thinkhazard/issues/409

[pgiraud]

Done.