WikiProject Uganda/Import Kampala Capital City Authority Data

Goals

The goal is to import Kampala Capital City Authority(KCCA) data provided under the Nakamiro Mapping And Surveying Channel Area Project. The import process and workflow will also provide a step into integrating OpenStreetMap workflows into government GIS processes.

Feature	Number
Buildings	35,538
Roads	737
Marketplaces	5
Drainage	1,546
High Voltages Poles	883
Hv lines	926
Low Voltage Lines	3,289
Low Voltage Poles	4,961
Transformers	172
Informal Settlements	16
Land Use	91
Schools	198
Street Light	272
Hill tops	2
Spot heights	4
Wetland	2

Schedule

Preparation, discussion: To be started on <date> Import: Expected to start as soon as the community has solved any issues. The Map below shows what data sets have been uploaded in the 5 parishes of Kawempe division in Kampala

Data

Data was provided by KCCA

Data description

According to KCCA, the data was collected between 2011 and 2016, based on Arc1960 UTM 36S, for the sole purpose of city planning, management and administration. The dataset contains several field attributes that can be used to improve on existing OSM data.

Background

ODbL Compliance verified: YES The Kampala Capital City Authority has given full authorization for the use of their data in OpenStreetMap under the ODbL license. A scan of the document can be found here.

Import Type

The import will be done manually by a team of experienced mappers following a detailed workflow to accomplish this. For each feature, we will assess the existing data in OSM against the KCCA data, for the merging of the KCCA data into the OSM database.

Note: In addition to the KCCA data, we have conducted field surveys a team of 30 mappers. The KCCA data will be used to provide additional attributes to the data collected by the field teams.

Data Preparation

Data Reduction & Simplification

The data is originally in shapefile format. You can download the original data from here.

Tagging Plans

Buildings

KCCA tag	OSM tag	Comments
Division = <name>	addr:division = <name>
Parish2 = <name>	addr:parish = <name>
Village2 = <name>	addr:village = <name>
PropertyType = Institutional, Residentialowneroccupied,Residentialrented, commercial,	building=commercial, residential
PropertySu=<classroom, hostel, barn, apartment, hospital,carteen, factory, kiosk, greenhouse, kraal, labaratory,mda, cemetry, bar_club, abbatoir, office, public toilet,poultry house,warehouse, rental space, showroom, store kitchen, stores>	building:use= <apartment, laboratory, green_house>building=<*>
entitytype=<individual>	Delete	Type of entity that owns the building; whether its an individual or company
legalname<name>	name<name>
flatnumbe=<number>	addr:flats= <number>
housenumber	addr:housenumber= <integer>

Roads

KCCA tag	OSM tag	Comments
layer= paved, unpaved	surface= paved, unpaved	Road condition
Road_Name	name=*	Name of road
Road Code	ref=*	Reference code

Marketplaces

KCCA tag	OSM tag	Comments
Name	name	Market name
DIVISION<name>	addr:division<name>	Division name
PARISH<name>	addr:parish<name>	Parish name
ZONE<name>	addr:village<name>	Zone/Village name
MARKET_NAM<name>	name<name>	amenity= marketplace
NAME_OF_VE<name>	Delete	Name of the association managing the market
NAME_OF_CH<name>	Delete	Name of the chairman of the market
CONTACT_OF< phone number>	contact
CONDITION<permanent, temporary>	note=<temporary, permanent, semi-permanent>
ROAD_NAME<name>	Delete	Major road on which the market is located
MARKET_STA<Gazetted, Non Gazetted>	note=<official, not official>
NUMBER_OF<Integer>	Delete	Number of vendors in the market daily
NUMBER_O_1<Integer>	Delete	Number of vendors in the market weekly
TOTAL_NUMB<Integer>	capacity=<integer>

Drainage

KCCA tag	OSM tag	Comments
Primary_Co<LU2,MA8A>	Delete	The drainage area code reference
Type<Tertiary>	waterway=canal, drain, ditch	Link
Basin<8A>	Delete	The area basin reference ID
Basin_Code<MA8A>	Delete	The area basin reference code
Road_type<paved, unpaved>	Delete	Th road surface next to the drainage system
Tertiary_C=<LU2_0_10177,LU2_0_9980>	Delete	Drainage reference code

