Import Nigeria eHealth Africa Boundaries (2)

From OpenStreetMap Wiki
Jump to navigation Jump to search

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

  1. Preparation, discussion - 28th April to 2nd May 2014
  2. 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.

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.