Import Nigeria eHealth Africa Boundaries

From OpenStreetMap Wiki
Jump to: navigation, search

Goals

The goal of this import is to substitute the quite poor boundaries of States and LGA's of the maplibrary database for 10 states of North Nigeria by the boundaries collected by eHealth Africa into OSM. On top of the states and LGA's boundaries, the import will include also the boundaries of the Wards for those 10 states.

The current boundaries 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, LGA and Wards features at once.

Schedule

  1. Preparation, discussion - 25th to 30th April 2014
  2. Import - expected start in 1st May 2014. Expected to be finished by 7th May 2014.

Import Data

Data description

The datasets are drawn and generated by eHealth Africa in the course of their mapping activities in northern Nigeria. The organisation has performed data collections in the entire area. For each and every settlement it has been defined in the field to which ward, LGA and state it belongs to. Based on that information, specialists have drawn the borders of all administrative features. During the process of drawing the features, the borders are snapped and aligned as much as possible with natural and artificial break lines present in the landscape, so as to position the boundaries accurately and realistic.

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 Ward boundaries, LGA boundaries and State boundaries for 10 states of the North of Nigeria (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, Urban, WardCode and WardName. 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
eHealth Africa has given full authorization for their data with the standard authorization document of the HOT.

Import Type

The import will be split by state, so it will be done in 10 changesets, one for each state. In each changeset, we will delete the maplibrary data and substitute it by the eHealth data, adapting the new state limits to the old state limits of the neighbouring still-not-imported states.

Data Preparation

Data Reduction & Simplification

The data will be reduced only to the keys listed further down.

Tagging Plans

Wards

Include all segments of the boundary of the ward as role=outer in a relation of type=boundary:

OSM tag
admin_level=* It can be 2, 4, 6 or 8, 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 wards that have a clear administrative centre, they will be added manually in the coming months an admin centre (role admin_centre) as member of the relation, with tags:

OSM tag
admin_level=8
capital=8
name=*
place=*
source=ehealthafrica.org
source:date=2013

The relation will have the following tags (all boundaries are inland, so they all have the land_area=administrative tag):

OSM tag
type=boundary
admin_level=8
boundary=administrative
name=*
source=ehealthafrica.org
source:date=2013

LGA's

Similar to wards, but:

  • Change the 8's for 6's.

States

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 will be included the capital city of each state, as role=admin_centre. Tagging will be similar to the LGA one, but changing the 6's by 4's.

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-YO for Yobe state, NG-KN for Kano 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
WardCode Not relevant
WardName name=*, for when it is an ward

Changeset Tags

We will use the following changeset tags.

Data Transformation

Data is in shapefiles. For each state we have one shapefile with ward boundaries, a second shapefile with LGA boundaries and a shapefile with the state boundaries. For each state we'll open those two files in JOSM with the OpenData plugin. We'll merge the three wards, LGA's and state shapefiles in one layer. We save the layer as .osm file. We then convert it with an ad-hoc 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 a 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.