[OSM-talk] Organizational mapping policy

Fri Jun 20 19:47:02 UTC 2014

<The DWG has seen some what we're calling "organized mapping" which we
can generally define as a set of mappers being directed or working on
behalf of an organization.>

Thanks for your explanation Serge. I'm very glad to have community members
willing to spent their voluntarily time in the DWG to take on the sometimes
difficult job to solve conflicts. However, I don't think it's a good idear
that the DWG can decide on policies/guidelines/requirements etcetera
because it's the same DWG that uses these policies/guidelines/requirements
for enforcing. The solution for that is simple: have a LWG like process
using a WIKI ánd the OSMF setting these policies/guidelines/requirements,
for example by endorsement. To make a trias politica complete OSM could
need one ore two wise, preferrably grey-haired men or women when a mapper
does not agree on a decision by the DWG.

That said, having rules/guidelines/requirements and things like a mission,
a vision, goals and core values could help our community getting further.
Since IMHO OSM is quite far from growing into that, a way to grow is just
by managing incidents.

As I've read there has been some discussion on the NYC building import,
where Mapbox used paid mappers and not involving the local community the
right way. It might be that the DWG refers to that incident, seeing this
type of action as a threat to OSM, and wanting to regulate that. Though we
already have an import policy, do you mean that the import policy needs to
be revised?
As broadly as you describe it, you could also be implying a policy onto
HOT. For example, I have been armchair mapping in the Philippines, trying
to do my best using sometimes bad satellite imagery (cloudy) to map roads
in the Tacloban area. Or it could have also been tracks (difficulty to see
sometimes), whereby I tried to use a tracktype which I'm sure was not
always correct all the time. HOT is a larger organization, and I was not
directly working for HOT but by using the tasking manager I was a remote
mapper.
You could also mean Maproulette, which seems to be a nice tool (I've never
used it) but which also promotes armchair mapping. And what about quality
assurance tools: even when they are not signalling things right some
mappers desperately want to solve any warning/error they come up with.
An organization could also be seen wider as a local community. Because of
the release of open address data in the Netherlands several people already
uploaded some areas without consulting the community about a standardized
tagging method. That was harmonized in the import process, but I believe
Frederik finds our import sloppy because we're using three tags (one of
them continuously used for tracking the progress of the import, another one
used for updating already imported data) he would not like to see.

In a post yesterday Frederik described that sometimes judgement is needed
in tagging. He's right on that one. As complexity tends to grow in OSM,
mapping might/will become increasingly difficult in OSM. A risk is that
sloppy mapping will occur more and more. There is a way to solve that:
using Google's method by having every change authorized. Though I not
favour that system, it is a solution to keep our database clean.

Of course you can reply saying I'm exaggerating. But is the DWG proposal
meant to tackle Mapbox? Is it meant to regulate HOT or other NGO's? Is it
meant for mapping parties or universities where people are instructed to
spread out and tag some places in a manner as prescribed by the instructor?

And let's not forget that any rule also has to enforced: it's for example
for a government not difficult to set maximumspeeds on roads. It's already
a bit more difficult to communicate these maximumspeeds in a proper way to
car drivers. And it's way more difficult for police to enforce these
maximumspeeds. Another problem with rules: they raise the bar for mapping.
What if Shell would come by, communicating with the community about the
best way to maintain all Shell fuel stations in OSM worldwide. Should we
regard that as as threat ('no, Shell is bad, they will hurt the community,
luckily we have policies to keep them out'), or should we see it as a
opportunity ('hey, Shell wants to be a part of our community'). I like
thinking in opportunities instead of threats: getting companies like Shell
in could solve a lot of bad data in OSM: missing fuel stations.

I'm sorry to say, but the potential/present/future problem for which the
proposed DWG policy/requirement should be a solution is still not very
clear to me. Though I'm very willing to help writing on something that
encourages any organization, professional or not, to help OSM further in a
proper way: the core values are there for all mappers.

Cheers, Johan

2014-06-20 14:25 GMT+02:00 Serge Wroclawski <emacsen at gmail.com>:

> To elaborate on what Frederik said a bit...
>
> The DWG has seen some what we're calling "organized mapping" which we
> can generally define as a set of mappers being directed or working on
> behalf of an organization.
>
> The difference between what OSM experienced and what Wikipedia
> experiences regarding paid contributors is a bit different, so I'll
> elaborate on this a bit.
>
> For Wikipedia the issue is really about independence. If I work for
> GloboChem and write in Wikipedia that GloboChem has a wonderful
> environmental reputation, there's an issue of bias and possibly truth.
>
> That's not the kind of thing we're seeing or thinking about. Instead,
> we're seeing issues like:
>
> 1. One mapper (on behalf of an organization) mapping in a very sloppy
> way. This might be something like extranious nodes, disconnected roads
> or broken relations. These aren't necessarily wrong in the sense of
> vandalism, but they may not be correct either.
>
> 2. If you ask the mapper about what's going on, they don't answer.
>
> 3. You might see more than one account doing the same type of mapping
>
> 4. The DWG has to find the "responsible party" on their own because #2
> and #3. This is not always easy, and it's often time consuming.
>
> 5. If the DWG sees that there's a lot of problems being caused by #1
> or perhaps something more extreme, then even if we are able to get
> through to a single mapper, other accounts (that turn out to be from
> the same organization, though not necessarily the same person)
> continue the same
> problematic mapping activity in the same style
>
> 6. Organizations differ in how they want to be communicated with. Some
> want us to treat them as a single entity and use some external
> communication tool (ie not OSM messaging), while others want us to
> treat mappers as individuals, and sometimes they want both, depending
> on the context. This complexity puts a burden on the DWG to find the
> right communication channel for each mapper in each context, using up
> our volunteer time and resources.
>
> 7. Once a problem has been identified, it's often difficult to get the
> individual or organization to take ownership of the problem and
> especially to fix previous mistakes.
>
> 8. It's not infrequent for these organizations to be using remote
> mappers, so sometimes you will see things mapped how they think they
> should look based on where they live/how the imagery looks rather than
> the on the ground truth. This gets more complicared when conflicts
> arise between these remote mappers and existing mapped data from local
> contributors. It's not a matter of vandalism, because it's not
> malicious, but it can be hard to figure out the right way forward in
> these situations.
>
> The proposal, which was relatively modest IMHO, mainly focued around
> the issue of transparency, making it easier to identify when a mapper
> is working on behalf of a larger organization, and if they are, the
> best way to communicate with the organization. In my opinion this
> would benefit all of OSM, especially our concerned users who come to
> the DWG with these complaints. It would probably end up reducing or
> eliminating the need for DWG involvement in many cases.
>
> As Frederik implied, for some reason the discussion on this turned
> quite bitter. I think it's inevitable that we'll have to address this
> topic, but I get the impression that parts of our community aren't
> ready to address this topic yet.
>
> - Serge
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20140620/b4ab02d7/attachment.html>