Energy Utilities

KCCA tag	OSM tag	Comments
LvLineABC/UGHvLineABC/UG	power=line, power=minor_line
OBJECTID<integer>	Delete	Survey object ID
ASBUILT<Existing Conductor, New Conductor>	Delete	Column represents where the power line is new or has been in existence for sometime
DISTRICT<WANDEGEYA>	addr:district
Substation<KAMPALA NORTH,KAWANDA,NAMUNGONA,LUGOGO>	Delete	Depicts the name of the substation to which the powerline originates
FEEDERNAME<KAWEMPE,MULAGO HOSPITAL 2,NTINDA,NAKULABYE,NAKULABYE, MAKERERE UNIVERSITY,KOLOLO,MAKERERE UNIVERSITY,MUTUNDWE,KAWANDA,GAYAZA ROAD	Delete	Depicts the location from which the power lines originate
FeederCode<KLN/KWP/11/1,KLN/MHO/11/2…>	ref=<KLN/KWP/11/1,KLN/MHO/11/2…>
VOLTAGE<11,33>	Voltage
DblCircuit<True, False>	Delete	Depicts whether the power line has a Dbl Circuit
PHASE<0>	Delete	Shows the number of phases the powerline has. Insufficient data was available for this column
LENGTH<integer>	Delete	Depicts the length of the power line in km
Legal< TRUE, FALSE>	Delete	Shows whether the power was legally installed
lvPoleABC/UGHvPoleABC/UG	power=pole, power=minor_line
OBJECTID<integer>	Delete	Survey object ID
ASBUILT<New pole, existing pole, replaced poler>		Column represents where the pole is new or has been in existence for sometime
DISTRICT<WANDEGEYA>	addr:district
Substation<KAMPALA NORTH,KAWANDA,NAMUNGONA,LUGOGO>	Delete	Column represents the substation area under which the pole is located
FEEDERNAME<KAWEMPE,MULAGO HOSPITAL 2,NTINDA,NAKULABYE,NAKULABYE, MAKERERE UNIVERSITY,KOLOLO,MAKERERE UNIVERSITY,MUTUNDWE,KAWANDA,GAYAZA ROAD	Delete	The name of the location of the origin of power line the power pole attached to
FeederCode<KLN/KWP/11/1,KLN/MHO/11/2…>	ref=<KLN/KWP/11/1,KLN/MHO/11/2…>
OVERALLCON<Structure OK,Urgent Maintenance,Normal Maintenance>	operation_status< good, needs_maaintenance>	Proposed tag
VOLTAGE<11,33>	voltage<11,33>
STRUCTURE<Pin Angle, Termination,Angle Strain (30-90),Flying Angle, Termination	design< pin angle, termination, strain>
LINECONFIG<Horizontal,H-Pole,Vertical,H-Pole/Lay Pole>	Delete	The column represents how the power lines were attached to the pole
POLEMATERI<wood>	material
POLELENGTH<12m, 14m>	height
POLEUSAGE=<MV/LV Combo,MV Only	Delete	The type of use of the pole
NOOFTOFFS<0,1>	Delete	Number of power lines coming off the pole
MVPHASE<3phase>	Delete	Maximum number of high voltage phases
LVPHASE=<1 Phase, 2phase, 3phase, N/A>	Delete	Maximum number of low voltage phases
CUSTTYPE=<House Connection,N/A,Ground Mounted Kiosk,Other, Cable - Box>	Delete	Type of connection
CUSTOMERCO<integer>	Delete	Number of customers
HVOPENPOIN=<True, False>	Delete	The column depicts where the pole has a high voltage openpoins
LVOPENPOIN=<True, False>	Delete	The column depicts where the pole has a low voltage openpoin
INSULATORT<Porcelain Pin, Glass Disk,Polymeric Strain,Porcelain Post,Porcelain Disk>	Delete	Type of insulator used
INSULATORC<integer>	Delete	Number of insulators used
CONNECTION<Wire Wrap, Crimp,PG Clamp,other>	Delete	Type of wire connection
STREETLIGH=<1 Phase, 2phase, 3phase, N/A>	phases
EQUIPMENTT=<N/A, conditionOK,missing, Damaged>	Delete	Where the pole is lacking any particular equipment
KIOSKCONDI=<N/A, conditionOK,missing, Damaged>	Delete	Where the pole is lacking a Kiosk and the condition
PADLOCKCON<N/A, conditionOK,missing, Damaged>	Delete	Where the pole is lacking a padlock and the condition
STAYCOUNT=<0,1>	Delete	Where the pole has stays
NoLvStays=<0,1>	Delete	Whether the pole has low voltage stays on the pole
FLYINGSTAY=<0,1>	Delete	Presence of a flying stay on the pole
GUYSTAY=<0,1>	Delete	Presence of a guy stay on the pole
SHORTSTAY=<0,1>	Delete	Presence of a short stay on the pole
STRUTCOUNT=<0,1>	Delete	Presence of a strut on the pole
ABS<True, False>	Delete	Whether the pole has an ABS
CABLETERMI<True, False>	Delete	Whether the pole has a cable termination
CIRCUITBRE<True, False>	Delete	Whether is the a circuit break on the pole
FUSESWITCH<True, False>	Delete	Whether there is a fuse switch present on the pole
FUSEDROPOU<True, False>	Delete	Whether the pole has FUSEDrop present
FUSES<True, False>	Delete	Whether there are fuses on the pole
GANGSWITCH<True, False>	Delete	Whether there is a gang switch present
ISOLATOR<True, False>	Delete	Whether the pole has insulators present
KNIFEBSWIT<True, False>	Delete	Whether the pole has a knife switch present
METERUNIT<True, False>	Delete	Whether the pole has a meter unit present
RMU<True, False>	Delete	Whether the pole has a RMU present on it
SECTIONALI<True, False>	Delete	Whether is a sectionali pole.
CAPBANKS<True, False>	Delete	Where the pole has capbanks present
Transformer	power=transformer	If the location of the transformer is on a pole then power=pole; transformer=distribution
TX name<name>	Name <name>
voltage<11,33>	voltage<11,33>
mounting< pole, ground pedestal>	location<pole, ground, pedestal>

