[Local-chapters] Editable Servers

[Richard Weait]

On Sat, Mar 20, 2010 at 2:01 PM, Serge Wroclawski <emacsen at gmail.com> wrote:
> We had a productive meeting today but one issue wasn't able to be
> resolved, so we discussed bringing it up on the list.

I've been watching discussions around the foundation and local
chapters with interest but from a distance.  I haven't felt the need
for a local chapter for me but don't feel that I need to get in the
way of others with an interest in local chapters. So that's the angle
from which I'm watching.  It colours my observations.

> The crux of the matter is the wording in the Chapter Agreement that says:
>
> "The chapter may however operate a clone of the database for running
> its own tile-server or any other service that makes use of the data
> (and is not editing the data)."
>
> The general consensus of the meeting was that this wording is to
> ensure that there is a single unified dataset. I agree that having a
> single dataset that's "OpenStreetMap" is a good thing.

Indeed.  I asked a postgres developer about "remote live masters" in
the context of databases.  Apparently that is a Really Hard Problem.

> The problem the wording imposes, though, is multifaceted, so I'm going
> to break down the objections raised by the US group:
>
> * Changeset-capable servers allow us to make updates to OSM
>
> One of the things that makes the US somewhat lucky is that we've been
> approached by government agencies who are genuinely interested in OSM.
> They really want to make it easy to get their data in OSM.
>
> To that end, we've been working on a variety of approaches to allow
> that to happen, from improved shapefile conversion tools, to
> discussions on ways to break up import reviews, to discussions of
> fully automated mechanisms to create diffs between versions when
> governments provide us new datasets.
>
> With such a tool, when the municipality gives us a new dataset, we
> could potentially create an changeset automatically, then push that
> back upstream.
>
> This provision would prohibit that, and that's bad for OSM.

Remote servers and disconnected editing have a proud history in OSM.
I'd be surprised if the Foundation were to now take a position
against:

Mapping the Isle of Man.  - IIRC, this was done by two foundation
board members and another prominent, long-time OSMer.  They mapped
Isle of Man on their own, local server, offered the data to a company,
then contributed the data to OSM.  The data collection had to be
isolated from the OSM servers until after discussion with the company,
otherwise license options for the company would have been limited to
cc-by-sa.

Mapping Palestine - IIRC this was done on local hardware / database,
then contributed to OSM.

RoadMatcher / OpenJUMP - used live OSM data to detect overlaps in
potential imports when preparing bulk uploads.

Mapping Kibera - IIRC this was / is done using local hardware, then
contributed to OSM.

French community Corine data import -  The Corine data was rendered
locally, then examined object by object and considered for import to
OSM.

Each of these involves staging and / or visualizing data before
submission to OSM and each met with positive reactions from the OSM
community.  I don't recall any objections to the projects above due to
the external servers.  Some of these may pre-date API 0.6 and
changesets, but each involved editing locally, before contributing to
the real OSM data set.  Again, all IIRC.  Patches welcome.

Perhaps the Foundation can clarify?

> * Editable servers open doors
>
> One of the other potential avenues of work in the US is the desire by
> some groups (including governments) to run their own crowdsourced
> dataset. They can't use OSM itself because they often want to provide
> the data under a different license- either public domain or something
> very permissive.
>
> Of course they can do this themselves. The town of Springfield could
> stand up their own custom instance of OSM and then provide editing. Of
> course it would be "closed loop", but if the data were public domain,
> we could feel legally free to slurp it into OSM. But for that, again,
> we need something that can generate changesets and push them upstream.

Merges on a large scale are an exercise left for the student.  I don't
think that this has been solved yet.