BugBuster: Difference between revisions

From OpenStreetMap Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 13: Line 13:
== Fixing doubled nodes in ways ==
== Fixing doubled nodes in ways ==


This does not break any closed ways (only on broken imports it might look like), it's only deleting doubled ways in a way not if the first and the last node is the same.
This does not break any closed ways (only on broken imports it might look like), it's only deleting doubled nodes ('''same Node-ID''' in the given way) in a way not if the first and the last node is the same. This bot does '''not merge''' two Node-IDs.


Dataset is the planetfile.
Dataset is the planetfile.

Revision as of 15:29, 28 September 2009

This bot changes general errors in OSM dataset is the planetfile. If the version changed from the latest planetfile, the bot will ask the api for the latest version of the element and update it's datasource. So the changes depends on very latest version of osm data.

Runs

Splitting long ways

Since the API is version 0.6 ways with more than 2000 nodes exists but could not be restored at this length. Else they could not be added as member of a relation if they wasn't before the API changed.

The changes were well discussed on #osm channel on the IRC.

There is currently a bug in the edits which is going to be solved till tomorrow (2009-09-28). It affects only some of the long ways which was part of a relation before the API changed.

Fixing doubled nodes in ways

This does not break any closed ways (only on broken imports it might look like), it's only deleting doubled nodes (same Node-ID in the given way) in a way not if the first and the last node is the same. This bot does not merge two Node-IDs.

Dataset is the planetfile.

Since today every affected way got a own changeset, this behavior is going to be changed before next edits are done.

Changesets contains up to 1000 ways or 45000 nodes, whats reached first (normally ways). Change sets are normally bounding nearly the whole world because we move from the lowest to the highest ID without localisation-sorting.