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

Jo winfixit at gmail.com
Thu Jan 9 01:07:31 UTC 2014


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>

> 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  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20140109/9cdf0e12/attachment.html>


More information about the Imports mailing list