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

Severin MENARD severin.menard at gmail.com
Wed Jan 8 11:21:58 UTC 2014


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?



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20140108/d5039b74/attachment.html>

More information about the Imports mailing list