Landuse

KCCA tag	OSM tag	Comments
OBJECTID<integer>	Delete	Survey object ID
PARISHCLAS<community facility,transport,low income,very low income,industrial,park & sport,vacant land,middle income,vacant land,commerce small scale & informal,wetland,agriculture informal	landuse= industrial; agriculture natural=wetland,
PARISHREGI<Mulago I, Mulago II, Mulago III,Bwaise I Bwaise II, Bwaise III, Kanyanya, Kyebando,Kawempe I, Kawempe II, Makerere I, Makerere II, Makerere III, Kasubi, Kazo, Nabweru>	addr:parish
AREA_HA2<Integer>	delete	Area of land use in hectares
AREA_SQ_KM< integer>	Delete	Area of land use in km2

Informal settlement

KCCA tag	OSM tag	Comments
Slum name< name>	name	Add land use= residential, residential= slum
Shape length <integer>	Delete	Length of the settlement
Shap area<integer>	Delete	Area of the settlement

Schools

KCCA tag	OSM tag	Comments
District <Kampala>	addr:district<name>
County<Kawempe,Kyadondo>	addr:county<name>
Subcounty< Kawempe North, Kawempe South, Rubaga North, Nabweru	addr:subcounty<name>
Parish<Kaso, Nabweru, Mulago, Mulago ii,Kawempe I, Kawempe II, Kasubi, Makerere I, Makerere II, Makerere III, Bwaise I, Bwaise II, Bwaise III, Kanyanya	addr:parish<name>
Village<name>	addr:village <name>
Name<name>	name<name>
ERT_Energy<0>	Delete	Amount ERT energy generated
Fcode<0>	Delete	School, insufficient data to be uploaded to OSM
Collection<Probably 2003 or 2004>	Delete	Date of data collection
Collecti_1<GPS>	Delete	Equiment used to collect the data
Schooltype<Primary, Secondary>	isced:level< 2,3>	Add amenity= school
Ownership<Private, Government>	operator< private, government>
School_Sta<Non-government, Government>	operator_type< government, non government
School_S_1< School open and use>	operational_status	Proposed tag
No_Student<Integer>	capacity<integer>
No_Teacher<Integer>	staff_count:teachers
No_Classro<Integer>	classroom_blocks<integer>
EMIS_Data< 2003, 2004>	date<2003,2004>
School_Ref< Integer>	ref<number>
Grid_Dista< less than 1km, greater than 1km>	Delete	Distance to a reference point within a grid
Source <AFRICON EMIS Schools Project>	Source <AFRICON EMIS Schools Project>

