[Imports] [HOT] CAR Activation; experienced mappers to finish the import of UNICEF data?

Jorieke Vyncke jorieke.vyncke at gmail.com
Wed Jan 8 12:19:21 UTC 2014

Hi all,

Severin first of all, thank you for all the effort you put in the import of
the UNICEF data!! I truly believe this import is really imortant for the
people of this country right now!  If you just follow twitter a little bit
you immediatly notice how severe the situation is overthere right now

I hope this import can be continued as soon as possible, also because the
Senegalese community, and probably even bigger, more countries in west and
central Africa (Togo, Burkina Faso, ...) are planning to organise a kind of
"mapping for the Central African Republic" next weeks. And I was hoping we
could participate in the import with the more experienced mappers overhere.
So I hope together with Séverin that this data import can be continued as
soon as possible!

All the best,


2014/1/8 Severin MENARD <severin.menard at gmail.com>

> Paul,
> I took you only 24 hours in December to stop this import. I would
> appreciate the same speed to help us solving the issue(s) you identified
> for this import that has humanitarian benefits. Can you please answer to my
> last email  in order we fix the tags and proceed again?
> Sincerely,
> Severin
> On Sun, Jan 5, 2014 at 11:06 AM, Severin MENARD <severin.menard at gmail.com>wrote:
>>> Date: Fri, 3 Jan 2014 11:27:16 -0800
>>> From: "Paul Norman" <penorman at mac.com>
>>> To: "'Severin MENARD'" <severin.menard at gmail.com>
>>> Cc: imports at openstreetmap.org, hot at openstreetmap.org
>>> Subject: Re: [Imports] [HOT] CAR Activation;    experienced mappers to
>>>         finish the import of UNICEF data?
>>> Message-ID: <17c601cf08b9$d0773900$7165ab00$@mac.com>
>>> Content-Type: text/plain;       charset="us-ascii"
>>> > From: Severin MENARD [mailto:severin.menard at gmail.com]
>>> > Sent: Wednesday, December 25, 2013 3:22 PM
>>> > To: Paul Norman
>>> > Subject: Re: [HOT] CAR Activation; experienced mappers to finish the
>>> import of UNICEF data?
>>> >
>>> > Hi Paul,
>>> >
>>> > 1. Health Facilities
>>> >
>>> > The fixme for longitude,latitude was proposed from the first version,
>>> > dated April 5.
>>> The general view is that fixme tags should not be mechanically created,
>>> and tags should not duplicate geodata. Similarily, tags like lat and
>>> long do not belong.
>> Once again was proposed from the very first version of the import, so I
>> hope this is not part of the reasons that made you block this import. As
>> explained for source and admin levels, this is used to have and make people
>> (remotely or in the field) able to cross check what the import user would
>> have done. Geodata is not very important, so you find it intolerable, we
>> put it away.
>>> > Differences I see are:
>>> > * source:UNICEF,2012 is tagged per object. Wold be really interesting
>>> to
>>> >   have such a tag as a minimum of metadata, but I know that, IMHO
>>> >   unfortunately, the trend is to put a source tag to the changeset
>>> (good
>>> >   idea, but of course only if everything in the changeset comes from
>>> the
>>> >   same source) and remove any source tag per object (very regretful for
>>> >   the metadata by object; means almost any OSM data extract another
>>> >   formats will not have any source for the data)
>>> If you want to change the import to include source tags, that needs to
>>> be discussed.
>> So let us discuss, please. I put all the arguments.
>>> > * typo identified by edvac with _ intead of : . Super easy to change
>>> and
>>> >   to correct from the data already imported. Just one question: such
>>> >   correction on data already on OSM should be done with a OSM import
>>> >   account or a normal one?
>>> If you're thinking of the addr:city tag, I'd do it with the same account
>>> used for the import.
>> OK issue resolved, I will proceed this way.
>>> > 2. Education facilities and Water facilities
>>> >
>>> > The fixme for longitude,latitude was proposed from the first version,
>>> > dated April 5.
>>> > Differences I see are:
>>> >
>>> > * admin level 1, 2, 3 informed by UNICEF for each object were not
>>> >   present in the proposition. Actually the first imports showed they
>>> are
>>> >   really interesting for quality check. Is this OK to put them? What
>>> >   should be the right key?
>>> http://wiki.openstreetmap.org/wiki/Admin_level
>>> >   does not mention a tag for admin level names.
>>> These changes are ones you need to propose and discuss. I'd say that
>>> this information belongs on the appropriate boundary relations, not
>>> on what you're importing.
>> Once again, this is for quality check during and after the imports. When
>> these facilities are located in small villages, it is frequent their names
>> do not exist yet neither in OSM, nor in GNS. So the information in
>> addr:city cannot be cross checked with existing data. I had a few examples
>> of such locations with admin level information totally different of where
>> they were supposed to be. If the someone processing the import misses this,
>> we have potentially a double mistake: the place name and the facility.
>> 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, not only when the import has been done.
>>> > 3. Otherwise, regarding edvac_import "lacking changeset tags as
>>> > described in the consultation", after having checked his 6 changesets
>>> > (see here), I see this problem only once. What is the fix for this?
>>> > Revert te changeset and do the upload again with the changeset tags?
>>> Heh, it figures that that's the one I looked at in more detail. Given
>>> it's
>>> just one, I'd say to leave it.
>> Good
> _______________________________________________
> HOT mailing list
> HOT at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20140108/00079fc7/attachment-0001.html>

More information about the Imports mailing list