[Imports] Import UNICEF data in Central African Republic, act II

Rafael Avila Coya ravilacoya at gmail.com
Tue Jan 14 01:33:26 UTC 2014

Hi, Séverin and all:

To avoid exceeding those 40kb, I will delete those lines that aren't
interesting for this my answer.

> ---------- Forwarded message ---------- From: *Severin MENARD*
> <severin.menard at gmail.com <mailto:severin.menard at gmail.com>> Date:
> Thu, Jan 9, 2014 at 3:14 PM Subject: Import UNICEF data in Central
> African Republic, act II To: "imports at openstreetmap.org
> <mailto:imports at openstreetmap.org>" <imports at openstreetmap.org
> <mailto:imports at openstreetmap.org>>
> Hi,
> Thank you all for your quick answers, my comments inline
> Today's Topics:
> 1. Re: Import UNICEF data in Central African Republic, act II 
> (Frederik Ramm) 2. Re: Import UNICEF data in Central African
> Republic, act II (Jo) 3. Re: Import UNICEF data in Central African
> Republic, act II (Rafael Avila Coya) 4. Re: Import UNICEF data in
> Central African Republic, act II (Jo)
> ----------------------------------------------------------------------
>  Message: 1 Date: Thu, 09 Jan 2014 00:24:02 +0100 From: Frederik
> Ramm <frederik at remote.org <mailto:frederik at remote.org>> To:
> imports at openstreetmap.org <mailto:imports at openstreetmap.org> 
> Subject: Re: [Imports] Import UNICEF data in Central African
> Republic, act II Message-ID: <52CDDE12.9030903 at remote.org 
> <mailto:52CDDE12.9030903 at remote.org>> Content-Type: text/plain;
> charset=ISO-8859-1
> Sev,
> I don't see big issues with your proposed import. The page on
> schools has a tag value of "uncomplete" where I'd guess that
> "incomplete" would be a better term but I'm not a subject matter
> expert.
> What strikes me that in your explanation, you seem to ask for
> special treatment because "this is for humanitarian purposes" -
> quotes:
> On 08.01.2014 23:34, Severin MENARD wrote:
>> Please keep in mind it deals with humanitarian data in a big
>> crisis context, so it is important to have the possibility to
>> cross checked facilities incorrectly located
> ...
>> therefore it is a very light dataset and adding a few tags
>> really useful for data control, considering its humanitarian
>> ground,
> would only
>> represent a few more Kb.
> You seem to be of the opinion that because this is "humanitarian"
> we should be lenient - but I think the opposite is the case. As HOT
> - a group of people who have been doing various imports for a long
> time and will doubtlessly continue to do so - you have to be a
> shining example to everyone else. You, of all people, are expected
> to "do things right", and other people will look at your imports
> and say: If people who do so many imports do <X> then it must be
> the right thing to do. You've already done a very good job at
> documenting the import procedure on the Wiki (this is indeed a very
> good example to others).
> No, I never asked the import group to be lenient. I was mostly 
> complaining about the fact the import having been stopped in 24
> hours while it took quite more time to get an answer to the
> explanations I provided without a real discussion to start. Happy
> this is the case now, but it could have been quicker (not lenient),
> regarding the humanitarian purpose.
> Regarding the sentence you quoted, I wanted to stress the
> importance to have control check for humanitarian data, like an
> original source tag and supposed admin level, so if ever someone
> doing the import makes a mistake, the final user to have some
> metadata for each object. Therefore I would not say lenient, but
> adapted and useful.
> That's why I'm happy that you're starting this discussion just like
> we'd expect from anyone else making an import.
> The two issues you mention in your email, source tag on every
> object and named admin units tagged with every object, are indeed
> unusual.
> The problem with source tags is that they only tell part of the
> truth - if you import a hospital from UNICEF and someone later
> changes it then they will likely forget to remove or amend the
> source tag. A source tag on the changeset makes this more clear.
> Except it will not appear in any GIS format. What about a tag
> mentioning the original source? Another point to have in mind:
> field data collection in CAR are rare, and the country
> practicability becomes quite hard, so it should not be updated on a
> very regular basis.

I agree in that having a source=UNICEF for each imported item is very
useful and convenient for GIS use after the import, and not a big
issue about other users forgetting to amend it in the future for a
country like CAR. The source tag will be in the changeset and in the
history of all the nodes too, so the solution of having the source in,
both the changeset and the nodes, is, IMHO, the most convenient for
this particular import.