Street Light

KCCA tag	OSM tag	Comments
feature= street_lamp	highway=street_lamp
ObjectID< integer>	Delete	Survey object ID
1a__Data_C<imuwonge>	Delete	Data manager ID
Validated<1>	Delete	Where the feature was validated
2__Divisio<KAWEMPE>	addr:division
4__Circuit<TtulaRoad,SirApolloKagwaRoad,BomboRoad,Ttula_MpererweRoad,LugobaRoad	Delete	The road on which the pole is located
5a__Latitu< co ordinates>	Delete	Latitude coordinates
5b__Longit<co ordinates>	Delete	Longitude coordinates
Select_App<light, control>	Delete	Presence of lights
6__Type_of <metallic>	Delete	Material pole used
M2__Pole_S<upright1, missing1, broken>	Delete	Pole condition
M3_Cover_P< Present OK, missing,	Delete	Light cover present
M4__Arm_st<one>	Delete	Number of light arms present
M5__Type_o<sodiumvapor, none>	Delete	Type of light present
M6__Workin<working, non working>	operation_status< operational, non_operational>
M7__Light<150,0>	Delete	Light watts
M12__Cable<ok1, notok1>	Delete	Cable condition
M13__Cable<OK, FAULTY, NOLATERN, SHORTING>	Delete	Cable condition detail
9__Street<OK, FAIR, POOR>	Delete	Overall condition of the street
CreationDa<Date>	date	Date of collection of data
Creator<landscape_team2>	Delete	The department team that created the dataset
EditDate<date>	Delete	The date the dataset was edited
Editor<landscape_team2>		The department team that edited the dataset

Elevation

KCCA tag	OSM tag	Comments
Hilltops
name<name>	name<name>	Add natural=peak
height<0>	height<integer>
Spot elevation		Add natural=spot_eleation
height<integer>	ele<integer>

Changeset Tags

We will use the following changeset tags:

• comment=KCCA data import #nakamiromapping
• source=KCCA
• source:date=2011..2016
• import=yes
• url=https://wiki.openstreetmap.org/wiki/WikiProject_Uganda/Import_Kampala_Capital_City_Authority_Data

To the * comment=* tag, you may need to add particular comments to the changeset.

Data Transformation

Data is in shapefile format. We opened that in QGIS and saved each file in a geojson format. In QGIS we also removed all the column attributes that were not in sync and not are to be uploaded to OpenStreetMap. Basing on the existing columns new attribute columns were created using the field calculator in QGIS with columns headers that match the OSM key and values in OSM. The dataset was loaded in JOSM using the opendata plugin.

Data Merge Workflow

For feature conflation, the different datasets will be reviewed and compared with their OSM counterparts to select the attributes and features that will be uploaded to the OpenStreet Map. The following section presents the considerations that will be taken into account for each one of the previously selected datasets to be merged with the attribute table or the features to complement the gaps.

General Overview of Data Merge Workflow

      JOSM

All features that have an offset with respect to the imagery or the rest of the features will be corrected using JOSM. Once all the features have been aligned to the correct CRS (Coordinate Reference System), they will be transferred to QGIS where the conflation process will be undertaken (explained below). Once conflated, the updated features will be again transferred to JOSM, further verified and finally uploaded to OSM.  

      QGIS

For all non-OSM features, their respective attribute table will be cleaned in order to only contain the previously selected attributes to be conflated with the OSM data. Later on, the overlapping features will be filtered and erased.

      Line features

For every external non-OSM data represented by a line feature, a buffer will be created.  All the OSM line features that fall into the buffer are to acquire all of the attributes of the non OSM field selected for the completion.

       Point features

