[osmosis-dev] Boxing accuracy

[Zenon Panoussis]

Hi everyone

I just subscribed and, as you might expect, I'm coming here with
a problem. I think it's an osmosis bug, but I can't say that for
sure.

I find the planet.osm file completely unworkable because of its
sheer size, so I used osmosis to split it into 720 more manageable
parts, which I then imported into a postgis/mapserver-utils database.

Looking at the result, I have lost about 2 meridian minutes of data
along each meridian, one on each side of it.

A couple of images explain it best:
http://www.xs4all.nl/~oracle/gap_manaus.png
http://www.xs4all.nl/~oracle/gap_lima.png

Both Lima and Manaus lie smack on a meridian.

Those bands of nothingness in the middle of densly populated cities
are not the result of some conspiracy among osm data contributors.
Here's the original dataset:
http://osm.org/go/NNZblPk--
http://osm.org/go/N2dmLuy--

Thus, my import ate up some of the data.

This is what I did in the specific part of the world where Manaus
lies:

--rx planet.osm \
--tee 2 \
--bp file=S-78--77.pol \
--wx S-78--77.osm \
--bp file=S-77--76.pol \
--wx S-77--76.osm

These are the polygon files referenced:

S-77--76.pol
1
    -77.0  -90.0
    -77.0   0.0
    -76.0   0.0
    -77.0  -90.0
END
END

S-78--77.pol
1
    -78.0  -90.0
    -78.0   0.0
    -77.0   0.0
    -78.0  -90.0
END
END

As you can see, I was just slicing meridian cake triangles from
the equator to the poles. Note that the overlap between the
polygons is a one-dimensional line, not an area.

The resulting .osm files were imported into postgres with
for i in *.osm;
   do osm2pgsql -d osm -a -s -v -S /usr/share/osm2pgsql/default.style \
      -k -G "$i"
done

The osm2pgsql binary was built out of yesterday's SVN with the
insert-as-modify patch at
http://www.mail-archive.com/dev@openstreetmap.org/msg10349.html .

Theoretically, my meridian gap could be caused by osmosis, by osm2pgsq,
or by any of their underlying libraries. My gut feeling though is that
it's caused by a rounding error in osmosis or by an accuracy error in
its underlying routines.

Ideas anybody?

Z