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

Bryce Nesbitt bryce2 at obviously.com
Sat Jan 25 18:36:45 UTC 2014

On Sat, Jan 25, 2014 at 2:23 AM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
>> Am 25/gen/2014 um 10:05 schrieb Bryce Nesbitt <bryce2 at obviously.com>:
>> I would leave the source=Unicef tag in place.
> most mappers do this, that's the reason why you can't trust source tags on objects ;-)
> cheers,
> Martin

I don't "trust" source tags.  Source tags give me a flavor for where
data came from, but just that.
Nothing in OSM is "trustable": if anything my goal is to "verify".

I find source tags on objects provide interesting and relevant context
when editing.  Even the somewhat
useless "source=bing" tags are useful: I get a sense that was an
armchair edit and I'm more likely to
take a heavy hand if I have local knowledge.  "source=survey" and I'll
take greater care figuring one or more prior mapper probably knows
something not visible from the air.  If there's a tiger:tlid or
tiger:cfcc I know i have Tiger data that is probably wrong.
"source=osmsync" or "source=Lowes Home Stores" and maybe it's a
database sync.  "source=unicef" and I might dig around
and figure out if there's a master list somewhere.

"source:pkey" or any other primary key and I'll know for sure there's
an external database somewhere
and a possibility of a two way sync.  Two way fuzzy sync is an
important future capability for OSM as databases get better and more
authoritative and the number of objects exceeds the ability of hand
mappers to verify them all.

Maybe if most tools automatically showed a sidebar with the changeset,
it would reduce the utility of a source tag on the object.  But right
now I'd rather have source= than not.  Removing it sounds like a great
way to shave a lot of utility in the name of saving 15 or so bytes per

More information about the Imports mailing list