[OSM-talk] Import guidelines review

[Worst Fixer]

Hello Frederik,

>> I did a redraw of them. To make understanding easier.
>> http://www.openstreetmap.org/user/WorstFixer/diary/17025
>> Do you have any comments? What to add? What to remove?

> I am very reluctant to have someone who
...
> (4) continues to make misleading and offensive statements in their OSM user
> blog

> play any part in rewriting our import guidelines, or helping to enforce
> them.

I see. Personality and charisma matters for you, thus, for DWG
decisions. That is why we need strict guidelines. Agreed by everyone.
Not just people who Frederik likes. Or dislikes.

> I know that we don't operate a strict real-name policy at OSM but I would
> expect someone who wants to be involved at a level where they make mass
> edits and help shape project guidelines to be a real person with an identity
> and not just some nickname.

I would not expect that. OSM has strict privacy policy, that says
"nothing but your user name will ever be disclosed". User name is
needed only to fight vandalism and have way to contact. Not to find
people in real world.

> Also, I know that it would be good practice to separate the message from the
> messenger, and even someone who does lots of stupid things could in theory
> come up with helpful documentation.
>
> In this case, I really have a problem. Yes, the import guidelines could be
> improved; but no, I cannot trust "WorstFixer" to do a good job at it. The
> complete overhaul suggested by "WorstFixer" is not the way to go.

It is made from current Import Guidelines looking at latest
discussions on imports at . It changes almost nothing. Only
representation.

> I support Jaak's points; I dislike the flow chart presentation;

Flow chart representations lets you fit everything into one screen.
For major things like guidelines it is better than making 300 page
book that nobody will read.

Look at http://creativecommons.org/licenses/by-sa/2.0/. It says
everything in one screen.

> and I think that
> WorstFixer's chart introduces too many of his own ideas (e.g. where does
> "shape aligns well with satellite" come from - it certainly makes no sense
> without further qualifying it to a degree not possible in a flow chart).

I can drop this statement if you wish. But we need replacement for it then.

Potential data sources are sometimes badly generalised, or are not to
scale at all. See some parts of TIGER for example. We need to avoid
this before data gets to database.

> I very strongly support Jaak's mentions of "make available instead of
> import" (technology for that is becoming ever easier with e.g. Josh Doe's
> conflation plugin for JOSM and Potlatch's vector backgrounds and snapshot
> server). This is the future of imports that involves the local mappers
> instead of just emptying a bucket over the map.

Then it has to be in import guide lines. So people adopt it and use it.

> Any import with a reasoning of "there's no mappers there anyway, so it's
> either import or no data", or "there are no mappers in X but at least when I
> do the import my company has something they can show our customers in X",
> is, in my opinion, not acceptable.

It means that we must revert things like TIGER and CanVec. Am I right?

> If you build a factory then this usually has lots of advantages for the
> local economy - you create jobs, you pay money to the government, you
> increase the importance of the region. But factories can also harm the
> environment, something that you don't see immediately; something that
> becomes obvious only later. That's why many countries now require people to
> assess the environmental impact before a factory is built; and I would
> request the same from would-be importers in OSM. Assess the impact that your
> import will have on the community.

I was tempted to write "tl;dr" after this, even though I read this. 8
lines of nice bookish English is nice for some newspaper article. But
it is not the way to write guide lines. Keep in mind people who not
spik inglish.

-- 
WorstFixer, twitter: http://twitter.com/WorstFixer