[Imports] Imports: technical method & social impact

Emilie Laffray emilie.laffray at gmail.com
Fri Oct 23 11:45:30 BST 2009


2009/10/23 Andy Allan <gravitystorm at gmail.com>

> Hi Sam,
>
> I'm with you on this one. Currently the documentation available (such
> as it is) almost entirely skims over the social aspects - which isn't
> surprising, since it's mainly techies writing technical documentation.
> I hope to do my bit to improve the situation over the next couple of
> weeks.
>
> On this matter, there's at least one script that I've found that both
> converts and uploads at the same time. Is there consensus here that
> such scripts are badly designed? I think it's outdated (can't remember
> offhand) but I'd like to put a warning on it in any case. I think we
> should promote a (social) review step between conversion and upload,
> and splitting the process into discrete tools (conversion tools
> separate from upload tools) I think is also the way forward.
>
> Collective thoughts?
>

I agree 100% with review by the community before importing. We want to make
sure we are not going to deter people from participating. The Corine import
was really a community effort as opposed to a single coder getting hold of
some data and trying to do it alone.
I know I will go back to the Corine import, but the import had two social
review:
- Community review and vote on the tags needed to be used for Corine
- Community review of a mapnik rendering on a test server before importing
to the live server

The second step was very important as it enabled us to fine tune the initial
import and find bugs in the import procedure. The import only happened when
all problems were solved.
In addition, all the data was available between each steps so people could
shout if a problem was found. I will finish the post mortem this week end.
An import like Corine can only happen because the community is behind it and
checking that it is making sense. Also, if it is just a few people playing
with data, we are not engaging the community as a whole. This one of the
reason why the Corine page was translated in English, hoping that we could
attract some external reviews from the French community, since it is an
European database.
Also, the import is now in the community manual import mode: a tool was made
available to the French community to import polygons that didn't make it for
overlap reason. The post mortem will detail the overlap algorithm. I am also
quite aware that we did with Corine cannot be reproduced easily with other
datasets since we didn't have to deal with roads for example, which is a
serious problem for the Canadians.
You can see the website http://osmose.openstreetmap.fr/clc . If you have the
JOSM remote control plugin, this will load the chosen polygon directly in
JOSM. People can then play and modify the polygon accordingly.
I know that for some people the focus should be on mapping parties, but I
believe those kind of tools are allowing people who can't do mapping parties
to participate. The French cadastre had a negative impact on the number of
mapping parties in France, but at the same time, it allowed me to map my
birth place at my leisure which I wouldn't be able to do since I live in
London. My point here is that mass import if done properly with community
review can actually drain some people into OSM, as they probably couldn't
contribute otherwise.

Emilie Laffray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20091023/c856d3cb/attachment.html>


More information about the Imports mailing list