Import Nigeria eHealth Africa Boundaries (2)
Goals
The goal of this import is to substitute the quite poor boundaries of States and LGA's of the maplibrary database for 26 states of Central and South Nigeria by the boundaries of eHealth Africa into OSM.
The current boundaries for Nigeria in OSM, the ones that origin from MapLibrary, are assessed by the mapping specialists of eHealth Africa, and are found to be incorrect and not complete. For example, the boundary of Kano state is missing a large area in the south, where three LGA's are mistakenly given to Kaduna state. Regarding the LGA's we noticed that only for a few of them a polygon was drawn.
With this import we hope to add all State and LGA features at once.
This import is part two out of two of importing eHealth Africa's boundaries. The wiki of part one can be found here.
Schedule
- Preparation, discussion - 28th April to 2nd May 2014
- Import - expected start in 3rd of May 2014. Expected to be finished by 7th May 2014.
Import Data
Data description
The datasets have been donated to eHealth Africa by the an international health organization. The exact details on this can't be published in this wiki, but is available for you on request.
The boundary datasets are made topologically correct, so that there are not gaps between features or overlaps of features present. The boundary features of the different administrative levels are aligned with each other, so that e.g. each LGA boundary falls in the State boundary it belongs to. The name of every administrative feature has been verified on correctness and writing/spelling.
The dataset consists of LGA boundaries and State boundaries for 26 states of the Central and South Nigeria that complement the 10 states that will be imported in a different import ((Kano, Borno, Yobe, Sokoto, Zamfara, Katsina, Jigawa, Bauchi, Kebbi and Kaduna)).
The dataset contains the following field attributes: AMAPCODE, LGACode, LGAName, SHAPE_Area, SHAPE_Leng, SHAPE_STAr, SHAPE_STLe, Source, StateCode, StateName, Timestamp.
The fields that have 'code' in the name are attributes that contain identification information of the different administrative levels internally used by eHealth Africa, and are therefore assumed not to be relevant for OSM. Only the fields with 'name' in the name will be included in the import process.
Background
ODbL Compliance verified: YES
An international health organisation has donated the data to eHealth Africa, and eHealth Africa has given full authorization for their data with the standard authorization document of the HOT. A scan of the document can be found here
Note that eHealth Africa has made the necessary corrections to this dataset so as to have it topologically correct, aligned with the international boundaries, and corrected in naming and spelling.
Import Type
The import will be split by state, so it will be done in 27 changesets, one for each state plus the Abuja Federal District. In each changeset, we will delete the maplibrary data and substitute it by the eHealth Africa data, adapting the new state limits to the old state limits of the neighboring still-not-imported states.
Data Preparation
Data Reduction & Simplification
The data will be reduced only to the keys listed further down.
Tagging Plans
LGAs
Include all segments of the boundary of the LGA as role=outer in a relation of type=boundary. Members will have the following tags:
| OSM tag |
|---|
| admin_level=* It can be 2, 4 or 6, depending what is the highest administrative level it belongs to. |
| boundary=administrative |
| source=ehealthafrica.org |
| source:date=2013 |
Although not part of the import, for LGA's an administrative centre (role admin_centre) will be added as member of the relation, with tags:
| OSM tag |
|---|
| admin_level=6 |
| capital=6 |
| name=* |
| place=* |
| source=ehealthafrica.org |
| source:date=2013 |
The relation will have the following tags:
| OSM tag |
|---|
| type=boundary |
| admin_level=6 |
| boundary=administrative |
| name=* |
| source=ehealthafrica.org |
| source:date=2013 |
| wikipedia=* |
States
Similar to LGA's, but:
- Change the 6's for 4's.
- As the import will be done state by state, the state relations will be edited manually from the members of the State LGA's that compose the state borders. Also manually it will be included the capital city of each state, as role=admin_centre.
- States relations will have the following additional tag: ISO3166-2=* . The value of that tag will be gotten from the StateCode field of the shapefile, just adding NG- in front of it (NG-EK for Ekiti state, NG-OG for OGUN state, etc., always according with the ISO3166-2 standard for Nigeria.
For states that share part of it's border with a neighboring country (Niger, Benin, Tchad, etc.), we will change manually the admin_level=* tag to admin_level=2 for the segments included in the border.
eHealth Africa fields tagging translation
| eHealth Africa Key | OSM tag |
|---|---|
| AMAPCODE | Not relevant |
| LGACode | Not relevant |
| LGAName | name=*, for when it is an LGA |
| LGACode | Not relevant |
| SHAPE_Area | Not relevant |
| SHAPE_Leng | Not relevant |
| SHAPE_STAr | Not relevant |
| SHAPE_STLe | Not relevant |
| Source | Not relevant (it's the name of the eHealth surveyor). Will be substituted for source=eHealth Africa |
| StateCode | From it we will get the ISO_3166-2 code for each state, just adding NG- in front of the code |
| StateName | Not relevant. Import will be done state by state, and the State name will be incorporated manually. |
| Timestamp | Not relevant |
| Urban | Not relevant |
Changeset Tags
We will use the following changeset tags.
- comment=eHealth Boundaries Import (2) - State of Ekiti (substitute Ekiti for the appropriate state for each changeset)
- created_by=JOSM/version
- source=ehealthafrica.org
- source:date=2013
- import=yes
- url=http://wiki.openstreetmap.org/wiki/Import_Nigeria_eHealth_Africa_Boundaries_(2)
Data Transformation
Data is in shapefiles. For each state we have one shapefile with LGA boundaries and another with the State boundary. For each state we'll open those two files in JOSM with the OpenData plugin. We'll merge both State and LGA's shapefiles in one layer. We save the layer as .osm file. We then convert them with an ad-hoc written script, that splits the boundaries in common segments and builds the corresponding type=boundary relations. We will then look carefully for possible errors (this will at least include the JOSM validator). After that, the maplibrary boundaries for that state will be deleted from the existing OSM data. Next, the new boundaries JOSM layer for the state that is being imported will be merged with the existing OSM data. The boundaries of the neighboring states will be modified to adapt to the borders of the state that is being imported. Another careful validation will follow, before we upload the changes for that state.
Data Merge Workflow
Team Approach
Import will be undertaken by GIS eHealth Africa personnel with the eHealthAfrica_imports OSM user.
References
The import will be discussed in the import list.
Workflow
Already explained.
Reverse plan
In case of any trouble, JOSM reverter will be used.
Conflation
Already explained.