Add files via upload

Author: jb5513

model/model-docs/src/SUMMARY.md

@@ -0,0 +1,18 @@
+# Summary
+
+- [Quick Start Guide](./quickstart.md)
+- [Introduction](./introduction.md)
+- [Data Collection Guidelines](./collection.md)
+- [Validation Process](./validation.md)
+- [Frequently Asked Questions](./faqs.md)
+- [Disclaimer](./disclaimer.md)
+  
+## Annex 1
+- [Excel Templates](./annex1.md)
+
+## Annex 2
+- [Project Core Schema (EN)](./schemas/project_core_schema_en.md)
+- [Project Core Schema (FR)](./schemas/project_core_schema_fr.md)
+- [Feature Project Schema](./schemas/feature_project_schema.md)
+
+

model/model-docs/src/annex1.md

@@ -0,0 +1,3 @@
+# Annex 1: a.	Excel template for location-specific data collection
+
+[English version](https://raw.githubusercontent.com/openkfw/open-geodata-model/main/Project_Location_Data_Template_EN_V03.xlsx)

model/model-docs/src/annex2.md

@@ -0,0 +1 @@
+# Annex 2: JSON Template and Description of the Data Model

model/model-docs/src/chapter_1.md

@@ -0,0 +1,2 @@
+# Project Location Validator
+Access to our Project Location Validator: <a href="project-location-validator/index.html" target="_blank">project-location-validator</a>

model/model-docs/src/collection.md

@@ -0,0 +1,58 @@
+# Collecting Project Locations data
+
+## What kind of data is collected? 
+*A Project location is defined as a set of one or more spatial features that are part of a financially supported activity, where it is not feasible to make any further geographical distinctions regarding funding.* 
+
+The responsible party gathers all project locations and associated information, which has received financial support, within the context of a specific cooperation project. Project locations are generally collected on the **output level**. Additionally, if geospatial data contributes to the measurement of project outcomes and impacts, then location data for potential outcome sites should also be collected. 
+
+Examples: 
+
+1. A project financially supports the construction of a hospital. The hospital is built at a specific location. It is represented as a single feature (point), which indicates the spatial location of the hospital (=output). Project outcomes are measured using non-geospatial data (e.g. patient statistics), hence no additional project locations information needs to be collected. 
+
+2. A project financially supports the construction of irrigation infrastructure that benefits a group of small-scale farmers. The irrigation infrastructure (=output) is composed of multiple features (e.g. weirs and watercourses) that are mapped as a collection of features (i.e. multiple points). Furthermore, remote sensing data is consulted to measure project outcomes (e.g. by quantifying changes in agricultural productivity). In this case, geospatial information on outcome areas (i.e. the irrigated fields that make use of and benefit from the irrigation infrastructure) should also be submitted.
+
+## Initial data collection and frequency of updates
+KfW strongly encourages the PEA or consultant to collect geo-coordinates **as early as possible** to increase the utilization potential of such data throughout the entire project cycle. If possible, data should be collected already during the project preparation phase, e.g. as part of a feasibility study. Data can be updated later if a project location site changes. Data updates should be ideally performed on an annual basis with the preparation of progress reports, if not otherwise specified. 
+
+## Geographical accuracy, geometry, and aggregation 
+The IATI standard describes a project location as **exact** or **approximate**. Exact locations refer to the geographical endpoints of financial flows and are reported with precise coordinates. All exact coordinates in Excel must be collected using WGS 84 (EPSG 4326) as the coordinate reference system, which is the standard for web mapping applications. Coordinates ("Latitude" and "Longitude" columns) have to be provided in decimal format with an accuracy of at least 5 digits after the separator (i.e. 00.00000).
+
+It is advised to report an **approximate** project location, if the location of project implementation is a target area defined by an administrative unit, or if the exact location of the project implementation site is (yet) unknown or if it should be anonymized (e.g. for security reasons). Also in these two latter cases, the respective administrative unit (at an appropriate level) where the project is implemented should be used instead. More explanations on when to use approximate locations are given in the FAQs.
+
+Project locations can be represented by three **types of geometry**:
+- **points**, e.g. a well or a hospital
+- **lines**, e.g. a road or transmission line
+- **polygons**, e.g. a protected area, agricultural plot, or administrative unit
+
+Additionally, different levels of detail may be used to represent this information. A road can be further segmented, where each sub-section represents different measures that have been financed, respectively. Furthermore, locations may be **aggregated** in a polygon that represents an intervention area or administrative unit. This might be useful for cases where there are a large number of sites that are part of the same project, and also if precise locations are unknown or if they should not be revealed due to privacy or security reasons. 
+
+While there are no strict rules governing the choice of geometry type and aggregation level for data collection, the following principles should be applied by the responsible party: 
+- *Maximize transparency and precision* of financial flows
+- Allow for *precise and unambigous spatial identification and delination* of project locations and different supported activities
+- *Preserve data privacy:* data should not be collected on an aggregation level where it contains personal information or could lead to the identification of individuals
+- *Avoid security risks*: data should not be collected on an aggregation level that might expose or endanger vulnerable groups, such as refugees or minorities that might face discrimination
+- Follow a reasonable *cost-benefit ratio* for collecting and producing the required information
+
+In case you are unsure, please get in touch with your project partner to discuss the necessary details. 
+
+## Collection of point-locations
+
+For the collection of point-loctions, we currently accept submissions in **.XLSX** and **.GeoJSON** formats.   
+
+### Using Excel for point-locations
+ 
+ The **.XLSX** format is best suited, if your institution does not know how to handle geospatial data and has no former experience with Geographic Information System (GIS) software. In this case you can use the most recent version of our [Excel templates](./annex1.md) to collect all relevant information.
+
+## Collection of point-, line-, and polygon-locations using GIS software
+For the collection of point-locations, the use of **.GeoJSON** is optional but recommended for its reliability and flexibility. For the collection of line- or polygon-locations, only **.GeoJSON** format is accepted.
+
+We highlight two common cases for generating the required data: 
+
+ 1. **Desktop-production**: For manual data collection, we recommend using the [Excel templates](./annex1.md) to store all attributes and merging this information with spatial information (feature geometries) in a GIS software. Since the Excel templates are pre-configured, it is easier to provide data that is compliant with our data-model and pass the validation check as a way to ensure data quality. A short video tutorial (to be released soon) will demonstrate how to use the Excel template with QGIS software.
+
+ 2. **Database-extraction**: If location information is available in a geospatial database, it is possible to extract and transform the data into field-mappings that also match our requirements. In these cases, the data-model can be provided as a [JSON schema](./annex2.md). This supports batch conversions as a starting point; any missing information can then be manually added.
+
+
+If GeoJSON format is used, multi-point, -line or -polygon features can also be submitted to reduce data redundancies. This can be useful if the same project activity benefits multiple sites (e.g. all irrigated fields that benefit from an irrigation infrastructure). You can also use multi geometry feature collections if your submitted data contains different geometry formats. 
+
+

model/model-docs/src/custom.css

@@ -0,0 +1,21 @@
+/* Source - https://stackoverflow.com/a
+ Posted by Sandman, modified by community. See post 'Timeline' for change history
+ Retrieved 2025-11-18, License - CC BY-SA 4.0
+ https://stackoverflow.com/questions/73555768/how-to-change-width-of-content-area-in-mdbook
+*/
+
+:root {
+    --content-max-width: max(750px, 90%);
+}
+.schema-docs {
+    border: 1px solid #ddd;
+    border-radius: 4px;
+    padding: 1em;
+    margin: 1em 0;
+}
+
+.schema-title {
+    color: #2c5e8a;
+    border-bottom: 2px solid #2c5e8a;
+    padding-bottom: 0.5em;
+}

model/model-docs/src/disclaimer.md

@@ -0,0 +1,12 @@
+# Disclaimer
+
+This data model and the respective guidelines and tools were developed by and for practitioners preparing and implementing International Aid and Development Cooperation projects and to provide them with assistance and examples of how to collect, validate, manage, and maintain project locations on-site or remotely.
+The content in this repository was carefully drafted by [MAPME Community of Practice](https://www.mapme-initiative.org/) members, their partners, advisers and other related experts by reflecting the extensive experience gained in such projects. The material and information provided here are however general in nature. They does not constitute any form of legal, technical, or other advice and therefore does not purport to replace such legal, technical, or other advice for a specific project or question by a user. Any use of the material or information provided in this repository for specific projects is at the user’s own risk.
+Due to the general nature of the data model and guidelines, conclusions drawn from them always need to be adjusted to the specific needs and design of the respective project context. MAPME Community of Practice members can therefore not be held liable for any use and any conclusions drawn from the data model, guidelines and tools. The boundaries, colors, denominations, and other information shown on any map in this work do not imply any judgment on the part of [MAPME Community of Practice](https://www.mapme-initiative.org/) members concerning the legal status of any territory or the endorsement or acceptance of such boundaries.
+MAPME Community of Practice members make no representation and exclude to the fullest extent permitted by applicable law any responsibility or liability for the data model, guidelines and tools, their content, or any errors or omissions made there. The information contained in this repository is provided for information purposes only and on an “as is” basis with no guarantees of completeness, accuracy, usefulness, or timeliness.
+
+# Main authors, contributors & publishers:
+
+[MAPME Community of Practice](https://www.mapme-initiative.org/)
+
+This work is a product of the staff of MAPME Community of Practice members and other expert organizations working in international aid and development. The findings, interpretations, and conclusions expressed in this work do not necessarily reflect the views of all members, expert organizations, theirs Board of Executive Directors, or the governments they represent. The authors do not guarantee the accuracy of the data included in this work.

model/model-docs/src/faqs.md

@@ -0,0 +1,38 @@
+# FAQs
+
+## What is a location type?
+
+While the Data Model template closely follows IATI standards, additional location types have been created to cover the full range of financial cooperation projects. Location types provide a brief description about the function of the Project Location. 
+
+Our extended list includes IATI location types that are useful for international development, as well as additional types relevant to all sectors. 197 new project location types have been created. These include for example, Capacity Development/Training or Voucher Schemes, which cannot be plotted based on any physical features on a map, but can be defined by underlying areas in which these types of projects operate. By extension, location types can be defined as project output- or intervention-related types of physical locations or areas. Please refer to the list of location types in the Excel template or in the json model for more information.
+
+If a specific location type has not yet been added, please use the most similar available type (e.g. "well" for "extraction well"). Additional information can then be added if necessary. 
+
+## Why collect information on Project Locations?
+
+The German Financial Cooperation uses Project Locations to report on the relevance, progress, and impacts of our project portfolios. We create maps of the portfolios of Project Locations for the German Federal Ministry for Economic Cooperation and Development [BMZ](https://www.bmz.de/de) and for our internal and external stakeholders. The data is used to assess portfolios for social, environmental or climate-related risks. 
+
+## When should Project Locations information be collected?
+
+KfW strongly encourages PEA or consultant staff to collect geo-coordinates as early as possible, to optimize the potential utility of such data throughout the entire project cycle. Ideally, data should already be collected during the project preparation phase, e.g. as part of a feasibility study.
+
+If exact locations cannot be determined at this stage, approximate location should be used (see below) and rechecked later during project appraisal and inception stages, where it may be possible to update approximate to exact locations. During project implementation, data should be updated at least once annually in project progress reviews. This ensures that any potential changes are reflected in the geographical allocation of funds, which are common in Financial Cooperation projects.
+
+## Are Project Locations confidential?
+
+The Excel template must be submitted without containing any personal data or any data that could be linked to individual persons, such as houses of private households. Exact coordinates of Project Locations remain confidential and are not published publicly by KfW. 
+
+Location data in fragile and conflict contexts are treated with extra diligence. If an exact Project Location is not to be collected or communicated due to security reasons, select the option "approximate (security)" in the "Geographic Exactness" column. Furthermore, by indicating "yes" in the column "Publishing restrictions due to security reasons" associated to a Project Location, it will be omitted from publicly available reports.
+
+## How was the model developed with respect to IATI standards?
+The Project Locations Model is mostly based on a proposal by the International Aid Transparency Initiative (IATI) to collect project specific geo-information, which is used by international development organizations. It harmonizes and coordinates development projects across multiple donor agencies. 
+
+This standard was further developed in this context to address our operational needs. In particular, the Project Location Model mostly uses predefined categories under the International Aid Transparency Initiative (IATI) standard. Furthermore, built-in selection methods support clean data entry in Excel. The existing IATI list of location types has been expanded to cover all physical and immaterial location types required by international development cooperation standards.
+
+## What are approximate locations and how can they be used?
+Approximate locations should be used if onf of the following circumstances apply: 
+1. An exact project location has not (yet) been specified or is not yet known (e.g., the exact project locations have not yet been determined) -> then choose the option: approximate (yet unknown).
+2. An exact project location is not to be collected or communicated due to security reasons (e.g., in a conflict zone) -> then choose the option: approximate (security).
+3. The target location(s) is/are one or more administrative units, such as a district, a province, or the entire country or group of countries (e.g., an entire country for a Policy-Based-Lending project or a number of districts in a country for a decentralization project) -> then choose the option: approximate (admin unit).
+
+

model/model-docs/src/introduction.md

@@ -0,0 +1,19 @@
+# Introduction
+
+## KfW’s Project Location data collection and management approach
+
+This section describes how Project Locations data should be collected, including information on technical requirements and expected formats; this guidance is intended for KfW staff, Project Executing Agencies (PEAs), consultants, and other external stakeholders responsible for data collection.
+
+
+## What is a Project Location?
+
+A Project Location is a set of one or more features that are part of a financially supported activity, where it is not feasible to make any further geographical distinctions with regards to funding. For instance, a financially supported hospital at a specific location is an example of a single-feature Project Location. Another example of a multi-feature Project Location is a group of adjacent agricultural plots that are being financed under an irrigation plan that benefits all producers in that area. A set of protected areas that are jointly financed from a single source of funding is another example of a multi-feature Project Location. However, if funding allocation can be further distinguished by smaller geographic areas, data across multiple Project Locations and the respective financial allocations must be collected. KfW strongly encourages capturing the geographical discrimination of financial flows to specific project locations where possible, which contributes to transparency and financial accountability.
+
+
+## Project Locations Model 
+
+The Project Location Model is a structured data model, developed by the KfW Development Bank, to collect location-specific information about projects supported by international development cooperation. The model is in use and continues to be developed by KfW, together with their peers and partners. 
+
+The model, in Excel format, is currently available for download in English and French, see also [Excel Templates](./annex1.md). The model can be used in combination with a Geojson file. 
+
+Data related to specific project locations should be collected with respect to the outlined requirements. Please see FAQ for more information about the International Aid Transparency Initiative (IATI) standards and enhancements particular to KfW's operational needs.