Worst OSM Fixer

Posted by WorstFixer on 11 May 2012 in English (English)

Problem of OSM is graphomania.

People want to write.

To write long books about openstreetmap.

Books! Posts! Stuff!

To write long threads on openstreetmap. Even longer to prevent disputes.

To prevent dispute, they write 103 messages

When someone imports loads of shit, they keep silence.


When someone posts pictures of that, they laugh and make fun.

Negatives are good!

When someone fixes that, they ban him.

Nobody ist perfect. Ich am not.

I not wanted to write this post. But I have 24 hours free time to think. I was banned, and will be banned in future if laws not change. If you want to fix something in OSM you have to be graphomaniac. You will write tons of letters to change tens of objects.

That sucks.

I was told to announce so I announce.

  • is_in tag is_indikator of bad import. Look yourself at taginfo. If object author used is_in tag instead of Karlsruhe scheme he did his import carelessly.

  • ele tag is another bad import indikator. Look yourself at taginfo. ele=0 ist used on carelessly imported parkings, and non-touched GPS way points. I am not saying anything about which sucks too.

For that reasons, I declare:

  • I will not upload any object with is_in tag. I will remove that tag. Not to lose data I will store all data from it into Karlsruhe schema.

  • As first thing after ban finishes, I process all un-elevated objects. Remove ele=, latitude=, longitude= tags. See what to do with other.

  • Ich want no war. OSMF und DWG will ban me if Ich edit too fast. I will wait for all the bans to finish. They limit maximum speed. I limit minumum speed. Ich set minimum speed fur mich as 50 000 nodes a day. If Ich edit 100 000 objekts per ein day, it is O.K. to ban me for day. If 150 000 - for two and so on. No more please, if you want no war too.

  • Being Worst OSM Fixer, remembering that OSMF promised to never tell anyone who Ich really am, Ich collect any letters and tweets about shit-imports, bad tags und other fixable stuff.

  • I promise to never tell any one who you are. Show me things you dislike. If thing you show me convinces me that all is bad there, I will fix it.

  • My twitter ist!/WorstFixer und Ich read it.

Comment from efred on 11 May 2012 at 06:49

hallo, is_in- und ele-tags sind keine fehler von Importen. ele wird an nodes über 1,7 millionen mal eingesetzt: siehe auch im wiki: und is_in wird insgesamt über 3 millionen mal eingesetzt. siehe dazu den wiki-eintrag

Hide this comment

Comment from Minh Nguyen on 11 May 2012 at 07:15

If you plan to delete nodes where ele=0, please make an exception for nodes with gnis:feature_id or gnis:import_uuid tags. Those belong to a huge, perfectly legitimate import of GNIS data in the U.S. Much of the GNIS data is stale, but it provides tons of names that would take us impossibly long to collect ourselves.

Hide this comment

Comment from woodpeck on 11 May 2012 at 08:15

You have not been told to announce before you edit; you have been told to discuss (with those who are likely affected). The proper procedure, if you want to automatically "fix" anything, is:

  • make up your mind about what you think needs fixing and how it could be fixed;
  • discuss on talk list (or, possibly, on the mailing list for the country affected by your edit)
  • find consensus
  • make a wiki page or similar to document what you're doing
  • then do it.

If consensus cannot be found, then the edit is not ok; no matter what speed it is done at.

Hide this comment

Comment from Zverik on 11 May 2012 at 09:05

woodpeck, why it is ok to import garbage, but takes weeks of discussions to remove it?

Hide this comment

Comment from Tom Chance on 11 May 2012 at 09:50

Zverik, it isn't ok to import garbage but two wrongs don't make a right!

Running large scale edits can easily delete or modify content in ways you won't expect. People may have improved some of the poorly imported data, so you will delete their work. You may inadvertently catch good work in your net. You may have simply mistaken some edits as being bad when they are work in progress or even reflect the facts on the ground.

It is arrogant and bad behaviour to go deleting lots of content without first checking that you are working from sound assumptions.

Hide this comment

Comment from kayle on 11 May 2012 at 11:15

1./ Why you think is_in tag is wrong import? Maybe it contains data which are somehow used. Maybe not in you county, but in other yes.

2./ ele=0 well, maybe most of ele=0 tag are unnecessary, but all? don't know

Graphomania is not OSM problem, people are problem :)

"bad imports" sometimes are not bad, only unfinished

Hide this comment

Comment from Tomas Kovacik on 11 May 2012 at 11:27

