[OSM-talk] [OSM-legal-talk] In what direction should OSM go?

[Ævar Arnfjörð Bjarmason]

On Wed, Sep 29, 2010 at 15:59, Anthony <osm at inbox.org> wrote:
> On Wed, Sep 29, 2010 at 10:38 AM, Ævar Arnfjörð Bjarmason
> <avarab at gmail.com> wrote:
>> On Wed, Sep 29, 2010 at 13:44, Anthony <osm at inbox.org> wrote:
>>
>>> Of course, if keeping stuff in sync is practically impossible, a good
>>> import is probably going to have to be manual (if you can't keep stuff
>>> in sync, and the data is in a form which is already commonly used for
>>> non-imported data, then you can't avoid redundancies in the import).
>>
>> This is largely a problem with our tools, not something that can't be
>> fixed.
>>
>> Distributed version control systems already solve the problem of
>> merging foreign data where your copy of it has moved since the
>> original import, there's no reason for why we couldn't make keeping
>> imports up-to-date significantly easier using similar techniques.
>>
> I don't know of any "distributed version control systems" which do
> anything remotely close to this.  It seems to me to be an AI-hard
> problem in the general case (*).  There are, of course, tools which
> can do this in specialized cases, but that's where the "if" in the "if
> keeping stuff in sync is practically impossible" comes into place.
>
> (*) In fact, I'd say that anyone who can devise a general tool which
> can merge all the different foreign databases together has thereby
> rendered OSM obsolete.

I *don't* mean that they could do it *automatically*. Distributed
version control systems don't do that either, you always need a human
to look at the result to see if it's sane.

I mean that we don't have *anything* currently that can take:

    1) A foreign database as it was X years ago, each object having
       some UID.

    2) A foreign database as it is *now*, each object having
       corresponding UID's.

    3) The OSM data imported from the #1 with the foreign UID's as
    tags, along with the new updated #2 database.

And present users with some object-by-object comparison of things that
changed, and offer them a way to resolve it using an OSM editor.

If we had a tool like this the problem of imports going stale would be
largely solved, since even if you have 10.000 changes from year to
year in the foreign database that's not a problem if you can
efficiently merge those changes.

We can't do that now, the best I've seen people do is something like
the TIGER upgrade where areas that haven't been touched *at all* are
being upgraded, but there's no interactive upgrade mechanism for areas
that have been touched, but where the TIGER data may be better than
what we currently have.