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

Frederik Ramm frederik at remote.org
Wed Jan 8 23:24:02 UTC 2014


   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).

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.

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.").

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.


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"

More information about the Imports mailing list