Add your QA plan here. Import Plan Ugandan Districts and Sub-region Outline
- 1 Goals
- 2 Schedule
- 3 Import Data
- 4 Data Preparation
- 5 Data Merge Workflow
- Preparation, discussion - January 2014
- Import expected to start- February 2014
The datasets are shapefiles defining Uganda administrative level 2 and 3 boundaries. They are called districts and sub-regions respectively. The districts datasets contains 112 polygons(districts) and contains the following keys: D_06_ID, DNAME_2006, AREA, PERIMETER, HECTARES, DNAME_2010, SUBREGION, COUNTRY while the sub-regions dataset contains 11 polygons with the following keys: AREA, PERIMETER, HECTARES, SUB_REGION, COUNTRY.
UBOS is the principal data collecting, processing, analysing and disseminating agency responsible for coordinating and supervising the National Statistical System.
Link to permission (if required): Awaiting discussion from mailing list- 
ODbL Compliance verified: Awaiting verification from import mailing list.
Hopefully it will be a one time thing, as long as the disticts are not re-drawn.We will be using JOSM to import it.
How do we handle the update process incase the district boundaries are re-drawn?
JOSM reverter will be used to reverse the upload, the re-drawn boundaries will then be re-imported to OSM.
Data Reduction & Simplification
Data will be reduced to the keys listed below. We shall then generate the .osm file from the simplified shapefile. We'll use shp2osm script to create an OSM file then upload with JOSM.
|district||place=city, name=*, boundary=administrative, admin_level=*|
|id||not tagged because it's not relevant|
Uganda is divided into 11 regions. We need a single .osm file of regions and districts.
We shall merge the district shapefile above with a regions shapefile. The two shapefiles have different projections so we have reprojected them to the same(WGS 84) to avoid datum transformation errors. For this we use the MM QGIS plugin. The rest of the keys(D_06_ID, DNAME_2006, AREA, PERIMETER, HECTARES,SUBREGION,COUNTRY) will be deleted from the shapefile. The remaining keys, DNAME_2010, SUB_REGION and D_06_ID will be renamed to district, region and id. We shall then save this new district shapefile. The table manager plugin in QGIS will be used. A .osm file is then generated from the merged shapefile. The resulting .osm file can be viewed here 
Result in JOSM:
- The .osm file, when viewed in JOSM renders with all the districts but the data reveals otherwise, for example there are 7 relations instead of the expected 112 relations(districts)-this does not seem to be the ideal result.
- Some of the districts in this OSM file are just regular ways and not relations.
Pointers on how to generate a .osm file who's data view has all relations. (A wiki browse, doesn't show any documentation on this)
The outer district boundaries are national boundaries, we will manually delete them from Josm/.osm and after import manually join the district boundaries with the national boundaries then add the national boundary to the district relations.
According to the email@example.com list response:
- The casing of the districts has to be converted to match OSM's lowercase style of naming things.
- The source shapefile has geometrical errors like self crossing ways, suspicious small enclave...
- The merged shapefile can be manually converted with the tools JOSM provides(open the shapefile using the opendata plugin), though the downside here is the slow progres.
- In the shapefile, most of the districts consist of overlapping ways, these need to be split and converted to type=boundary relations.
- Proposal for a specialised script that does the translation.
This script [] transforms the merged shapefile to an osm file with 124 relations(which is the expected file). The downside at this point is:
- the osm national boundary and generated osm file(from the merged shapefile) boundary are not in sync.
There are three ways of dealing with this:
- Go through the entire length of the national boundary and compare the two layers, merge and join where necessary.
- Or, start from the centre of the layer and work outwards, since there are no boundaries to merge.
- Then we'd have to be careful with the upload ensuring that only the verified boundaries get uploaded(by making a selection of these).
Data Merge Workflow
The import will be discussed in the import list. See 
Please refer to the workflow page.(To be set-up)
In case of any trouble, JOSM reverter will be used.
We have 2 options here:
- Add the 13 UBOS regions as subs of the 5 historical regions.
Though for the Uganda context, having the 13 sub-regions is administratively more logical.