Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

Inconsistencies in OSM data #639

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 3 comments
Closed

Inconsistencies in OSM data #639

openstreetmap-trac opened this issue Jul 23, 2021 · 3 comments

Comments

@openstreetmap-trac
Copy link

Reporter: martin.schaller[at]gmx.de
[Submitted to the original trac issue database at 10.35pm, Wednesday, 16th January 2008]

The osm database seems to contain some inconsistencies.
For example, way 19854486 contains in the planet.osm nodes in the range 130273708 - 130288164.
The history of the way also shows this nodes, but in the current version (with the same timestamp) they are not available. The nodes itself are reported as "410 Gone".

@openstreetmap-trac
Copy link
Author

Author: jburgess[at]uklinux.net
[Added to the original trac issue at 11.15pm, Wednesday, 16th January 2008]

The history data looks odd. The way was created referencing the 130273708 node at 01:43:59

<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.5" generator="OpenStreetMap server">
  <way id="19854486" visible="true" timestamp="2008-01-07T01:43:59+00:00" user="AiNikolas">
    <nd ref="207713785"/>
    <nd ref="138470330"/>
    <nd ref="130273708"/>
...

but exactly 1 second earlier it seems that node was deleted...

...
  <node id="130273708" lat="40.7232322" lon="22.8403975" user="AiNikolas" visible="true" timestamp="2007-11-24T17:52:14+00:00"/>
  <node id="130273708" lat="40.7232322" lon="22.8403975" user="AiNikolas" visible="false" timestamp="2008-01-07T01:43:58+00:00"/>
</osm>

The way wsa created by Potlatch. Any Ideas Richard?

@openstreetmap-trac
Copy link
Author

Author: richard[at]systemeD.net
[Added to the original trac issue at 3.28am, Thursday, 17th January 2008]

Appears to be an issue with splitting ways. Am investigating.

Node 130273708 (problem node)[[BR]]
http://www.openstreetmap.org/api/0.5/node/130273708/history [[BR]]
originally in way 13874445 at 2007-11-24T17:43:55+00:00 [[BR]]
deleted at 2008-01-07T01:43:58+00:00 [[BR]]
(also, shouldn't be rewritten every time!)

Way 13874445 (deleted)[[BR]]
created at 2007-11-24T17:43:55+00:00 [[BR]]
deleted at 2007-11-24T17:45:51+00:00 [[BR]]

Way 18925657 (southern section)[[BR]]
rewritten at 2008-01-07T01:43:58+00:00 when node was removed from it and deleted [[BR]]

Way 19854484 (bridge)[[BR]]
first written at 2008-01-07T01:43:57+00:00 containing the node [[BR]]
rewritten at 2008-01-07T01:44:08+00:00 when node was removed

Way 19854486 (live, containing problem node)[[BR]]
created at 2008-01-07T01:43:59 [[BR]]

So it appears that:[[BR]]

  • 01:43:57 - user splits way 18925657[[BR]]
  • 01:43:57 - bridge/northern section written as new way 19854484[[BR]]
  • 01:43:58 - southern section rewritten as way 18925657, all nodes only in northern section are deleted (those also in other ways are retained)[[BR]]
  • 01:43:59 - user splits way 19854484[[BR]]
  • 01:43:59 - northern section written as new way 19854486, with full list of nodes as if they hadn't been deleted[[BR]]
  • 01:44:08 - bridge rewritten as way 19854484

It seems possible that (despite the timestamps) the southern section uniquenodes table is being assembled before the northern section's way_nodes are written. Therefore the southern section uniquenodes table contains the nodes of the northern section.

@openstreetmap-trac
Copy link
Author

Author: richard[at]systemeD.net
[Added to the original trac issue at 10.24pm, Thursday, 17th January 2008]

When splitting a way, 0.6c will now write both 'halves' immediately, rather than one immediately and one when the user deselects. This means they will be batched in the same HTTP request and the above problem of processing two in parallel will be avoided.

In addition, 0.6c also checks thoroughly that all nodes in a way are visible on 'putway'.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant