phoenix
phoenixPhoenix - Your AI Assistant
Inactive session will be ended in 24 hours
End Session

Research project Groundwater Dashboard

  • Posted:
  • Proposals: 47
  • Remote
  • #4486849
  • Expired
Khalid H.Dhirendra K.Isha S.Angela O.Volodymyr D. + 42 others have already sent a proposal.
  • 7

Description

Experience Level: Expert
The objective of this project is to develop a web application called Groundwater Dashboard Explorer (GWDE). The GWDE is a front-end web application designed to visualise geospatial groundwater data (risks, opportunities, and climate scenarios) for a research project. The codebase must be reusable as a "blueprint" that can easily be forked and customised for other projects.

New Proposal

Login to your account and send a proposal now to get this project.

Log in

Clarification Board Ask a Question

  • Asad C.

    - How do you envision your primary users (policy makers vs researchers vs public) interacting with the dashboard—do they need simplified storytelling or deep analytical controls?

    - How dynamic will the data be, should the dashboard support real-time updates, or will it mostly work with precomputed datasets and scenarios?

  • Jon B.

    Data Size & Structure
    Can you provide more detail on the expected size and structure of the datasets exposed via the API (e.g. typical raster dimensions, number of layers, scenarios, and time steps per indicator)?
    Will the API deliver pre-processed, web-optimised data (e.g. tiles or aggregated values), or will the frontend be expected to handle raw formats such as NetCDF/GeoTIFF directly?
    API Readiness & Stability
    Is the API already fully defined and available for testing, or will it evolve during development?
    Will there be versioning and a stable contract for endpoints, or should the frontend be designed to accommodate ongoing changes?
    Blueprint / Reusability Expectations
    Could you clarify the expected level of reusability for the “blueprint”?
    For example, should the system support configuration-driven reuse (e.g. switching datasets via config), or is code-level reuse (fork and modify) sufficient?
    Data-driven Stories & Content Pages
    Regarding the “data-driven stories” and additional pages, should these be implemented as static content/templates, or is dynamic content management (e.g. CMS-like functionality) expected?
    Performance Expectations
    Are there specific performance targets (e.g. maximum load times, supported dataset sizes, or expected number of concurrent users) that the frontend should meet?
    Scenario Comparison (Split-screen)
    For scenario comparison (e.g. split-screen), should both views be fully synchronised (zoom, layers, time), or is a simpler independent comparison acceptable?
    UI/UX Design Responsibility
    Will UI/UX designs (wireframes or visual direction) be provided, or is the provider expected to lead the full design process, including iteration cycles?
    Definition of Final Deliverables
    Could you clarify the expected level of testing, documentation, and handover required (e.g. developer documentation, onboarding materials, or training sessions)?
    Post-launch Support
    What level of post-launch support and bug fixing is expected within the project budget?
    Existing Codebase Usage
    You mention an existing IIASA dashboard codebase — is reuse or extension of this code encouraged or expected?