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

Thu Jan 9 10:37:47 UTC 2014

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

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.

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

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

Rafael.

On 09/01/14 02:07, Jo wrote:
> If there is data in your source that you want to pass on to the people
> who are going to import/integrate it into Openstreetmap, you can use
> tags like
> 
> odbl
> created_by
> 
> and such. These are tags which JOSM will silently remove before
> uploading the data. So they will not end up in the OSM DB, but your crew
> has them available to do cross checks.
> 
> You can use MAPCSS to make them visible more prominently during your
> edit session.
> 
> I hope this helps. (Maybe JOSM could be expanded to have tags dedicated
> for this purpose, say an import: namespace and maybe it would be a good
> idea to be able to tag objects with upload=no, so JOSM refuses to upload
> them when they have not been verified. But that's for another mailing
> list...)
> 
> Jo
> 
> 
> 2014/1/9 Frederik Ramm <frederik at remote.org <mailto:frederik at remote.org>>
> 
>     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).
> 
>     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.
> 
>     Bye
>     Frederik
> 
>     --
>     Frederik Ramm  ##  eMail frederik at remote.org
>     <mailto:frederik at remote.org>  ##  N49°00'09" E008°23'33"
> 
>     _______________________________________________
>     Imports mailing list
>     Imports at openstreetmap.org <mailto:Imports at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/imports
> 
> 
> 
> 
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
> 

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

http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros