[Imports] Best practices for address imports

Frederik Ramm frederik at remote.org
Sun Nov 24 20:40:16 UTC 2013


Carol,

   maybe we're suffering from a trans-atlantic word defintion problem
here. When I say "community" I always, exclusively, mean the OSM
community - not "the community of people living in one house block or
one village or city quarter or town" or anything else.

Everyone can of course be (or become) part of the (OSM) community. But
in terms like "community import" we're never meaning to say "an import
done by some community of people" but "an import done by the OSM community".

Maybe that was clear already, I wasn't sure.

>   * How OSM defines a local community? Opinions have been thrown out by
>     individuals but this needs to be defined by the community and
>     clearly stated.

This is very difficult to define and clearly state. I think that it
might be possible to find a "guideline" but it is likely that in the end
someone will have to make a call.

>   * What does OSM define as a legitimate OSM community member? Opinions
>     have been thrown out by individuals but this needs to be defined by
>     the community and clearly stated.

This is also difficult, although when talking about who should be
involved in imports we could simply say that you need so and so much
time with OSM and so and so many 1000 manual edits before you can
participate in an import, without telling those that don't meet the
criteria that they are "not legitimate community members".

>   * If local community mappers (GIS, OSM, etc...) make a decision to add
>     data to their map

Compare to what I said above - only the local OSM mappers can make a
decision to add data to OSM. Members of other local communities who are
not OSM community members might add data to "their" map at liberty, but
"their" map is not the OSM map.

You don't have a claim to OSM just because you live in a place or do GIS
in a place - you can only have a claim to OSM if you participate in OSM.

>     how much influence does OSM really want to have
>     on what is considered correct use of OSM for that local community

We had that discussion a lot in the past. To a certain degree, I think
the project should allow local people to shoot themselves in the foot,
make mistakes, learn from them, etc., however if a local group somewhere
makes a decision that is considered harmful and where others elsewhere
have already experienced the negative consequences, I think the locals
should at least be able to demonstrate why their case is going to be
different.

I think it also makes a difference just how local the group is and how
much data we're talking about - remember that we don't yet have local
databases. If a local group were setting up their own OSM-cloned
database of course they could do whatever they wanted. In the distant
future, we might indeed get there - OSM as a cluster of linked local
databases where local people make their own decisions.

Btw. this also works the other way round - not only "how much can OSM as
a global project dictate to a national/local OSM community" but also (we
had that too) "how much can the OSM community in one country dictate to
regional groups in that country" (e.g. countries with culturally
disjunct areas where people would like to make their own decisions).

>   * What is the OSM community and who does it really support since it
>     does seem to be highly selective in who it gives the import hall
>     pass to?

I think if you really want to be constructive about this in the future,
you need to get over your own failed import. I can sense that you're
still grumbling about the fierce central command which is unfairly
highly selective about who their friends are, and that you're still in
battle mode trying to find fault with, and improve, the system, or
others. Bury that hatchet now or you'll find it extremely hard to
acquire a balanced and sober view.

>     if the OSM admins determine
>     that imports should not be done by anyone, then say so. It will save
>     us all a lot of "heartache and rejection."

I think that imports are mostly undesirable but at the same time
inevitable. Much like a country can't win a "war on drugs", the OSM
admins could never win a "war on imports" even if they declared it. Just
as drugs can be good but aren't in the wrong hands, so are imports. What
we need to do is make it clear to people that a life without imports is
possible, but if they decide to do imports nonetheless, at least make
sure they're not ruining it for themselves and everyone around.

>   * Providing examples of the kind of data sets that would be considered
>     as valuable additions to the main map and which would not be
>     considered appropriate for the main map.

I think a much bigger and more rewarding issue would be to demonstrate
clearly to people that data doesn't have to be in OSM in order to be
used/useful.

What we currently have is someone playing with OSM, finding out how
great and easy it is to have access to pre-rendered tiles and Overpass
API database requests and easy planet file downloads and whatnot. Then
they find that their county lacks building outlines. Then they find the
building shape file on their county's GIS web site. And the first thing
they ask is: HOW DO I GET THIS INTO OSM? - When indeed all they want is
a convenient slippy map that shows OSM data plus the county GIS building
outlines (or so).

And currently they're right - dumping anything into OSM is often an easy
way to make it accessible in the form you want to access it. If we
managed to work on that front - to provide easy tools for people to e.g.
throw a shape file onto OSM and make both visible together without
importing - then the whole import question would lose much of its urgency.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"



More information about the Imports mailing list