[Imports] Proposal:Uganda Import

f.dos.santos at free.fr f.dos.santos at free.fr
Tue Jan 28 00:57:13 UTC 2014


I promise, this is my last attempt to convert this shapefile ;-)

This time this is not 1 but 2 OSM file, I've put in [1] a zip with both source and result :
- Uganda_districts2010.shp this is the (112) district only file
- districtReSimRenamed.shp the merge 11 region + 112 district

The code in [2] have been adapted to work with those type of files, it does a better job dealing with the "very close but not the same point" problem and doesn't require a database anymore. 
This works much better now, and it can build automagically the admin hierarchy :-)

So you've got 2 result OSM file :
- districtReSimRenamed.osm with the 123 shapes converted into admin boundary relations
- Uganda_districts2010.osm with the 112 district shapes converted into 123 admin boundary relations

There is still errors in those files, I'll list just a few.

Look for example in the Uganda_districts2010.osm, in region Western (relation -46) you'll see border Kyenjojo and Kibaale have a lot of parallel but not the same way :
- way -341 and way -425
- way -342 and way -424

For Kabale (relation -70) and Kanungu (relation -60) :
- way -377 and way -239

For Kanungu (relation -60) and Rukungiri (relation -40)
- way -376 and way -369
Please note that the split for way -363 is not an error, it was splitted before reaching the 2000 nodes limits.

Kaberamaido (relation -90)
- way -126 very small loop that the simplification process squashed into a single line

In the districtReSimRenamed.osm you'll see the same errors and a new one : Teso (relation -6) and district doesn't share the same ways.
- in way -101 versus way -140 and -141 for district, there is an offset about 60m
- way -98 versus -150 for district, there is an offset about 100m

And finally, the admin level number are obviously wrong as I've chosen them only as example for the purpose of the conversion process.


[1] http://dl.free.fr/mC6bXQBK2
[2] https://github.com/FranciscoDS/uganda_osm.git

----- Mail original -----
De: "f dos santos" <f.dos.santos at free.fr>
À: "Imports OpenStreetMap.org" <imports at openstreetmap.org>
Envoyé: Samedi 25 Janvier 2014 16:36:50
Objet: Re: [Imports] Proposal:Uganda Import


I have done some work to prepare an import (not discussed yet on this list as it's still a work on progress) of portuguese administrative area.
I tested my code on the Uganda shapefile and, after correcting some issues, I've a result (far from perfect as the source is far from perfect) that can be useful.

The OSM file is here [1] and the (experimental) python code is [2].

The code have been adapted to the uganda shapefile, and does the following :
- build boundary relation for each admin area
- build hierarchy of admin area from the lower admin area (district) build the upper (subregion) : DEACTIVATED as it's not working well for this shapefile
- capitalize names and convert from ISO to UTF8
- construct unique way, simplify it and deal with the 2000 nodes limit
- detect and try to resolve self intersecting way
- detect enclave and exclave and give them the proper outer/inner role (for Uganda there is no inner ring)
- save the result on a local postgres+postgis database

The OSM file still contains "issues" so it can not be used as is, but can probably be edited and fixed manually :
- merging the suboptimal ways (two identical ways but not sharing exactly the same nodes coordinates).
- adjusting the admin_level

There is still one big issue in this OSM file : I removed 1 district because of a loop in the shapefile (and my code goes into an infinite loop).

I hope it can help.


[1] dl.free.fr/mpSmh2T9m
[2] https://github.com/FranciscoDS/uganda_osm.git

2014/01/21 "Satoshi IIDA" <nyampire at gmail.com>

>I made a .osm file but they are NOT relationalized. :) 
>So please do not upload them directory. 
>I think it is better to wait Jo's work. 
>> source file 
>seems contain some errors.(e.g. self crossing ways, suspicious small enclave, or so) 
>might need some validation step, in case of. 

2014/1/22 Jo < winfixit at gmail.com > 

I'm looking into converting your shapefiles into proper OSM relations automatically. It will take a while (a few days) though to finish the script. 

I sent you a file yesterday, but it's better to wait a bit. That was the result of some manual practice to find out how to automate it. 


2014/1/21 Aggrey Muhebwa < muhebwa.grey at gmail.com > 

Hello folks, 

Following Ketty's proposal for the Uganda imports , i decided to start by running the shape file for one district (specifically dokolo district), but for some reason, the generated .osm file has <way>....<.way> instead of <relation>...</relation>. Somewhere, she indicates that of 112 districts, only a couple of them are being processed!! Could it be an issue of wrong data in the shape file that is being fed to the ogr2osm.py script?? 

More to that, along the iway in the discussion, someone(my apologies for not mentioning the name) states that there should be a work-around to that, but that's unclear, given the fact that the ogr2osm.py algorithm follows specific steps (and it doesn't seem to be handling checks for worst case scenarios), then it will always give you wrong output if you feed it wrong imput.. (garbage in, garbage out..). 

My proposal is to make sure that the shape file at the input is correct. is there any way of validating the shape file before running it through the script ?. 



Yours Faithfully 
Aggrey Muhebwa 
(+256)774561760 /701909434 

Skype:Aggrey Robotboy 
IRC: AggreyMuhebwa-Robotboy 
"Creativity is Intelligence having fun" 
Imports mailing list 
Imports at openstreetmap.org 

Imports mailing list 
Imports at openstreetmap.org 

Satoshi IIDA 
mail: nyampire at gmail.com 
twitter: @nyampire 
Imports mailing list
Imports at openstreetmap.org

Imports mailing list
Imports at openstreetmap.org

More information about the Imports mailing list