[Imports-us] [Imports] Best practices for address imports

Sun Nov 24 20:02:43 UTC 2013

Import and Import-US group members,

I've been thinking after writing my last response in this thread. Since we
are talking about best practices in this thread, we still haven't gotten
any closer to clearly defining many things that are governed by the Imports
and Imports-US groups. I've been remaining silent in the hopes that more
would come out of the conversations we had earlier in the month. However, I
am still paying attention to the issues concerning OSM data imports and the
culture of this community. I do hope to be able to make the next Import-US
hangout meeting and regret that I couldn't meet you all in the last one.

What I've seen that is HUGE progress:

   - Acknowledgement from the OSM-US board that changes should be made to
   make the guidelines and process of importing more consistent and
   understandable as a resource for new and veteran mappers.
   - The work Jason (and others) have done with the Import Guidelines
   page.This is a great improvement over what has been on this page in the
   past. Thank you for this.
   - Effort to put together an outline for those interested in importing
   data into OSM that Serge drafted.
   - There are likely many more efforts and discussions in the background
   that have not been announced and I'd like to thank everyone who has
   participated.

An observation on the guidelines page that I'd like to make is that it
implies strongly that importing is a counter effort to mapping parties when
these do not always need to be viewed as mutually exclusive activities
especially if you consider those in GIS, including those in local
government offices who control and maintain local community data, to be
part of the local communities and also would like to be involved in the OSM
project. This divide does not need to exist though I can see where it might
often be the case. Maybe we can change that! Also, what criteria need to be
met for local community buy-in? How many local communities members need to
be asked before this is considered accepted?

I've been following some of the recent import requests and there seems to
be the same issues cropping up. These are things that still have not been
adequately defined by those commanding the import process:

   - 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.
   - 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.
   - If local community mappers (GIS, OSM, etc...) make a decision to add
   data to their map, how much influence does OSM really want to have on what
   is considered correct use of OSM for that local community if the OSM
   "ambassadors" do not live in that area?
   - 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?
   - When talking about best practices, the responsibility should not be
   exclusively put on the importer but also on those commanding the import
   process on the OSM administrative side. Being this is an open source
   friendly community, can we have more transparency from the OSM side of the
   import process? Currently, more effort seems to be put into keeping it
   ambiguous, scary, and simply talking people out of it than actually
   defining a clearer process for how this could work for all parties
   involved. Again, 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."
   - 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. By not having this information available, OSM
   sets itself up for conflict where there doesn't necessarily need to be. If
   you don't let people know what you do and don't want, don't be surprised
   what they bring to the table.

Frederik: I appreciate you defining some of the terms I asked about. I'd
like to follow up on that with some more questions if you don't mind.

A *community importer* is a person who works either as an individual or
within a team of community importers. Community importers have an intimate
knowledge of the *local community* (neighborhood, city, county, state,
etc...) in which they are uploading data and ideally are local community
members of that local community. Either individually or as a team,
community importers apply a systematic approach to uploading datasets in
clusters or groupings (*manual import*) rather than uploading an entire
dataset at one time (*automated import*).

^^Would this make an adequate definition for what you described in your
email?

-Carol

-------------------------------------
Carol Kraemer
North River Geographic Systems, Inc
http://www.northrivergeographic.com
404.431.0125 cakraemer at northrivergeographic.com

On Sun, Nov 24, 2013 at 2:09 PM, Frederik Ramm <frederik at remote.org> wrote:

> Hi,
>
> On 24.11.2013 19:18, Carol Kraemer wrote:
> > Can we get definitions for "manual community import,"
>
> A community import is one where the import is not done by one central
> entity but small parcels of the data-to-be-imported are made available
> for individual community members to tackle as they see fit, in their own
> time, in areas they are familiar with, and where they will be expected
> to check imported data, comparing it to their own knowledge of the area
> and other suitable data sources they are familiar with from their prior
> mapping practice.
>
> A community import doesn't have a fixed timeline and relies on the
> enthusiasm of individuals to get it done, and because familiarity with
> the area is required, even the most enthusiastic individual will not be
> able to do everything by themselves.
>
> Any mapper can be a "community importer" but you would normally be
> expected to have prior OSM experience to participate. Someone who has
> just joined OSM to participate in a community import will face a very
> steep learning curve and unless they are very good & diligent this might
> defeat the purpose of a community import.
>
> In a community import, the individual who imports a parcel of data takes
> (a certain degree of) responsibility for the uploaded content. This
> means that if challenged later about the content of the import, the
> uploader cannot say:
>
> "Don't ask me, I just grabbed this parcel of data that Fred hat provided
> on his download page and loaded it up in JOSM!"
>
> and neither
>
> "Don't ask me, this is just the county's building footprints as they
> were published, why would I know about that peculiar cluster of
> buildings there?"
>
> Because the data has been reviewed and checked by the uploader before
> uploading, they will usually have noticed any peculiarities, and fixed
> problems before they hit "upload".
>
> As a consequence, to achieve the same throughput (in terms of time
> needed to import a certain number of objects), a community import will
> have to enlist much more participants than a scripted import by a
> central entity, but will also make sure that many more eyeballs are
> involved to make sure the data isn't rubbish.
>
> A comunity import isn't necessarily good but it has a better chance to
> be good than an automated import.
>
> Both types of imports require detailed prior discussion and consultation.
>
> 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-us/attachments/20131124/f8fa4efd/attachment.html>