Import Nigeria eHealth Africa Places
The goal is to import, state by state, the place names that are included as a field of every residential area that were already imported from the eHealth Africa data for 8 states of North Nigeria ( https://wiki.openstreetmap.org/wiki/Import_Nigeria_eHealth_Africa_Residential_Areas ).
The nodes for each area are placed at the centroid of every simple polygon, and as the ponderated-by-area medium point of the centroids of each polygon for every multipolygon. Moreover, the type of place (place=village or place=town) is determined by the total area of the polygon or multipolygon. For the small number of place names inside cities or quarters/neighbourhoods of some towns, we will re-tag them manually to place=suburb, place=quarter or place=neighbourhood, depending on their extension and importance.
- Preparation, discussion - due to start the 10th of July 2014.
- Import - expected to start any time after the community has solved any issues, doubts or concerns about this import. The import will start with the Kano state, and will be followed by the rest of the states, as soon as a final Q&A is performed to their respective data.
The datasets were collected 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 and remote tracing using aerial imagery. Residential areas were drawn and named for what they call, in eHealth Africa, build-up areas, towns and cities.
The original dataset consists of residential areas for 8 states of the North of Nigeria and the name of the settlement that each of them enclose. The 8 states are the following: Kano, Borno, Yobe, Sokoto, Zamfara, Katsina, Jigawa and Kebbi.
The dataset contains several field attributes, of which the only one of interest for this import is the Settleme_1, that contains the name of the settlement.
You can have a look at the original field attributes and some screenshots in this hackpad, under the section Residential areas (cities.shp and towns.shp).
ODbL Compliance verified: YES
eHealth Africa has given full authorization for the use of their data with the standard authorization document of the Humanitarian OpenStreetMap Team (HOT). A scan of the document can be found here.
The import will be done manually through one job for each state in the HOT Tasking Manager (TM), having for each task of the job only the place nodes that lie within the task tile, in a similar way as it was done for the Central African Republic UNICEF import. For each task, we will first check the eHealth nodes to be imported, and second we will assess the data already in the OSM database against the eHealth Africa one for merging the eHealth data into the OSM database. The OSM mappers who will contribute to this import job will follow a detailed workflow to accomplish this.
Data Reduction & Simplification
The data was originally in shapefile format, in two different files (Towns.shp and Cities.shp) for each state. For each state both files were opened in JOSM with the Opendata plugin, corrected their errors and merged in one file. There wasn't any other reduction or simplification than that.
Each place node of every simple polygon and multipolygon will have the following tags:
|place=*||village or town, depending on the area, except for cities, where suburb, quarter or neighbourhood will be used|
For each state, we will use the following changeset tags:
- comment=eHealth Africa NAMEOFSTATE places import, #hotosm-task-NUMBEROFJOB
where we will substitute NAMEOFSTATE by the state (example: Kano) and NUMBEROFJOB by the number of the job in the HOT Tasking Manager (581 in the case of Kano).
In the following table, you can see the import job for each state, the comment in the changeset and its status:
|State||Status||HOT Task Manager job||Changeset Comment|
|Kano||Work in progress||Kano places TM project||comment=eHealth Africa Kano places import, #hotosm-task-581|
|Borno||Finished||Borno places TM project||comment=eHealth Africa Borno places import, #hotosm-task-921|
Data is in osm format. We extract the name from the residential polygons or multipolygons and place it in a node at the centroid of the polygon or at the pondered-by-area medium point of the centroids of the polygons of a multipolygon. This script also decides whether the place is a village or a town depending on the total area of the polygon or multipolygon.
We run the script for the data of each state. The resulting osm file is named as eHealth_Africa_Places_NAMEOFSTATE.osm. For example, for Kano state it's eHealth_Africa_Places_KANO.osm.
Data Merge Workflow
Import will be undertaken by experienced OSM mappers, using an import specific OSM user account.
You can see the workflow here.
In case of any trouble, JOSM reverter will be used.
The location of the eHealth nodes is generally correct. Sometimes you will see the node near one of the edges of the enclosing residential area, or even outside. This normally happens when the place node was extracted from a set of close to each other residential polygons (multipolygon relation), so even in this case we won't change it's position. Only in very exceptional cases it could be needed to change the position of the node, but as a general rule we'll leave the place nodes in the position they are.
First of all, we will check if the name of the place is spelled correctly and respect the cartographic writing conventions. With very few exceptions, each noun of the place must have its initial letter in capital and subsequent letters non-capital, like for example Kurje, Unguwar Abdu and Gwarmai Cikin Gari. In case of doubt, we won't make any change to the name and we will leave a remark on the comments window that pops up when marking the task as done in the Tasking Manager.
Sometimes we find two nodes with the same name beside each other. It may seem at first that this is a case of duplicated nodes and that we should delete one of them, but normally they are there on purpose. In the following screenshot we can see the Walawa village with two identical nodes. In this case they are duplicated because the Western side of the village belongs to Durma ward, whereas the Eastern side belongs to Maitsidau ward. In this case, we will change the names to Walawa East and Walawa West. We should leave a comment about it in the pop up window of the Tasking Manager.
Most of the place nodes we will encounter in the OSM database are from the GNS 2009 import.
In 2009 a huge set of GNS data was imported into OSM, an import that is now assessed as poor and inconvenient. In that dataset we have many duplicated, misspelled and badly located nodes, having many nodes being located in the middle of nowhere or just in the non-inhabited area between several settlements. Worse, many of the nodes don't have any relation to the village where they are located (if they are located over a settlement), nor any of the villages nearby. And, except for the name, we aren't interested in the other GNS tags, that shouldn't be imported to OSM in the first place.
The GNS nodes for settlements are easy to spot, as most of them still have the fixme tag as one of their tags, and therefore they appear as an in JOSM, instead of the usual green polygon icon that JOSM uses to represent a place.
In case of finding a place node already in the database and quite near the eHealth Africa node (in almost all of the cases it will be a 2009 GNS imported node), we will proceed the following way:
2. If the GNS node name is similar to the eHealth counterpart, we will add the GNS name as alt_name (example alt_name=Sansani and source:alt_name=GNS to the eHealth node, and then delete the GNS node.
3. In case the name of the GNS node is different enough from the eHealth one, we will just delete the GNS node. The limit on when the name is similar enough to add it as an alternative name or different enough to dismiss it, is difficult to define. In case of doubt, we suggest to add it as an alt_name and leave a comment on the comments box when you save the task in the Tasking Manager, so it will be carefully reviewed during the validation process.
GNS nodes that are far enough the eHealth Africa nodes that we are importing and that are over or near a settlement or group of small hamlets will be left for the time being. They would be eventually replaced in future imports of eHealth Africa data, like the RuralVillages one.
The nodes inside big towns and cities have to be retagged manually, because the village/town schema doesn't make any sense inside them. Depending on the extension they cover and their importance in the city, they can be tagged as place=suburb, place=quarter or place=neighbourhood.
In case they cover roughly one ward or a bigger area, we suggest tagging them as place=suburb. For nodes that cover smaller areas, we would tag them as place=quarter. The place=neighbourhood tag is for even smaller areas inside a city, but it's quite unprobable that we will find any eHealth Africa node that deserves that tag within this dataset.
About the GNS nodes inside big towns and cities, we will proceed similarly as we did in rural areas. The general goal is to get rid of the GNS nodes and substitute them by eHealth Africa or, in general, by more accurate data.
Finally, any suspicious name in the eHealth Africa layer will be tagged with a fixme=* tag and a comment in the pop-up window when we mark the corresponding task of the Task Manager as done.
For any further questions, you can contact mapping_at_ehealthafrica_dot_org