> I understand your admin level explanation but I don't think it is 
> sufficient reason for adding the highly unusual three "is-in" type
> of tags that you are proposing. I wonder how addresses in CAR are 
> constructed - is it possible that the correct postal address for a 
> location like that might be "XYZ Hospital, Adminarea 3, Adminarea
> 2, Adminarea 1, CAR" or so? In which case a potential compromise
> could be using the addr:full tag (Wiki: "Use this for a full-text,
> often multi-line, address if you find the structured address fields
> unsuitable for denoting the address of this particular
> location.").
> This is a good idea, if everyone agrees I change the wikipages to 
> reflect that
> Lastly, I too think the "fixme" should be dropped, because doing
> an import with "fixme" tags gives the impression that it is ok to
> import half-baked data for others to fix - something we're doing
> everything to avoid, and your documented import procedure makes it
> clear enough that you expect importing users to curate the data as
> required.
> I already dropped it
> Bye Frederik
> ------------------------------
> Message: 3 Date: Thu, 09 Jan 2014 11:37:47 +0100 From: Rafael Avila
> Coya <ravilacoya at gmail.com <mailto:ravilacoya at gmail.com>> To:
> imports at openstreetmap.org <mailto:imports at openstreetmap.org> 
> Subject: Re: [Imports] Import UNICEF data in Central African
> Republic, act II Message-ID: <52CE7BFB.7000002 at gmail.com 
> <mailto:52CE7BFB.7000002 at gmail.com>> Content-Type: text/plain;
> charset=ISO-8859-1
> Hi S?verin and all:
> I agree with Frederik about the use of addr:full instead of the 
> boundary_admin_levelX_name tags  (I would change "CAR" at the end
> of the full address for "R?publique centrafricaine" or "Central
> African Republic"). I think it's a smarter solution: 1 tag instead
> of 3, and a tag that is fully accepted by all.
> I wonder if the data available at this time through the HOT task
> manager will be changed or not to incorporate these changes to the
> import.
> Sure it will be changed to reflect all the decision made on this
> thread
> In case you change the data for the rest of the import process, I
> would add some improvements that I already suggested in past
> emails, so we avoid having to correct them afterwards (in case we
> want):
> 1) Some schools have the 'capacity:classrooms', 'capacity:pupils'
> and 'capacity:teachers' with value "0". I would set it better to
> "unknown" value, as it makes more sense (for the
> capacity:classrooms one at least, as there is surely no school
> without any classroom in it).
> Good idea, we will change this
> 2) I find operator=yes/no not appropiate. As we read in the
> key:operator wiki ( http://wiki.openstreetmap.org/wiki/Key:operator
> ), "the operator tag is used to name a company, corporation, person
> or any other entity who is in charge of the operation of a certain
> map object". But "yes" or "no" aren't any entity themselves. I
> think it would be more appropiate to change it to operated=yes/no,
> maintained=yes/no, manned=yes/no or something similar. I would
> suggest the tagged "maintained". The only issue: these tags are not
> widely accepted tags, as it is the operator tag.
> the original field is COMITE_GES (= COMITE GESTION) that means 
> management committee, and the values are yes or no. What would fit
> the most?

About the operator tag, I've found a suitable one that is already in
use (accepted by the community (
http://taginfo.openstreetmap.org/keys/?key=managed )): managed=yes/no.
It fits perfectly with our purpose of translating COMITE GESTION
(management committee). And I don't see any problem on the key:managed
being used mainly for natural areas, as they state in the key wiki ( (
http://wiki.openstreetmap.org/wiki/Key:managed ) ). The key:managed
would be better than key:operated, key:maintained or key:manned that I
suggested before, because those keys are not in common use as the

> 3) Again, in case the data is updated to incorporate the changes
> for this import, I would correct the following typos for the
> health facilities import:
> operator:type instead of operator_type toilets:number instead of
> toilets_number capacity:beds instead of capacity_beds 
> health_facility:type instead of health_facility_type addr:city
> instead of addr_city
> Has been done in the wiki (and will be implemented in the TM as
> well). DO you see remaining ones?

I don't see any typo like that remaining in the wiki. But (at least)
for the water facilities import I've seen a (in my opinion very
convenient) tag, addr:ward, that is not documented yet in the wikis. I
wonder if any health node has this tag included; I didn't see it for
any health facility in the two task tiles I did the import in the
Bérberati city.

Whenever I got one node like that in the Bérberati city, I used that
info to add a place=suburb node near it, because I thought it was the
most correct tagging. But I think this should be agreed upon and then
documented in the wiki, to avoid having inconsistencies.

> I know we can correct that with a script or by hand afterwards, but
> what if, in the mean time, somebody makes and improvement like
> tracing the area of the hospital, copy/pasting the data from the
> hospital node to the new area or relation and deleting the node?
> The same would be true for schools (much less probable for water
> facilities).
> Hmm this is another discussion. Frankly I prefer to have the
> global attributes on one node in the middle of the compound. Why
> not create also a relation between it, the buildings, the landuse
> and other objects like related water points but it is basically
> time consuming, it would be far from being an world standard as
> many mappers are not skilled enough in OSM techniques to do this,
> and it does not provide much extra value. Moreover it would require
> to be in the field to know what are the facility extent and
> involved buildings, what is not obvious at all from imagery in CAR
> context.

No worries. As you said that the data will be corrected/updated for
the continuation of this import, there won't be anything to correct
afterwards, so problem solved.

It's true that the extent of facilities is not obvious sometimes but,
in some cases, seeing the extent of a school in rural areas of Africa
and other developing countries is quite easy, as their buildings are
completely different (long rectangles), and separated from the rest in
a quite open area. But in any case this is not an issue, and it's out
of the scope of the import now.

Finally, about the voting of the different issues that you suggest, I
would do it only in case we can't agree about a certain issue. If I
don't miss anything here, the only one we still have different points
of view is the one about the source in the nodes/changeset one, and
honestly I think we'll end up with a solution we can be all happy, and
be able to proceed with this import that is so important for
humanitarian organizations in the field.



> _______________________________________________ Imports mailing
> list Imports at openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/imports

Twitter: http://twitter.com/ravilacoya


More information about the Imports mailing list