Nepal VDCs boundaries import
Goals
The goal is to import the boundaries of the 4,049 Village Development Commitees of Nepal (VDC's) from the World Bank database, and to conflate them with the roughly 10% of VDC's boundaries already in OSM (see this Nepal boundaries in OSM hackpad for background on Nepal boundaries and the current state of the Nepal administrative boundaries in OSM).
On top of this import, we will add the United Nations Office for Humanitarian Affairs (OCHA) pcodes for each boundary.
Schedule
- Preparation, discussion - Starting 15th of May 2014
- Import - expected to start as soon as issues and questions are cleared.
Import Data
Data description
The data is divided into 5 shapefiles: one for the country boundary (admin_level=2), one for the 5 development regions (admin_level=4), another one for the 14 zones (admin_level=5), another for the 75 districts (admin_level=6) and the last one for the VDC's (admin_level=8).
We are interested only in the last two files. The district file contains the name and id of the district, and also the names and id's of the zone, region and country it is enclosed. The VDC's file has also the names and ids of each VDC.
We also have the OCHA pcodes in an excel file. Those pcodes (and also the OCHA old codes) will be added to the VDC's relations using a script that matches each of the boundaries.
Background
ODbL Compliance verified: YES
License is CC-by 3.0. This issue was already clarified back in August 2013. Please see: [1]
Import Type
The import will be split by districts, so it will be done in 75 changesets, one for each district. It will be a manual import. For each district we will produce an osm file with only the VDC's inner boundaries and admin_level=8 correcponding relations, that will be joined manually to the existing district/zones/regions/international borders, and conflated with that 10% of VDC's existing boundaries in OSM. Only 11 out of the 75 districts have all or part of their inner VDC's already in OSM.
Data Preparation
Data Reduction & Simplification
The data will be reduced only to the keys listed further down.
Tagging Plans
Include all segments of the boundary of the VDC as role=outer in a relation of type=boundary:
| OSM tag |
|---|
| admin_level=8. Segments that belong to districts, zones, regions or international borders are already in OSM, and they have their own admin_level=*. |
| boundary=administrative |
| source=Fortius One Inc. |
The relations will have the following tags:
| OSM tag | Remarks |
|---|---|
| type=boundary | |
| boundary=administrative | |
| admin_level=8 | |
| name=* | |
| alt_name=* | Only when we have two different names |
| unocha:pcode=* | |
| unocha:old_code=* | |
| source=Fortius One Inc. |
Original data fields tagging translation
| Key | OSM tag |
|---|---|
| ENGTYPE_X, with X= 3 or 4 | Not relevant |
| ID_X, with X=0, 1, 2 or 3 | Not relevant |
| NAME_X, with X= 0, 1, 2 or 3 | Not relevant |
| NAME_4 | name=* |
| ISO | Not relevant |
| TYPE_X, with X= 3 or 4 | Not relevant |
Changeset Tags
We will use the following changeset tags.
Data Transformation
Data is in 5 shapefiles as commented. We opened the districts and VDC's shapefiles in JOSM with the OpenData plugin, merge them and saved the resulting file as osm.
Then we produce 75 different osm files (one for each district) from that file, simply using the JOSM filters.
Next, we run a script to retag and convert those files in standard relations-based osm files, one for each district, including the pcode for each relation.
For each of those files, we just delete the district boundaries and the district relation, so we have 75 ready to manually conflate and upload VDC's only files.
In general, we will respect the region, zone and district boundaries already in OSM, unless there is a good reason to do otherwise. We won't change the international borders shapes.
Data Merge Workflow
Team Approach
Import will be undertaken by only 1-2 (or 3 at the most) mappers with very good experience in importing boundaries, with an import specific account for each one.
References
The import will be discussed in the Nepal OSM community and Imports lists.
Workflow
Already explained.
Reverse plan
In case of any trouble, JOSM reverter will be used.
Conflation
Already explained. It will be done manually, as the rest of the import.