[OSM-dev] JOSM problem with 0.4 api

Jon Burgess jburgess777 at googlemail.com
Sat May 5 19:43:59 BST 2007


Josm seems to get confused with the 0.4 API. When we download several
overlapping areas Josm sometimes believes that there are changes to
upload. It is not clear why but maybe be due to the conflist
resolution code. The data shows 2 segments between a pair of node, one
in a way, the other unattached. When the data is saved by Josm, it
seems to have swapped the segments in the way:

The two downloads by Josm were of:
wget -O a.osm "http://www.openstreetmap.org/api/0.4/map?bbox=-0.48516258072916785,51.75637877291667,-0.4452265192708321,51.78069122708333"
wget -O b.osm "http://www.openstreetmap.org/api/0.4/map?bbox=-0.5006673996541688,51.73079619698333,-0.4316578854541646,51.772808117783335"

data.osm is the files saved by JOSM.

The 2 Segment IDs are: 6183487 & 17068955.
This is present in the b.osm download only:

[jburgess at localhost broken2]$ grep 6183487 a.osm
[jburgess at localhost broken2]$ grep 6183487 b.osm
  <segment id="6183487" from="8079226" to="648282" user="Jon Burgess"
visible="true" timestamp="2007-01-29T23:09:30+00:00">
[jburgess at localhost broken2]$ grep 17068955 a.osm
[jburgess at localhost broken2]$ grep 17068955 b.osm
  <segment id="17068955" from="8079226" to="648282" user="80n"
visible="true" timestamp="2006-11-12T23:55:45+00:00">
    <seg id="17068955"/>

In b.osm above it is segment 17068955 which is in a way. In the saved
JOSM data the segment has switched to 6183487. For some reason it
thinks the segment needs uploading, but the reason is not clear:

[jburgess at localhost broken2]$ grep 6183487 data.osm
  <segment id='6183487' action='modify' timestamp='2007-01-29
23:09:30' from='8079226' to='648282'>
    <seg id='6183487' />

I have uploaded the files for reference:
 http://www.jburgess.uklinux.net/a.osm
 http://www.jburgess.uklinux.net/b.osm
 http://www.jburgess.uklinux.net/data.osm

SteveC says: email your IPs to him if you want access to the 0.4 API
to attempt to fix this (currently access is restricted to a list of
fixed IPs while the deployment issues are resolved).
General access to the API will be restricted until this issue gets fixed.

-- 
    Jon




More information about the dev mailing list