Maja4 dev patch 1 Sample Geodata ToR

[Maja4Dev]

These are the new Sample ToR for KfW Project location data collection and management which KfW counterparts need to amend and complete and then to forward to their project's Project Executing Agency (PEA) and / or their Implementation Consultant for data collection and updating.

[goergen95]

Hi @Maja4Dev,

thanks for opening the PR. There are three main points I am still uncomfortable with these ToR.

• The provision of the ToR are a burden to technical adapt partners. For partners with elaborated GIS systems there are better formats/procedures for the exchange of geospatial information. I would be against KfW making it mandatory for them to deliver their data in sub-optimal and proprietary data formats.

• Currently there is the lack of a clear process how the governance of future changes to the specification looks like. This is very much required if KfW wants to make it legally binding for partners to adhere to the specifiation. Then, partners need to know which version is the legally binding one, how changes are being handled on what that means for them during the lifetime of a project.

• KfW needs tooling to check if incoming data adheres to the standard. As long as KfW does not have such tooling it is really hard for anyone to assess the integrity of the data. Ideally, such tooling should be developed openly (e.g. in this repo) so that technical adapt partners can use the tools too to check their data before sending it to KfW.

Happy to further discuss this during a dedicated meeting.

[Maja4Dev]

Hi @goergen95 : The ToR are necessary for our KfW colleagues to be able to request the data collection from their implementing partners - regardless which data collection template will be used.

Without ToR, no data will be collected for KfW.

The filling out of the sample ToR (yellow-highlighted text) allows KfW staff to enter project-specific information which the data collector may need to have - such as the DAC-codes of the project, a.o.

Once we have better formats for data collection, we can easily add or replace them in the sample ToR. But there will be for many years still be some data collectors that will need the excel template.

Regarding the clear process how the governance of future changes to the specification looks like: from my perspective the (latest ) template published here in Github is the currently valid one. If we have more that one format (e.g. Excel and Kobo Toolbox and / or languages - they should all present an identical data model). Which other specifications do you need? Do you want to make a proposition?
There should be definitely tooling to check if incoming data adheres to the standard. It would be great if this could be published here in Github, please discuss with @Jo-Schie .

[Maja4Dev]

Hi @fretchen, happy to implement your recommendations, but need your help 😅.

[fretchen]

So I have a few propositions.

• The discussion on the process is moved into #23
• The discussion on a streamlined data format can be found in #24
• I am not sure if the clear tooling needs an extra issue or if this is part of the other open PRs and issues @goergen95 ?

@Maja4Dev

• I created a PR to implement most of the suggested changes here.
• However, I also think that we still need to sit together to fix some layout problems...