For every external non-OSM data represented by a point feature, a buffer will be created.  All the OSM line features that fall into the buffer and do not overlap with other features, are to acquire all attributes of the non OSM field selected for the completion.

       Polygon features

All non-OSM features overlapping those from osm will get all the respective OSM attributes. The attributes with the best quality or most updated information will be kept.

        GeoJSON conversion

Once the conflation process is done, all conflated files will be converted to GeoJSON in QGIS and then transferred to JOSM to be verified and rectified in case there are CRS problems.

Buildings

Step 1:

Open JOSM and download the latest Buildings digitised in OSM using Esri and Maxar imagery. Using the Overpass-Turbo  download query wizard in JOSM all buildings in the Nakamiro catchment area are downloaded.

Step 2:

Inspect the layer to identify any gaps in data quality using JOSM.  In order to clean up the buildings in OSM the HOT team will use the 2014 high resolution imagery shared by the KCCA’s GIS.

Step 3:

Upload the received imagery to OAM. Due to technical difficulties in getting the imagery into openaerial map, HOT will convert the imagery into Mbtiles and create a remote mapping task of the area.

Step 4:

Review the imagery’s accuracy. To check for imagery accuracy between the KCCA high resolution and the satellite imagery default in OSM (Maxar), HOT  will use GPX tracks. After comparing with GPX tracks data collected on the field, KCCA high resolution imagery was deemed to be accurate. Through mapping supervisors and youth mappers, HOT will realign and remote map the OSM buildings to be added to the KCCA high resolution imagery.

Step 5:

Select the features and attributes to be conflated. The KCCA GIS team shared a 2014 buildings dataset in point format. Only those fields that contain OSM compatible tags will be selected and retained. The tags and fields that were not OSM comparable will be dismissed.

Step 6:

Field mapping. The digitised and re-aligned buildings will then be used as the XML layer in OMK during the data collection. Using the Mbtiles of 2014 the surveyors will update the buildings in OSM and those not existing in the 2014 imagery will be mapped using points on OMK.

Step 7:

Conflation. The resulting remote mapped and field collected building dataset will then be merged and compared with the KCCA 2014 buildings. The OSM comparable attributes from the KCCA 2014 building dataset will then be copied to the existing OSM buildings dataset. The data will be validated with the 2019 high resolution imagery shared by the KCCA team. In case of any conflicting attributes between the two datasets the HOT remote mapped and field collected dataset will supersede any other as it is the most updated. All attributes susceptible to be remotely verified will be reviewed using the 2019 high resolution imagery.

---

Roads

The selected KCCA’s attributes will be copied and pasted onto the existing OSM roads. In case the surface type for a certain segment of road does not match between OSM and KCCA’s data there was a validation from the ground and the 2019 image that will supersede the value.

Table IV: Roads conflation equivalencies table

	KCCA roads	OSM roads
Key	field: layer	highway=surface
Tag	Paved Roads	Paved
	Unpaved Roads	Unpaved
Key	field: ROAD_NAME	highway=name
Tag	All named roads	name
Key	Field: Rodcde	ref=*
Tag	All named roads

Step 1:

Roads previously digitised in OSM using Bing, Esri and Mapbox and Digitalglobe satellite imageries will be first downloaded using the Overpass-Turbo query wizard in JOSM for the selected area.

Step 2:

Inspection of OSM’s data quality using JOSM. Most of the roads in the project area of Interest were previously digitised effectively in OSM with a few paths missing. Most of the OSM roads had only one attribute: ‘highway’ = ‘primary’; ‘secondary’; ‘tertiary’ or ‘unclassified’.

Step 3:

Inspection of external data. KCCA shared a 2016 roads dataset digitised using the 2014 high resolution imagery and currently being used to set up road name signage within the city. Both datasets were loaded in JOSM and compared. KCCA’s layer presented an offset with respect to the OSM roads layer. This offset will be corrected to assist the conflation process.  

Step 4:

Select the attributes and features to be conflated. For roads only two attributes that contained similar information; ‘layer’ and ‘road_name’ were found between OSM and the dataset provided by KCCA. These attributes’ respective keys and tags will be matched following the criteria of the OSM wiki on roads tagging. The attributes coming from KCCA’s datasets will be adapted to match the OSM tagging system by changing the respective column name and cell value to the respective OSM equivalent.

