[OSM-talk] JOSM incomplete ways debuggung (was: Unordered segments)

David Groom reviews at pacific-rim.net
Sat Apr 28 23:52:10 BST 2007


----- Original Message ----- 
From: "Frederik Ramm" <frederik at remote.org>
To: "Martijn van Oosterhout" <kleptog at gmail.com>
Cc: <talk at openstreetmap.org>
Sent: Saturday, April 28, 2007 11:16 PM
Subject: [OSM-talk] JOSM incomplete ways debuggung (was: Unordered segments)


Hi,

Martijn van Oosterhout wrote:
>> In my opinion it's not the incomplete flag, but that JOSM cannot somehow
>> cope with ways that have been downloaded in several steps. Somehow it
>> just patches the new stuff on, instead of rebuilding the way from the
>> data now available.
>
> The thing is, I've looked at the code and the problem that's occuring
> simply Shouldn't Happen (tm). The problem is basically that somehow
> multiple nodes with the same ID appear and some get attached to the
> right object and some don't.
>
> I still don't understand the download merging process enough yet to
> really look into it, but I'm thinking of piling in the debug info and
> try to work out where it's going wrong...

I have followed the merging process in great detail and must agree with
Martijn - there isn't an obvious mistake at least. If a way is
downloaded which contains segments that are not present, "placeholder"
objects (incomplete=1) are created; if new data arrives in later
downloads, newly arrived segments with the same id as stored incomplete
segments will overwrite the existing segment (more specifically, a
"cloneFrom" method is called on the existing segment that copies all the
new data into the old segment, unsetting the "incomplete" flag in the
process).

It all *looks* right; the only thing I can think of is that somehow one
of the incomplete segments remains, or is duplicated or so.

I've been trying to set up a very simple example:

lochewe% cat i1.osm
<osm version="0.3">
<node id="1" lat="1" lon="1" />
<node id="2" lat="2" lon="2" />
<segment id="11" from="1" to="2" />
<way id="21">
<seg id="11" />
<seg id="12" />
</way>
</osm>

lochewe% cat i2.osm
<osm version="0.3">
<node id="3" lat="3" lon="3" />
<segment id="12" from="2" to="3" />
</osm>

First file contains an incomplete way, second file contains the missing
segment. But with this example, loading file 1 and then file 2 will make
the way complete, exactly as it should.

Can anyone provide an example where this doesn't work and where you have
to apply the "save the whole thing as .osm, then load it again"
workaround to actually get a complete way? - Ideally in the form of two
files, but two bounding boxes would also be perfect as long as it is
repeatable...

It has happened to me a thousand times but now that I try to provoke it
and write down (or save) the exact data, I can't seem to reproduce it.

Bye
Frederik

Frederik,

Its not exactly an example of the situation you describe, but is an example 
of the "save the whole thing as .osm, then load it again", and is the main 
reason why I have been inadvertently creating unordered ways in JOSM 
(currently version 222, and the following problem still exists):


The problem arises where you are using a  combination of the applet and 
JOSM.

1) Create a series of nodes in the applet, and draw segments between them.

2) Then load this area into JOSM and make the segments into a way.

3)  Upload the way to the server.

4) In the applet, add some new nodes infront of the way, and draw segments 
between those new nodes, and then connect these new segments to the way.

5) Re-download this area into JOSM and add the newly created segments to the 
way created in (2).

6) Try and reorder the way in JOSM.  It wont reorder.  You have to save the 
whole thing as .osm, then load it again, then reorder and it works.

It may seem that the example I have given above is a very long winded and 
extreme example.  All I can say is that where you are using Yahoo Satellite 
imagery to add nodes and segments I find it much easier to join these into a 
way, and annotate those ways in JOSM, and the situation I have described 
happens very frequently.


David







More information about the talk mailing list