Hi Zenon, On Wed, Sep 1, 2010 at 11:33 AM, Zenon Panoussis <ora...@provocation.net>wrote:
> > 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/%7Eoracle/gap_manaus.png> > http://www.xs4all.nl/~oracle/gap_lima.png<http://www.xs4all.nl/%7Eoracle/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. > Um, don't your polygons only touch at a single point (-77,0) and not along a one dimensional -77 longitude line as you suggest. The two polygons touch at the equator, drift apart as they travel south, then touch again at the south pole. There's a gap between them which would explain the missing data. Have I misinterpreted something here? > > 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/d...@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. > Osmosis uses the http://download.oracle.com/javase/6/docs/api/java/awt/geom/Area.html class to manage the polygon, and it is constructed from the http://download.oracle.com/javase/6/docs/api/java/awt/geom/Path2D.Double.htmlclass which provides double precision coordinates. It will only treat objects lying along some edges of shapes as being inside the area (ie. left edge of a polygon is included, but right edge isn't). This should mean that in cases of touching polygons data should only be included in one of the two. See http://download.oracle.com/javase/6/docs/api/java/awt/Shape.htmlfor more details. That's not to say there isn't a bug in the Sun *cough* Oracle libraries, but it's certainly not custom code that I've written. On that note, I suspect that data along the international date line might encounter issues if you specify a polygon right edge of exactly 180 degrees because data on that line will then be excluded. But that's not your issue. The solution in that case is probably to specify a right edge of 181 degrees to work around the problem. > Ideas anybody? > Please check your polygons again. And if you still think they're right please let me know where I've gone wrong :-) Brett
_______________________________________________ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