Step 5:

Divide the data sets in manageable sections. The updated KCCA roads dataset will be divided up into sections, based on the parish from which the road originates. In some cases the attributes from the KCCA dataset will be transferred to the OSM layer by using the Conflation plugin in JOSM, and for some other cases, it will be done manually.

Step 6:

Conflation. Two methods will be piloted for the conflation of KCCA and OSM roads.

Method 1: Using the JOSM conflation plugin

First the updated KCCA dataset will be loaded in JOSM as a geojson or OSM layer. Now, download the OSM roads layer, as a new layer,  using the Overpass-Turbo wizard. Then the conflation plugin will be downloaded by going to Edit and then Preferences menu. Then on the Plug-in tab the Conflation plug-in will be downloaded. Now select all KCCA’s features in JOSM. On the Conflation plug-in window, click the configuration button, and set  the KCCA dataset as the reference layer.

Afterwards, select all the OSM roads layer features and in the Conflation plug-in choose the OSM layer as the subject. Once all features have been selected, set the rest of the conflation parameters on the dialog box. First, select the one to one method and the Hausdorff distance option. Uncheck the replace geometry option. This is because you only want to transfer the attributes and not the geometry. Make sure the ‘merge all tags’ box is ticked and click generate matches. The plugin will then match attributes of all in the reference layer with those in the OSM layer within a distance of 30 metres.

A new conflation layer is generated showing what features are to be transferred and matched together. Later on, on the conflation palette window click the ‘matches’ tab. This tab shows all the common features between both layers that will be susceptible to be conflated. Now, highlight all features to be conflated, and click on the conflate button. This will bring a window that will allow you to manually solve, one by one, the tagging conflicts existing between both layers features. The data cleaner will then be required to choose between the OSM and KCCA attribute for the feature. After this process is finished, all the tags of the coincident features from the reference layer will be transferred to the subject layer. Now, you will have to go to the subject layer and verify, object by object, if the tag conflation was actually done. For those common features that were common and the tags were not transferred, you will have to do it manually using method 2 outlined below.

Method 2: Using systematic manual inspection

The following diagram is a mind map that depicts the second workflow used to conflate the attributes from KCCA roads to the OSM layer and the additional features that only existed in the KCCA roads layer and not on the OSM layer, tags inclusive.

Marketplaces

The market data from KCCA will be loaded into QGIS in the shapefile format. The data set was then saved as geojson to ease editing and loading into in JOSM subsequently. In QGIS all fields that were not compatible with the with the OSM data model and tagging system were deleted these included NAME_OF_VE, NAME_OF_CH,ROAD_NAM,MARKET_STA and NUMBER_OF. The column attributes that were inline with the OSM tagging model were then edited using the field calculator. New fields were created inline with the OSM tagging model.

The data was then loaded in JOSM as a geojson and the KCCA 2019 high resolution imagery added either as a TMS using openaerialmap or as an Mbtile locally in JOSM. Using the JOSM download query option all marketplace features in OSM were downloaded as new layer Using the 2019 KCCA high resolution imagery and the OSM downloaded data,  the marketplace points locations were verified and any duplicated points deleted.This is data-set will be compared with the data collected from the field using the OpenMapKit where any new points marketplaces with added and verified before uploading to OSM.

As for the marketplaces only the available numbers and complementing features (as points) were included into the conflation process.

Table V: Marketplaces conflation equivalencies table.

	KCCA Markets	OSM buildings	OSM Poi's
Key	field: marketplaces	amenity=marketplace	POI
Tag	name	name	marketplace

Drainage

The KCCA  drainage dataset was loaded into QGIS as a shapefile, in QGIS all column attributes that are not related to OSM are deleted and using the field calculator a new column attribute for ‘waterway’ was created. The dataset was then divided by parish and saved as a geojson to then be loaded into JOSM using the Opendata plugin. In JOSM, using the Overpass Turbo download query wizard option, all features tagged as waterways within the AOI in OSM were downloaded. The 2019 KCCA high resolution imagery was then converted to mbtiles and loaded in JOSM. Using the 2019 imagery and the KCCA dataset in comparison with the existing dataset. The senior mapper would systematically focus on a particular drain in the KCCA dataset, he would then use the 2019 imagery to identify and trace the visible drains and tagging them as waterway= drain. If the drain can be clearly seen that its not built or lined then its tagged as a waterway=ditch.For the drains not visibly seen in the 2019 imagery, the field drain data collected will be used to verify and ascertain the existence and type of drainage in place.

