kartoza / gfdrr_oondra

GFDRR Challenge Online Operational Natural Disaster Risk Assessment platform
0 stars 3 forks source link

Metadata Search #27

Closed lucernae closed 7 years ago

lucernae commented 8 years ago

Taken from discussion with @gubuntu :

  1. yes please implement interaction with both geonode API and CSW. Tim suggested you do geonode API first but you've already proceeded with CSW as well. Client should figure out if target is geonode and if so use its API as an 'extra'. But default must be csw since all metadata clearinghouses use that standard. If you use both then how to present results? Two separate sections or somehow merge them? Does geonode api have download endpoints? Can you get inasafe keywords through geonode api?
  2. A metadata record returned by CSW will have inasafe keywords in the supplemental information field
  3. A metadata record returned by CSW will have WCS or WFS endpoint url. Use that to request raster or vector in desired format.
  4. For this project the target instance will only be our oondra geonode instance. Future clients will not be limited to inasafe so it does not have anything specific to inasafe except for the inasafe keywords in the supplemental information field, which this project (Admire) will curate.
  5. The UI does not have to be called MetaSearch. It should be presented as an alternative option for the user to find exposure or hazard layers -> then present a list of available layers that intersect the user's area of interest. User should be able to find out as much as possible about the layer before choosing it (quickview, other metadata fields, inasafe keywords, etc.) - then when the user chooses to download a layer it should fetch the layer ideally clipped to the aoi.
gubuntu commented 7 years ago

@lucernae is busy with this

gubuntu commented 7 years ago

@lucernae please comment and complete or close

gubuntu commented 7 years ago

This issue was moved to kartoza/geosafe#133