kayle is right.

your opinion is that that imports are all bad, my is that you are bad, maybe we should delete you :)

Hide this comment

Comment from Harry Wood on 11 May 2012 at 12:41

On a practical tagging level, I don't really think Kayle is right. is_in is a bad tag, I'd hope that one day we might purge it. I can also see your point of view that people laughing and having fun with the 'Worst of OSM' site is not a very positive/pro-active approach to fixing problems in OSM data.

But you were banned for making automated edits without discussing it properly. You probably think you're clever because you figured out how to run a bot. That's not clever. Clever is persuading and getting the community on your side with your ideas for sweeping changes. If you get annoyed and start talking about going to war against people in the community who work hard to build and protect it... then nobody is going to find you very persuasive.

So don't be annoyed. Try to discuss more and work on being more persuasive

Hide this comment

Comment from Vincent de Phily on 11 May 2012 at 12:48

Fixing OSM data is needed and important (in fact it's the whole point of being an OSM contributor), but it sounds like your over-enthusiasm causes two problems :

  1. You're going too fast when deciding wether something is an error, and make generalizations when you should proceed on a case by case basis. For example, is_in is valid and good in many places, and the S/N in south america deserves surveying/imagery (as opposed to anthing automatic) to be fixed properly.

  2. You try to bypass the community advice in order to go faster. It's true that discussion slows things down, but it's necessary to avoid big mistakes.

Dont take this as a "me VS the others" chalenge. We're all working together to improve the map (and we need all the manpower we can get). The temporary block you got is just a warning that you're doing it wrong, and risk making as much of a mess as you intended to fix. Learn from that warning :)

Hide this comment

Comment from kayle on 11 May 2012 at 15:59

I'm happy if somebody find error or bad data and fix it. But please, ask first if you do large area bot edits in different countries.

Hide this comment

Comment from Sanderd17 on 11 May 2012 at 18:07

I've used is_in tags on places where I don't know the boundary, so I could (hopefully) determine the boundary after enough is_in tags.

And no, there are no copyright-free maps which contain boundaries of Belgium.

Hide this comment

Comment from woodpeck on 11 May 2012 at 18:26

You seem to think that you are doing "the right thing" but you aren't. You are worse than the people importing garbage.

You have changed thousands of roads named "S/N" to service roads based on the erroneous assumption that S/N was Spanish for serivice road. Had you followed the automated edit policy and discussed that before you acted, the error could have been avoided.

You have removed the "created_by" tag on more than 100,000 nodes, therefore significantly increasing database bloat without good reason. It is community consensis to remove created_at when you touch an object for some other reason, but not if that's the only edit you make. Had you discussed that beforehand, this error could have been avoided.

You have converted is_in tags to addr:country or addr:province, even though the addr:* tags are for exclusive use by objects that have addresses - addr:* is not a replacement for is_in. This mistake could have been avoided if you had talked to other people before you acted.

Not only do you make the wrong edits, you are also quite arrogant about it; this is not the right attitude to engage with mappers.

And in addition to that, your edits are technically flawed (see e.g. where you edited something without editing it).

You want to do something useful for the project but you act like a child. You use fragments of German in an attempt to be funny but you fail; you don't want to reveal who you are but you want your contribution to be taken seriously.

I think you have to decide. Yes OSM has shitty imports and we need good people to guard against that and to keep up our standards. You could be one of these people - or you could be a self-righteous twat playing silly games.

Hide this comment

Comment from pieleric on 11 May 2012 at 23:21

Concerning the S/N roads in Peru. This doesn't mean they are service roads. I'm pretty sure it stands for "Sin Nombre" which means "no name" in Spanish. Apparently in the import of Telcom IP, every street without known name got named "S/N". It's an horrible idea. Nevertheless they might still be big roads, and actually it's unlikely any of them is a "service road".

Hide this comment

Comment from pieleric on 12 May 2012 at 09:14

Hello, Concerning the S/N roads. I believe "S/N" stands for "Sin Nombre" which is Spanish for "Without Name". So it's probably there to mean that in the import the name was unknown. I doubt it means it's a service road (and if you look on the imagery, many road called "S/N" are pretty big roads).

Hide this comment

Leave a comment

Parsed with Markdown

  • Headings

    # Heading
    ## Subheading

  • Unordered list

    * First item
    * Second item

  • Ordered list

    1. First item
    2. Second item

  • Link

  • Image

    ![Alt text](URL)

Login to leave a comment