Energy Utilities

Low and high voltage lines

The low and high voltage power network data will be first loaded in QGIS. In QGIS the following attribute columns will be deleted: OBJECTID, DISTRICT, Substation, FeederName, type and size. The Feedercode column attribute will be edited to become ref. Using the field calculator a new column of power with a default value of ‘line’ for high voltage and ‘minor_line’ for low voltage power lines, respectively, will be created. The two datasets will then be saved as Geojson. The newly saved high and low voltage line will be loaded into JOSM using the openlayers plugin. The two datasets will be then merged and. In this new layer, both the low and high voltage lines will be copied from their respective shapefile layers and pasted in their exact location on the new OSM layer using Ctrl+A to select all features, Ctrl+C to copy and Ctrl+Alt+V to paste in the exact location. Once all power lines are in one layer, all data relating to power existing in OSM will be downloaded as a new layer. Using the download Overpass-Turbo query wizard, the senior mapping supervisor, will use the following query ‘power=*’ to fetch the data. Once the data is in OSM, a comparison between what is existing in OSM and the acquired KCCA dataset will be carried out. This is done to avoid double mapping or uploading information to OSM of already existing features.

Using the ‘todo list’ plugin, the senior mapper will then inspect each segment of the power line. If a power line does not exist in OSM, then its copied and pasted onto the OSM downloaded layer. If the powerline already exists in OSM and also exists in the KCCA/UMEME dataset, then the KCCA/UMEME dataset takes precedence as the data was collected through survey while the existing OSM data was acquired using satellite data which would render it of lower accuracy. The senior mapper will also use the Mappillary plugin in JOSM to verify the existence of the power lines by downloading the available Mapillary images within the area. He would then look for evidence of power line within the images before adding the power line segment on to the OSM layer. This process is done for all high and low power line segments. Once the inspection is done the data that has been added to the OSM layer is then uploaded to OSM.

Low and High voltage Poles

The Low and high voltage power poles data was first loaded in QGIS. In QGIS the following attribute columns were deleted: OBJECTID, ABSULT, DISTRICT, Substation, FeederName, LINECONFIG, POLEUSAGE, NOOFTOFFS, MVPHASE, LVPHASE, CUSTTYPE, CUSTOMERCO, HVOPENPOIN, LVOPENPOIN, INSULATORT, INSULATORC, CONNECTION, STREETLIGH, EQUIPMENTT, KIOSKCONDI, PADLOCKCON, STAYCOUNT, NoLvays.

The column attribute of Feedercode was edited to become ref, OVERALLCON to condition, VOLTAGE to voltage, STRUCTURE to pole_type, POLEMATERI to material, POLELENGTH to height.

Using the field calculator a new column for ‘power’ with a default value of pole was created. The two datasets were then saved as Geojson. The newly saved high and low voltage line were loaded into JOSM using the openlayers plugin. The two datasets were then merged and a new OSM layer was created. In this new layer, both the low and high voltage lines were copied from their respective shapefile layers and pasted on the new OSM layer using Ctrl+A to select all features, Ctrl+C to copy and Ctrl+Alt+V to paste into their exact location. Once all power lines are in one layer, all OSM data relating to power was downloaded as a new layer. Using the download overpass query wizard, the senior mapping supervisor, used a “power=*” query to acquire the data. Once the data is in OSM, a comparison between what is existing in OSM and the acquired KCCA dataset is carried out. This is done to avoid double mapping or uploading information to OSM of already existing features.

Using the ‘todo list’ plugin, the senior mapper would then inspect each segment of the power line. If a power line is not in OSM, then its copied and pasted onto the OSM downloaded layer. If the powerline already exists in OSM and also exists in the KCCA/UMEME dataset, then the KCCA dataset takes precedence as the data was collected through survey while the existing OSM data was acquired using satellite data which would render it of lower accuracy. The senior mapper would  also use the Mappillary plugin in JOSM where possible to verify the existence of the power lines by downloading all mapillary images within the area. He would then look for evidence of power line within the images before adding the power line segment on to the OSM layer. This process is done for all high and low power line segments. Once the inspection is done the data that has been added to the OSM layer is then uploaded to OSM.

