Networking impediments and opportunities
From Earth Science Information Partners (ESIP)
< Back to 
| Workshops | Air Quality Data Network
JJ Bogardi, Global Water System Project (GWSP) at EGIDA, Bonn:
Nature of Networking Projects: Complex funding; mixture of paid and voluntary; multiple obligations; international; differing project maturity; governance, cultures
Which glue keeps it together? Trust and personal affinity. Common objectives and scientific values. Mutual respect. Mutual benefit (win-win). Complementarity. Donor dictate
Lethal“ ingredients. Turf mentality. Budget discrepancies. Too much competition. Lack of data and information exchange. Donor jealousy
- Clear statements about obstacles: no clear structure; no dedicated funding and no clear idea(s) yet how to do it.
- Opportunities, fixes: ID manageable work packages; Find, organize, distribute reusable components, resources; Create win-win situation
Impediment Slide
- Differing requirements, agendas, goals, timelines
- Need to plan in advance, adding requirements/needs mid-course
- DLR - WCS version; NASA wants 1.0, community WCS uses 1.1.x
- NILU - service interface must support "point observation view"
- STI - commitment to adopt community server; need help on technical level
- EEA - wants to add WCS service but needs to determine how to do this (e.g. decide which standard(s) to support)
- CNR comment - INSPIRE can add stability to standards
- NG - community definition of metadata, in particular for client development; how can INSPIRE etc. help us?
- JRC - no impediments, all ready to go
- Mismatched funding / mismatched development cycles
- NILU - must answer immediate needs; this drives development efforts
- Open source community efforts versus off-the-shelf software
- Difficult to keep open source software going over the years
- Require resources staff/$
- DLR - limited resources - limit development efforts, not unwilling to install and run community server
- NILU - limited funding, but maybe not impossible
- STI - limited funding, need to prioritize
- Is it reliable?
- Don't trust open source
- STI and EEA - must be certain that system survives ~10 years, not only on technical level but as a community
- Unidata - backward compatibility is part of netcdf philosophy, not so in WCS (example multi-part mime wrapper); CF has slow development cycle on purpose, largely backward compatible although newer versions resolve ambiguities and therefore may break old code
- Unclear expectations/requirements of the community
- Need for clear, simple documentation/instructions
- Group needs to add feedback/experience to documentation
- Responsibility to maintain structure
- STI - communication tools, repository+version control are critical elements
- Changing/evolving standards and approach - Interoperability burnout
- Too many new things - how to know where to focus?
- Governance needs - limited resources, growing needs
- STI - structured community software development would probably work
- Support vs. documentation vs. development
- Organisation of community software development: formal vs. informal; need for some sort of steering group with a mandate to take decisions
- Unidata - started as small grant to look at needs
- Challenges of real-time systems
- Modifications needed to be made to the software for data coming in frequently
- performance
- STI - must persuade users to go through services rather than data downloads
- Insufficient user feedback/ user involvement
- Agreement on protocols (i.e. WCS x.y, W*S) vs. payload (i.e. adopt new netcdf-cf standard as community standard)
