Hi Zenon, On Sat, Sep 4, 2010 at 8:36 AM, Zenon Panoussis <[email protected]>wrote:
> > Brett Henderson wrote: > > 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. >> > > Each polygon starts at the pole, travels north to the equator along the > left meridian, travels along the equator to the right meridian and then > back to the pole. Since (in the first polygon) -76,-90 is the exact same > point as -77,-90, the line from -76,0 to -77,-90 is the -76th meridian. > No, I don't believe that is correct. -76,0 to -77,-90 is not the -76th meridian. Yes, it starts on the 76th meridian and eventually finishes at the south pole, but it follows a different path to get there. The 2D libraries being used here do not know that the coordinates map to a globe and therefore will not draw straight lines on a globe, they draw straight lines between coordinates assuming a 2D plane. Projected onto a globe, the line will be curved. The line from -76,0 to -77,-90 passes through -76.5,-45, not -76,-45. > > Likewise, the second polygon goes north along -78, east along the equator > and then back south along -77, which is its common line with the first > polygon. "-77,90 -77,0" and "-77,0 -78,-90" are in fact the very same > line, the -77th meridian, but in a confusing notation and drawn S->N the > one and N->S the other. > > If I wrote something like > > > S-77--76.pol > 1 > -77.0 -90.0 > -77.0 0.0 > -76.0 0.0 > -76.0 -90.0 > -77.0 -90.0 > END > END > > the polygon would *appear* more closed, but in reality the last "line" > would only be a point. > Have you actually tried this? I am fairly confident that it will fix your problem. > > Geographically at least, this is all correct. But I don't know how it is > translated into math, and it could very well be that > "-77.0,90.0 -77.0,0.0" = "-77.0,0.0 -78.0,-90.0" confuses the parsers. > I suspect the 2D libraries are working exactly as designed, you just have to be aware of the implications of using 2D coordinates to describe points on a spherical surface. I could be wrong, but please try a full square polygon instead of your existing triangles. > > BTW, I wrote something in my previous posting about Manaus being on 77W > and followed that with some grep output. It's Lima on 77W, not Manaus, but > I have the same problem with both and my grep results are consistent with > the problem, albeit for the other city. > > > Osmosis uses the >> http://download.oracle.com/javase/6/docs/api/java/awt/geom/Area.htmlclass 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. >> > > Hmm, that's very interesting. Do I understand you correctly, that all > the polygons that are defined as parts of one operation with --bp are > considered and then their edge points on one side are removed to avoid > duplication? > Refer to the "Definition of insideness" at the following URL. http://download.oracle.com/javase/6/docs/api/java/awt/Shape.html My reading is that points on the left or bottom boundaries of a polygon are considered inside, and those on the right and top edges are not. > > After my previous postings I sliced out my map gap from planet.osm (for > the real Manaus and using the "a line for a point" notation on the pole > itself): > > -60.02 0.02 > -60.02 -90.0 > -59.98 -90.0 > -59.98 0.02 > -60.02 0.02 > > Manaus lies on lat 3.11S, where a longitude degree is 110578 metres. > The 0.04 degrees of the slice above are 4423 metres wide at this > latitude and my gap was about 2700 metres. In other words, the new > slice should cover the gap with good margin. > > When I imported it, half the gap was filled. The eastern half. > > Now note: when I exported two adjacent polygons, java tried to remove > some points on one edge to avoid overlaps. This time however I was not > exporting adjacent polygons, but polygons that were 0.96 degrees apart. > Therefore, nothing should have been excluded. Yet I'm still missing a > band of about 1350 metres in Lima and Manaus. > > I have an unproven theory on what's going on here. > > Theoretically, only a point can be part of a line and a point has no > second dimension. In practice though, a point will have a second dimension > because we don't work with infinite precision numbers. The thickness of a > point will be the smallest decimal that can be represented with the number > precision that we happen to be using. > > At the latitude of Manaus I originally lost a band ~2700 metres wide, > which is way beyond anything that could be explained by number precision. > But my polygons went all the way to the pole. As we get closer to the pole, > precision begins to matter. As we get real close to the pole itself, the > distance between meridians becomes a value so small, that double precision > numbers no longer can express. > > So my guess is this: java sets the width of the area to exclude at the > smallest possible number at the narrowest place of the polygon, which > in this case is the pole or very close to it. It sets it not in metres, > but in degrees. As the polygon progresses towards the equator, the > infinitesimally narrow exclusion band grows wider and wider, until it's > almost three km wide at the latitude of Manaus. > > Not only that, but it does this irrespective of whether we are reading > adjacent polygons or not. Which makes sense, because one instance of a > subroutine doesn't know what parametres another instance of the same > subroutine might or might not have been called with. > > This would explain why I lost so much in the first place and also why > I still lost some when I was exporting non-adjacent polygons. The original > export > > -60.0 -90.0 > -60.0 0.0 > -59.0 0.0 > -60.0 -90.0 > > lost me about 2700 m around 60W, smack on Manaus. The next export, > > -60.02 0.02 > -60.02 -90.0 > -59.98 -90.0 > -59.98 0.02 > -60.02 0.02 > > lost me about 2700 metres around 60.02W, which lies 2210 metres left of > 60W. > Hence, 1105 metres were filled on the right (east) side of the previous > gap, > leaving approximately the left (west) half of it still gaping. It seems > that > the right edge of a polygon is included, not the left. > > Sure, I'm speculating here and I have no hard evidence for my conclusions. > Then again, this theory explains the actual results and is not contradicted > by anything as far as I can see, so it seems valid to me, just as a theory > of > course. I don't understand java code, so I can't actually verify it. Again, I believe that the problem is due to your triangular polygons, but if that proves not to be the case then I'll start digging further. Rather than deal with large amounts of data, please create a simple OSM file that contains a single Node object that is being mistreated by the --bounding-polygon task. Then we can figure out exactly where the problem lies. > > > 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. >> > > If I am right in all this, then java is to blame and you not. Instead of > setting the width of a line as the smallest possible number at the best > available precision in degrees, it should set it as the smallest available > number in metres, so that the then extremely small error remains constant. > This would block a small area around the poles from ever being processed, > but that's much better than losing millions of square kilometres in areas > where mapping actually matters. > > It's also possible to work around the java problem in osmosis, but before > I make any suggestions in that direction I would like to see my theory > confirmed. If my disks survive the currently ongoing thrashing of > re-importing > the whole planet into postgres, I'll try some experiments. > Which schema are you importing into? If you are using a PostGIS schema then the projection you use may impact the results. Brett
_______________________________________________ osmosis-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/osmosis-dev