Land Use

The land use data will be first loaded into QGIS in the shapefile format. In QGIS, the following column attributes will be deleted; (OBJECTID, AreaHA, Area sqkm). The columns attribute PARISHCLA will be then edited to ‘landuse’ and the values of ‘low income’, ‘middle income’ and ‘very low income’ will be deleted. The features whose values will be deleted will be filtered out and saved out as a geojson. The remaining features will then be saved as a geojson and loaded into JOSM.

In JOSM the 2019 high resolution imagery acquired from KCCA will be converted to mbtiles and loaded in JOSM using the mbtiles plugin. Using the todo list plugin, each feature will be inspected using the 2019 imagery to ascertain whether land use value reflects a true and updated description of the area in question. From the inspection, the HOT team noticed that the land use layer was outdated and could not be uploaded to OSM.

As for the landuse2015 the tags were very similar. Only the complementing features are to be conflated.

Table IX: Landuse conflation equivalencies

	KCCA Landuse2015	OSM landuse
Key	field: Land_cover	landuse=*
Tag	High density
	Low density
	Medium density
	paved roads
	Wetlands	natural=wetland

Schools

The schools dataset was loaded into QGIS and converted from csv to Geojson. Then the following column attributes were deleted; ERT Energy, Fcode, Ftype, Remarks and Grid distance. The rest of the column attributes were edited to match the respective OSM tags as listed below. The file was then saved and loaded in JOSM as GeoJson. In JOSM all education related points in OSM were downloaded using the download query wizard. The senior mapper used the ‘amenity=school” query to download all schools as a new OSM layer within the dataset extent.

Using the ‘todo list’ plug-in all schools in the KCCA dataset were selected and cross checked with the schools in the OSM layer. When a school existed in both datasets, attributes would be compared and if there is a contrast the OSM dataset would take precedence as it was collected in 2014 compared to the 2003-2004 collection date of the KCCA dataset.This dataset will also be compared and updated  with the data collected from the field.

The schools layer contained points obtained from UBOS, the ‘name’ field and the complementing features are going to be conflated following the key below. The school points were matched with the respective building :

Table X: Schools conflation equivalencies

	UBOS Schools		OSM
Key	Feature/Dataset	field: NAME	building= yes	amenity=yes	Comment
Tag	Schools_ubos	Name	building=school	amenity=school=*	Building as polygon, amenity as a point

Street lights

The Streetlight dataset was first loaded into QGIS and converted from CSV to geojson. Then all the column attributes that could not be matched with an OSM tag were then deleted. The list of column attributes and what actions were taken against them is listed in the table below. Using the field calculator a new column attribute ‘highway’ was introduced with a default value of ‘street_lamp’.

All non-overlapping features will be tagged as ‘highway=street_lamp’, conflated with their complement and uploaded as points to OSM.

	KCCA street_lights	OSM highway
Key	Street_lights	highway=street_lamp	Comment
Tag	feature	street_lamp	as points

Informal Settlements

All informal settlements will be tagged as ‘landuse’ = ’informal’. An alternative tagging exists: ‘landuse’ = ’residential’ , ‘residential’ = ’slum’, however this is only a proposed tag. Most common tagging practices will be favored for the sake of consistency. Landuse will be uploaded as a polygon.

Table VIII: Informal settlement conflation mind map

	KCCA Tagging	OSM Tagging
Key	Informal Settlement = feature	landuse= residential	Comment
Tag		residential= slum; inforamal
	feature	informal	The dataset contains the slum name for selected features, this might mean that informal could not necessarily match exactly OSM tagging

Team Approach

Import will be undertaken by experienced OSM mappers, using specific OSM user account, following this <workflow>

References

The import will be discussed first in the Talk-Ug list, and then in the Imports list.

You can see the workflow <here>

Reverse plan

In case of any trouble, JOSM reverter will be used.