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.
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.
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.
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.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.html
class 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?
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.
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.
Z
_______________________________________________
osmosis-dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/osmosis-dev
