On 18 October 2012 23:05, Frederik Ramm <frede...@remote.org> wrote:
> In a recent message, to talk-it
> (http://lists.openstreetmap.org/pipermail/talk-it/2012-September/030778.html),
> Paul writes
>
> "We recognize that the line between an import and assisted mapping is not
> currently clearly defined; however all the cases I have seen recently
> clearly were on the import side of that line."
>
> So he calls it "assisted mapping", I called it "using a variety of legal
> third-party material in the mapping process", we could also call it "a
> manually verified, small-scale import".
>
> These things are ok and while it is not currently written, DWG does not
> enforce separate accounts for them. If that is any help, we can try to sit
> down together and try to clarify the line between "assisted mapping" and
> "import".
>
> There are many reasons why we want mass imports clearly separated from
> normal, human-contributed data. We got burnt by this in the license change
> in Poland, where we had to spend massive amounts of time sorting between
> "good" and "bad" changesets contributed by the same account.

This is off topic in this thread, but I'd like to set the record
straight.  Who do you refer to as "we" when you say you had to spend
any time sorting those changes?  The LWG and the rest of the
contributors to the license change have done nothing at all to
understand what data in Poland was compatible with the new license and
which of it wasn't.  You might have noticed (or not) that pretty much
every sentence in LWG minutes referring to this data has a factual
error of some sort, especially the ones quoting any numbers.  Really.
This was on such a scale that the day before the redaction started
(Tuseday morning) I was asking people on #osm-dev including LWG
members and the bot operator, if any of the decisions made by LWG to
that time had in fact been taken into account.  What I learnt was that
the final rules to be applied by the bot were such that over 50% of
the data to be redacted by the bot in Poland was in fact compatible
with ODbL, while at the same over 50% of the data incompatible with
ODbL would be left in the database.  Completely nothing had been done
to that time.

(And even then there was not much will to do anything right.  I was
told that if I wanted to provide drop-in code to fix the basic
problems, then I had about 12 hours to do so -- that was another
statement that made Michael's Collins' "reasonable effort" and "due
diligence" simply laughable.  On that same day, the operator of the
bot had literally said that it was not his task to read LWG's meeting
minutes and implement those plans.  A week later when it turned out
that a human mistake caused too many objects to be redacted (mind you
those objects have not been unredacted to this day -- a joke on the
automated edits guideline where you're supposed to have the tools to
undo anything you do), another community member had come to #osm-dev
to ask about this and was quoted an hourly rate for programming work
by one of the OSMF board members for repairing the destruction done to
that contributor's work)

So I'll appreciate it if you can avoid saying that you'd spent time
sorting through any changesets (or have you and that work was simply
not used?).  I had agreed to provide the whitelists and blacklists
needed for the bot to approximate what would be a license-based
redaction because I felt responsible to both the Polish OSM community
and the authors of the CC-By-SA data to be removed, for what the OSM
project does with those people's contributions.  I had quit the OSMF
to avoid the responsibility for their movements.  But at that time I
had already spend *weeks* of programming work trying to help the OSMF
destroy less by writing the equivalent of the redaction bot to go
through UMP edits history.  And because of that decision I have even
spent a couple hours this last weekend helping the OSMF do *more*
destruction to free geographic data in the OSM database, instead of
doing something productive.

Now coming back to the question of dedicated import accounts, I don't
see they make a lot of difference.  They're not a huge burden to the
importer, but they neither do solve any problem that the source
tagging doesn't solve better already.  If you want to redact the OSM
database ignoring basic facts and information that has been provided
to you clearly and repeatedly by different people then not much is
going to help you.  Still the UMP imports usually have required days
to weeks of manual work before each changeset uploaded because of the
data model differences and I think you could easily put them in the
"assisted import" category.  Which would mean that there's more manual
work in them than 3-rd party and using either a separate account, or
entire-changeset tagging, would cause more false negatives than not.
You could do that work in smaller changesets but you'd lose the
atomicity or "bisectability" in git speak, where you'd have a map
state in between the beginning of the work and the end, which is
unroutable and unusable.  We've put great effort in avoiding that by
doing a lot of preparation for each upload and working together with
other local mappers.

Cheers

_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Reply via email to