[HOT] eHealth Africa Kano places import

Rafael Avila Coya ravilacoya at gmail.com
Thu Jul 17 18:10:36 UTC 2014

Hash: SHA1

Hi, Paul:

Well, no dataset is 100% ok, and this applies to eHealth data as well.
We can truly use the GNS data for the validation process once all the
nodes are imported + local knowledge. I uploaded a convenient csv file
of that GNS data so you and anyone can open it in JOSM with the
OpenData plugin: http://ge.tt/3zjj9ko1/v/0?c

Except for the nodes of the state capital cities, I haven't seen any
GNS node that says that it is a capital of a ward or LGA.

The RuralVillages.shp is just the name given to one of the files with
places in the eHealth database, as they file them. You can read this
hackpad that tells about the whole eHealth database:
(you can download the data for the Ajingi LGA here (it's from April
14): http://ge.tt/5Cg5Bfe1/v/0 ). If you want to check the
RuralVillages file for the whole of Kano state, just tell me and I
send it to you by email (it's from mid-May).



On 17/07/14 18:20, Paul Mallet wrote:
> Well, if, as you say, the names collected by ehealth are 100% sure,
> then I don't think it is necessary to keep the very different
> names, moreover all this GNS data isn't going anywhere so if "we"
> need it back, we can still access it by other means (a layer as you
> propose).
> For names that refer to a ward/lga, I think the best step is to put
> a note on the new node telling the village/town is the ward/lga
> admin center (according to GNS), so that when we later add those
> admin_center roles, it can be used as an indication...
> PS : what do you call "RuralVillages data", sorry but i'm not very 
> familiar with the import list and data...
> 2014-07-17 18:03 GMT+02:00 Rafael Avila Coya <ravilacoya at gmail.com 
> <mailto:ravilacoya at gmail.com>>:
> About the GNS names that are very different, it can be really like
> you say, and refer to a ward. Even sometimes, they are the name of
> a place that is divided in two, with the two names being the
> neighbourhood names and the GNS the name of the place, but that's
> not very usual I think.
> I also hesitate to delete some GNS nodes. GNS data should be used
> as a complementary data set (similarly, we used the NGA data for
> the Centrafrique UNICEF data import, for example), because it lacks
> enough quality to be imported directly to OSM. In fact, if I
> remember well, there was a thread in the imports list not long ago
> about the possibility of reverting GNS imports altogether.
> In other words: the best scenario would be having the Nigeria map 
> without the GNS nodes, and make the import of eHealth data having
> the GNS data as a layer, adding "GNS" to the source tags as needed,
> as we did with the NGA data in the UNICEF import in CAR (see this
> node as an example: http://www.openstreetmap.org/node/2663456730
> ).
> But what's for sure, most of GNS nodes aren't well geolocated, and
> due to the density of villages in this area, it's normally
> difficult to know to which willage they belong to.
> We could use what we have from the RuralVillages data as a 
> not-to-be-imported layer in JOSM, so we could safely delete more
> of the GNS nodes (most of all probably), but I don't think we loose
> much if we wait for that second import, and we even gain as the
> eHealth database will be growing in the mean time. And having the 
> RuralVillages nodes in JOSM is a temptation, at least for me ;)
> But I don't have the last word in any case. What do you think?
> Cheers,
> Rafael.
> On 17/07/14 16:11, Paul Mallet wrote:
>> Hi Raphaël,
>> Thanks for the answer :) I agree that we can postpone the 
>> admin_centre roles for when the task is finished, and concerning 
>> the capital tags, I really don't know... and it is certainly 
>> different between each rendering (OSM.org, HOT...)
>> Also, I wanted your help about another thing :
>> Most of the GNS places already in the database have a (really) 
>> different name than the ehealth ones. In the wiki, it is written
>> to skip the old ones entirely, but I always hesitate, and even
>> more when the old name is the same as the ward's... Is it a
>> mistake ? an indication that it is the admin center ? an alt_name
>> ? :$
>> Paul
>> Le 17 juil. 2014 14:43, "Rafael Avila Coya"
>> <ravilacoya at gmail.com
> <mailto:ravilacoya at gmail.com>
>> <mailto:ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>>> a
>> écrit :
>> Hi, Paul:
>> Sorry for answering this last email but I missed it.
>> As I understand, what the capital=* tag adds is the importance
>> of the place. For example, if a place is the seat of a ward 
>> (admin_level=8) and also the capital of an LGA (admin_level=6), 
>> tagging it as capital=6 you set clear the importance of the
>> place. I know that this can be extracted from all the boundaries 
>> relations, but I wonder if renderers are doing that, or relaying
>> on this capital=* tag. I really don't know.
>> In any case, I was thinking more about this and perhaps the best 
>> idea (as you also mention) is that, when the import of places for
>> a state is finished (now Kano state), one of us can go through
>> all the LGA's (they are just 44 for Kano state) and put the
>> capitals as admin_centre of their respective boundary relations.
>> It would be a quite easy and small job.
>> About the wards, each LGA has between 10 and 15 wards. For Kano 
>> state we have 484 wards. This is a bigger job. But surely there 
>> will be some ward seats that will be missing for the time being.
>> We could do the ones we have for now, and leave the rest for
>> later.
>> My opinion now would be not to include this in the places import 
>> wiki, so we don't complicate it too much. We can (and I will do)
>> go on adding the admin_centre's for LGA's and wards, and later
>> on, we can complete the missing ones out of the import job. The
>> mirrored download JOSM plugin [1] + the JOSM filters will do it
>> very smartly.
>> As for the Rural villages set of data, bear in mind that eHealth 
>> is, and will be for long, in the process of collecting data in
>> the field, and this includes villages and hamlet names in 10
>> states of North Nigeria. As of mid May, the RuralVillages.shp
>> file had 1,162 place names only for Kano state. There are other
>> files with names for hamlet areas and also isolated hamlets. I've
>> been very lucky to have the opportunity to see how this data is
>> collected in the field, and I can assure you that is a really
>> tough job, and certainly with the risks due to the insecurity of
>> the area.
>> There are two key point here:
>> 1) In the coming months (and probably years), thousands of new 
>> place names (and other geodata) will be continuing to be
>> collected and added to the eHealth database. For that reason,
>> it's important to make sure the quality of the data is good
>> enough before we import it to the OSM database, so merging new
>> collected data to the existing OSM database in the future will be
>> as easy as possible. As an example, the last few weeks 1,087
>> health facilities in Kano State were imported to OSM, and only
>> days later eHealth staff sent me a new .csv with 186 new health
>> facilities for that state!
>> 2) Having the data ready for import is not the only thing we
>> need; we also have to actually import it to OSM. My advice is to
>> see how well and how fast we import this set of place names that
>> we are now importing, before we think on the next import job, so
>> we can keep the whole process as more comprehensive as possible.
>> Cheers,
>> Rafael.
>> [1] 
>> http://wiki.openstreetmap.org/wiki/JOSM/Plugins/mirrored_download
>>  On 16/07/14 08:24, Paul Mallet wrote:
>>> Ok for the admin_centre role. I'm a bit more relucant about
>>> the capital tag however, I think it is redundant with the 
>>> admin_centre role (and has less informations), but anyways...
>>> I have another question for you :)
>>> You mention on the wiki another import for smaller dwellings 
>>> (villages & hamlets), so I was wondering if it was a good idea 
>>> to tag those dwellings right now (place tags + landuse) or if
>>> it could cause some problems during the next phase of the
>>> import... anyways I think it's important to write it in the
>>> wiki.
>>> Gracias !
>>> PS: moreover, until we import the villages, we won't have all 
>>> the admin_centre available, so I think we can define it later.
>>> Paul
>>> Le 16 juil. 2014 04:42, "Rafael Avila Coya" 
>>> <ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>
>> <mailto:ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>>
>>> <mailto:ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>
> <mailto:ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>>>> a
>>> écrit :
>>> Salut, Paul:
>>> Thank you for contributing to this import. It will greatly
>>> help on the efforts for the eradication of Polio in North
>>> Nigeria and, in general, for the development of North Nigeria.
>>> It's very good idea what you propose. Although the import 
>>> requires only the places to be imported, I think we can do
>>> this on top of roads editing and correction, so I will add this
>>> to the wiki and workflow, with clear instructions on how to do
>>> it (probably tomorrow 16th July).
>>> I've seen the task you've done, and it's all perfect.
>>> It's good idea to also add the tag capital=* to the 
>>> admin_centre's. For example, I added capital=6 to Garin
>>> Shanono, capital of Shanono LGA ( 
>>> http://www.openstreetmap.org/node/2965065968 ). For capitals
>>> of wards, they would be tagged as capital=8. But we can forget 
>>> about this tag if we consider that it is unnecessary.
>>> Cheers,
>>> Rafael.
>>> On 15/07/14 23:04, Paul Mallet wrote:
>>>> Hello
>>>> Should we add the new places as the admin_centre of their 
>>>> matching administrative relations (lga/ward...) or is it
>>>> part of another next process ?
>>>> Paul
>>>> Paul MALLET
>>>> 2014-07-15 18:12 GMT+02:00 Rafael Avila Coya 
>>>> <ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>
> <mailto:ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>>
>>> <mailto:ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>
> <mailto:ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>>>
>>>> <mailto:ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>
> <mailto:ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>>
>> <mailto:ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>
> <mailto:ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>>>>>:
>>>> The HOT Tasking Manager for the import of places (towns, 
>>>> villages and urban suburbs/quarters) is ready [1].
>>>> We advice ONLY EXPERIENCED MAPPERS to take part in this job.
>>>> Prior to start importing the data, it's COMPULSORY TO READ
>>>> AND FULLY UNDERSTAND the import wiki [2] and, specially, the 
>>>> Should you have any further questions, you can contact 
>>>> mapping_at_ehealthafrica_dot_org or myself.
>>>> Cheers and happy mapping,
>>>> Rafael Ávila Coya.
>>>> [1] http://tasks.hotosm.org/job/581 [2]
> https://wiki.openstreetmap.org/wiki/Import_Nigeria_eHealth_Africa_Places
>>> [3]
> https://wiki.openstreetmap.org/wiki/Import_Nigeria_eHealth_Africa_Places_Workflow
>>>> _______________________________________________ HOT mailing 
>>>> list HOT at openstreetmap.org <mailto:HOT at openstreetmap.org>
> <mailto:HOT at openstreetmap.org <mailto:HOT at openstreetmap.org>>
>> <mailto:HOT at openstreetmap.org <mailto:HOT at openstreetmap.org>
> <mailto:HOT at openstreetmap.org <mailto:HOT at openstreetmap.org>>>
>>> <mailto:HOT at openstreetmap.org <mailto:HOT at openstreetmap.org>
> <mailto:HOT at openstreetmap.org <mailto:HOT at openstreetmap.org>>
>> <mailto:HOT at openstreetmap.org <mailto:HOT at openstreetmap.org>
> <mailto:HOT at openstreetmap.org <mailto:HOT at openstreetmap.org>>>>
>>>> https://lists.openstreetmap.org/listinfo/hot

- -- 
Twitter: http://twitter.com/ravilacoya

- --------------------------------

Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.

Atendendo á lexislación vixente, empregue formatos estándares e abertos.

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/


More information about the HOT mailing list